Tactical-Design

정의 Aggregate는 하나의 단위로 취급할 수 있는 도메인 객체의 묶음이다. 주문과 주문 항목이 전형적인 예다. 이들은 별개의 객체지만 주문(과 그 항목들)을 하나의 Aggregate로 다루는 것이 유용하다. Fowler가 정리한 핵심 속성은 셋이다. Aggregate의 구성 객체 중 하나가 Aggregate Root가 된다. 외부에서 오는 참조는 Root만 향해야 하며, 그래야 Root가 Aggregate 전체의 정합성을 보장할 수 있다 Aggregate는 데이터 저장의 기본 전송 단위다. 로드와 저장은 Aggregate 전체 단위로 요청한다 트랜잭션은 Aggregate 경계를 넘지 않아야 한다 DDD의 Aggregate는 리스트나 맵 같은 컬렉션 클래스와 혼동되곤 한다. 컬렉션은 범용 구조이고, DDD Aggregate는 주문·진료 방문·재생목록 같은 도메인 개념이다. 하나의 Aggregate가 여러 컬렉션과 단순 필드를 함께 가지는 경우가 많다. UML 등 다른 맥락에서 쓰이는 “aggregate"는 DDD Aggregate와 같은 개념이 아니다. ...

개요 Evans는 모델 요소를 Entity, Value Object, Service로 분류했다. Fowler는 이를 Evans Classification이라고 부르며, 프로그래밍 언어와 다이어그램 표기법 어느 쪽도 채우지 못했던 사고의 공백을 메웠다고 평가한다. Entity와 Value Object를 가르는 기준은 동일성(identity) 이다. 필드가 몇 개인지, 얼마나 복잡한지는 기준이 아니다. Entity 정의 많은 객체가 속성이 변하더라도 생애주기를 관통하는 연속성과 동일성을 나타낸다. 어떤 객체는 주로 속성으로 정의되지 않는다. 이들은 시간을 관통하고 종종 서로 다른 표현을 가로지르는 동일성의 실을 나타낸다. Evans의 문제 서술은 다음과 같다. ...

Repository 정의 Repository는 보편 언어로 표현된 Aggregate에 대한 조회 접근이다. Evans가 이 패턴을 도입한 문제는 두 가지다. 첫째, 단지 무언가를 찾기 위한 탐색 가능한 연관관계가 늘어나면 모델이 흐려진다. 성숙한 모델에서 쿼리는 종종 도메인 개념을 표현한다. 둘째, 그러나 쿼리 자체가 문제를 일으킨다. 대부분의 DB 접근 인프라를 적용하는 순전한 기술적 복잡도가 클라이언트 코드를 빠르게 압도하고, 그것이 개발자로 하여금 도메인 계층을 멍청하게 만들도록 이끌어 모델을 무의미하게 만든다. 제약 없는 쿼리는 객체에서 특정 필드만 빼내 캡슐화를 위반하거나, Aggregate 내부에서 몇 개의 특정 객체만 인스턴스화하여 Aggregate Root를 무방비 상태로 만들고 이 객체들이 도메인 모델의 규칙을 강제하는 것을 불가능하게 만든다. 도메인 로직이 쿼리와 애플리케이션 계층 코드로 옮겨가고, Entity와 Value Object는 단순한 데이터 컨테이너가 된다. ...