ddd

DDD(Domain-Driven Design)란 무엇인가?

DDD는 소프트웨어를 만들 때 현실 세계의 업무 영역(도메인)을 그대로 반영하여 설계하는 방법론이다. 하나의 거대한 설계도 대신, 업무 영역별로 경계를 나누고 각각에 맞는 모델을 만든다.

Domain-driven design (DDD) is a software design approach that focuses on modeling software to match a domain according to input from that domain's experts. DDD is against the idea of having a single unified model; instead it divides a large system into bounded contexts, each of which have their own model.

---

DDD에서 Ubiquitous Language란 무엇인가?

도메인 전문가, 사용자, 개발자가 모두 같은 용어로 소통하도록 정한 공통 언어다. 의사와 간호사가 같은 의학 용어를 쓰듯, 팀 전체가 동일한 단어로 같은 개념을 가리켜야 오해가 줄어든다.

These aspects of domain-driven design aim to foster a common language shared by domain experts, users, and developers—the ubiquitous language. The ubiquitous language is used in the domain model and for describing system requirements. Ubiquitous language is one of the pillars of DDD together with strategic design and tactical design.

---

DDD에서 Entity와 Value Object의 핵심 차이는?

Entity는 고유한 식별자로 구분되는 객체(예: 비행기 좌석 번호)이고, Value Object는 속성 값 자체가 중요한 객체(예: 명함의 정보)이다. 좌석은 번호가 다르면 다른 좌석이지만, 명함은 같은 내용이면 어느 장이든 동일하게 취급한다.

An entity is an object defined not by its attributes, but its identity. As an example, most airlines assign a unique number to seats on every flight: this is the seat's identity. In contrast, a value object is an immutable object that contains attributes but has no conceptual identity. When people exchange business cards, for instance, they only care about the information on the card (its attributes) rather than trying to distinguish between each unique card.

---

DDD에서 Aggregate란 무엇이며, 왜 외부에서 루트만 참조하도록 제한하는가?

Aggregate는 관련 객체들을 하나의 대표(루트)를 통해 묶은 그룹이다. 자동차를 운전할 때 엔진, 브레이크, 헤드라이트를 개별 조작하지 않고 운전대와 페달로만 제어하듯, 외부에서는 루트만 접근하여 내부 일관성을 보장한다.

Models can be bound together by a root entity to become an aggregate. Objects outside the aggregate are allowed to hold references to the root but not to any other object of the aggregate. The aggregate root checks the consistency of changes in the aggregate. Drivers do not have to individually control each wheel of a car, for instance: they simply drive the car. In this context, a car is an aggregate of several other objects (the engine, the brakes, the headlights, etc.).

---

DDD는 모든 프로젝트에 적합한가?

DDD는 복잡한 비즈니스 로직이 있는 프로젝트에서 빛을 발하지만, 단순한 프로젝트에 적용하면 오히려 불필요한 설계 비용이 든다. Microsoft도 도메인이 복잡하고 공통 이해가 필요한 경우에만 권장한다.

Critics of domain-driven design argue that developers must typically implement a great deal of isolation and encapsulation to maintain the model as a pure and helpful construct. While domain-driven design provides benefits such as maintainability, Microsoft recommends it only for complex domains where the model provides clear benefits in formulating a common understanding of the domain.