DDD 구성요소

1. Entity

   • 식별성을 정의한다.

   • 동일하다는 것이 무슨 의미인지 정의한다.

   • 유일한 결과를 반환하는 연산을 정의한다.

   • 속성으로 일치 여부를 판단하는 요구사항에 주의한다.

   • 모델링과 설계상의 고려사항이 포함되어 있다.

   • Class 정의, 책임, 속성, 연관관계는 특정 속성보다는 Entity의 정체성에 초점을 맞춰야 한다.

   • 자주 변형되지 않거나, 복잡하지 않더라도 의미에 따라 Entity를 분류한다면 Model은 투명해지고 구현은 견고해질 수 있다.

2. Value Object

   • 식별성을 정의하지 않는다.

   • 불변적(immutable)으로 다뤄야 한다.

   • 불변성은 값의 의미에 있어서도 일관성을 지닌다.

   • 불변성은 공유와 객체 참조 전달을 안전하게 만들어 구현을 상당히 단순하게 만들어준다.

   • Model에 포함된 어떤 요소의 속성에만 관심이 있다면 그것을 Value Object로 분류한다.

   • Value Object가 전하는 속성의 의미를 표현하게 하고 관련 기능을 부여한다.

     ** 성능 문제로 VALUE OBJET를 변경하도록 허용할 때가 있다. 구현에 영향을 주는 요인은 다음과 같다. 
     - VALUE가 자주 변경되는 경우
     - 객체 생성이나 삭제에 비용이 많이 드는 경우 
     - 교체(변경이 아닌)로 인해 클러스터링이 제한되는 경우 
     - VALUE를 공유할 일이 그리 많지 않거나 클러스터링을 향상하기 위해서나 다른 기술 적인 이유로 
     공유가 보류된 경우 
     
     다시 말하건대, VALUE의 구현이 변경 가능하다면 그것을 공유해서는 안된다. VALUE의 공유 여부와는 
     관계없이 VALUE OBJET는 가급적 변하지 않게 설계한다. 

3. Repository

4. Aggregate

   • Aggregate에는 루트(root)와 경계(boundary)가 있다.

   • Root는 전역 식별성을 지닌다.

   • Root 이외의 Entity는 지역 식별성(local identity)을 지니며, Aggregate 내에서만 구분되면 된다.

   • 경계 안의 Entity는 서로 참조할 수 있지만, 경계 바깥의 Entity는 해당 Aggregate의 구성요소 가운데 Root만 참조할 수 있다.

   • 경계 안의 Entity는 지역 식별성을 지니며, 해당 Aggregate 안에서만 유일하다.

   • 데이터베이스 질의를 이용하여 Root만 직접적으로 획득하고, 다른 객체는 모두 Aggregate를 탐색해서 발견해야 한다.

   • 삭제 연산은 Aggregate 경계 안의 모든 요소를 한 번에 제거해야 한다.

   • 내부 구성요소에 대한 일시적인 참조는 단일 연산에서만 사용할 목적에 한해 외부로 전달될 수 있다.

5. Servcie

   • Entity나 Value Object의 일부를 구성하는 것이 아니라 Domain 개념과 관련돼 있다.

   • Entity나 Value Object와 달리 SERVICE를 정의하는 기준은 클라이언트에 무엇을 제공할 수 있느냐에 있다.

   • Entity나 Value Object가 주로 동사나 명사로 이름을 부여하는 것과 달리 Service는 주로 활동이나 행동으로 이름을 짓는다.

   • 명칭은 Ubiquitous Language에서 유래하거나 Ubiquitous Language에 도입돼야 한다. 또한 Service의 매개변수와 결과는 도메인 객체여야 한다.

   • Domain의 중요한 프로세스나 변환 과정이 Entity나 Value Object의 고유한 책임이 아니라면 연산을 Service로 선언되는 독립 Interface로 Model에 추가하라.

   • Interface가 Domain Model의 외적 요소의 측면에서 정의된다.

   • 상태를 갖지 않는다

   • 추상적이고 의도적인 정의를 가질 수 있으며, 이것은 객체 정의와는 특성이 다르다.

     ** 여러 계층으로 분할된 서비스 예제  
     Application  
     자금 이체 응용 서비스
         - 입력(XML 요청과 같은) 내용의 암호화
         - 이체 처리를 위한 도메인 서비스로의 메시지 전송
         - 이체 확인 대기
         - 인프라스트럭처 서비스를 이용한 통지 결정
     
     Domain  
     자금 이체 도메인 서비스
         - 금액 인출/입금에 필요한 Account(계좌)와 Ledger(원장) 객체 간의 상호작용
         - 이제 결과 확인 정보 제공(이체 수락 여부 등)
     
     Infrastructure  
     통지 서비스
         - 애플리케이션에서 지정한 곳으로 이메일이나 우펀 등을 보냄  

6. Module

   • Module로 쪼개지는 것은 코드가 아닌 바로 개념이다.

   • 독립적으로 이해하고 논리적으로 추론할 수 있다는 의미에서 낮은 결합도가 달성되도록 노력한다.

   • 시스템의 내력을 말해주는 Module을 골라 일련의 응집력 있는 개념들을 해당 Module에 담는다.

   • 결합도와 응집도에 대한 설명은 기술적인 측정 기준처럼 들리게 해서 연관관계와 상호작용의 배분 방법에 근거해 결합도와 응집도의 정도를 기계적으로 판단하게 만든다.

   • Ubiquitous Language를 구성하는 것으로 Module의 이름을 부여하라.

   • Module의 이름은 Domain에 통찰력을 줄 수 있어야 한다.

     ** 모델링 패러다임
     - 구현 패러다임을 도메인에 억지로 맞추지 않는다. 
         - 도메인에 관한 사고방식은 반드시 하나만 있는 것이 아니다. 패러다임에 어울리는 모델 개념을 찾는다. 
     - 유비쿼터스 언어에 의지한다. 
         - 각종 도구가 서로 엄밀한 관계에 있지 않더라도 언어를 일관되게 사용하면 설계의 각 부분이 분화되는 
         것을 방지할 수 있다.
     - UML에 심취하지 않는다.
         - UML 다이어그램과 같은 도구에 집착해서 그리기 쉬운 방향으로 모델을 왜곡하곤 한다. 
         예를 들면 UML에 제약조건을 표현하는 기능이 포함돼 있지만 충분하지 않다. 다른 그리기 방식이나 
         간단한 문장으로 설명을 써놓는 편이 객체를 바라보는 특정 관점을 나타내고자 도식 방법을 완곡하게 
         바꾸는 것보다 낫다. 
     - 회의적이어야 한다. 
         - 도구가 실제로 제 몫을 하고 있는가? 단순히 어떤 규칙이 있다고 해서 반드시 값비싼 룰 엔진이 
         필요한 것은 아니다. 아마도 약간은 덜 깔끔하겠지만 규칙은 객체로 표현할 수 있으며, 복합적인 
         패러다임은 문제를 터무니없이  복잡하게 만든다.