소프트웨어의 진정한 복잡성은 기술이 아닌 도메인(Domain, 비즈니스 본질) 그 자체에 있습니다.
기획자와 개발자가 각자의 언어로 이야기할 때 발생하는 "우리가 원하는 건 이게 아닌데..."라는 치명적인 소통 오류를 원천적으로 제거하기 위해 도입합니다. 비즈니스 규칙이 코드에 명확하게 반영되므로 요구사항이 변할 때 수정 범위를 쉽게 파악하고 유연하게 대응할 수 있습니다.
DDD의 한계와 초기 투자 비용
단순한 데이터 입출력(CRUD) 위주의 시스템에는 과도한 오버엔지니어링이 될 수 있으며, 도메인을 깊이 이해하고 모델을 구축하는 초기 시간 투자가 반드시 필요합니다.
DDD는 거대한 시스템의 복잡성을 관리하기 위해 전체 도메인을 독립적인 문제 영역인 **바운디드 컨텍스트(Bounded Context)**로 분리하며, 이는 현대의 **마이크로서비스(Microservice)**와 1:1로 강하게 상관 관계를 맺습니다.
상품(Product) 도메인에서는 다음 5가지 방식으로 전략과 전술이 적용됩니다.
displayProduct()라는 코드와 일치하는 단일 용어를 사용합니다.Product 객체는 상품명이 변경되더라도 고유 식별자(productId)가 같으면 동일한 상품으로 인식하고 추적합니다.Money)은 금액이나 통화 속성이 다르면 완전히 새로운 객체이므로, 내부 값을 수정하지 않고 통째로 교체합니다.Product(루트 엔티티)와 ProductOption(내부 객체)을 하나의 트랜잭션 단위로 묶고, 옵션 변경은 반드시 루트를 통해서만 제어합니다.출처: https://blog.kakaocloud.com/193
출처: https://learn.microsoft.com/ko-kr/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/ddd-oriented-microservice