Domain-Driven Development(DDD)

Domain-Driven Development(DDD)¹

• 보편적인(유비쿼터스) 언어를 사용한다.
• 분석 작업과 설계 그리고 구현까지 통일된 방식으로 커뮤니케이션이 가능하다.

개념

Context

• 의미를 결정하는 단어나 문장이 나타나는 설정이다.

Domain

• 지식, 영향력 또는 활동의 영역이다.
• 사용자가 프로그램을 적용하는 주제 영역은 소프트웨어의 도메인이다.

Model

• 도메인의 선택된 측면을 설명하고 해당 도메인과 관련된 문제를 해결하는 데 사용할 수 있는 추상화 시스템이다.

Ubiquitous Language

• 도메인 모델을 중심으로 구성되고 모든 팀 구성원이 팀의 모든 활동을 소프트웨어와 연결하는 데 사용하는 언어이다.

단점

• 모델을 순수하고 유용한 언어 구조로 유지하기 위해, 팀은 일반적으로 도메인 모델 내에서 많은 양의 격리 및 캡슐화를 구현해야한다.
  • 도메인 중심 설계에 기초한 시스템은 상대적으로 높은 비용을 들일 수 있다.
  • 도메인 중심 설계는 유지 보수성과 같은 많은 기술적 이점을 제공하지만, 마이크로소프트는 모델과 언어 프로세스가 복잡한 정보의 통신과 도메인에 대한 공통된 이해를 형성하는 데 분명한 이점을 제공하는 복잡한 도메인에만 적용할 것을 권고한다.

Strategic Domain-Driven Development(DDD)

• 모델 무결성을 유지하고 도메인 모델을 추출하며 여러 모델로 작업하기 위한 일련의 원칙이다.

Bounded Context

• 모델이 적용되는 컨텍스트를 명시적으로 정의한다.
• 팀 구성, 애플리케이션의 특정 부분에서의 사용 및 코드베이스, 데이터베이스 스키마와 같은 물리적 표시 측면에서 경계를 명시적으로 설정한다.

Continuous Integration

• 자동화된 테스트로 모든 코드와 기타 구현 아티팩트를 자주 병합하여 조각화에 신속하게 플래그를 지정하는 프로세스를 구축한다.
• 개념이 다른 사람들의 머릿속에서 진화함에 따라 모델의 공유된 관점을 강조하기 위해 유비쿼터스 언어를 끊임없이 연습한다.

Context Map

• 프로젝트에서 실행 중인 각 모델을 식별하고 제한 컨텍스트를 정의한다.
• 여기에는 비객체 지향 서브시스템의 암시적 모델이 포함된다.
• 각 경계 컨텍스트의 이름을 지정하고, 이름을 유비쿼터스 언어의 일부로 지정한다.
• 모델 간의 접촉 지점을 설명하고, 모든 커뮤니케이션을 위한 명시적 번역의 개요를 설명하고, 공유를 강조한다.

Artifacts

Entity

• 객체는 속성으로 정의되지 않고 스레드의 연속성과 정체성에 의해 정의된다.

Value object

• 속성을 포함하지만 개념적 정체성이 없는 객체이다. 불변으로 취급되어야 한다.

Aggregate

• Aggregate Root라고도하는 Root Entity로 함께 바인딩 된 객체의 Collection이다.
• Aggregate Root는 외부 객체가 해당 멤버에 대한 참조를 보유하지 못하도록 차단하여 집계 내에서 수행되는 변경의 일관성을 보장한다.

Domain Event

• 이벤트를 정의하는 Domain 객체이다.
• Domain 이벤트는 Domain 전문가가 관심을 갖는 이벤트이다.

Service

• 작업이 개념적으로 어떤 객체에도 속하지 않는 경우, 서비스에서 이러한 작업을 구현할 수 있다.

Repository

• Domain 객체를 검색하는 방법은 대체 저장소 구현을 쉽게 교환할 수 있도록 특수 저장소 객체에 위임해야 한다.

Factory

• 도메인 개체를 만드는 방법은 대체 구현이 쉽게 교환 될 수 있도록 특수한 Factory 객체에 위임해야한다.

Reference

1. Wiki_Domain-Driven_Design ↩