답변:
첫째, 필요한 것을 모른다면 필요하지 않을 수 있습니다. DDD로 해결되는 문제점을 인식하지 못하면 해당 문제점이없는 것일 수 있습니다. DDD 옹호자들조차도 DDD가 대규모 (> 6 개월) 프로젝트만을위한 것이라고 지적합니다.
이 시점에서 여전히 읽고 있다고 가정하면 DDD에 대한 나의 견해는 다음과 같습니다.
DDD는 소프트웨어를 실제 시스템 또는 프로세스의 모델로 만들려고합니다. DDD 를 사용할 때는 실제 시스템의 작동 방식을 설명 할 수 있는 도메인 전문가 와 긴밀히 협력해야 합니다. 예를 들어 경마에 베팅하는 것을 처리하는 시스템을 개발하는 경우 도메인 전문가는 숙련 된 북 메이커가 될 수 있습니다.
자신과 도메인 전문가 간에 유비쿼터스 언어 (UL) 를 구축합니다.이 언어 는 기본적으로 시스템에 대한 개념적 설명입니다. 아이디어는 도메인 전문가가 시스템을 읽고 시스템이 올바른지 확인할 수있는 방식으로 시스템이 수행하는 작업을 기록 할 수 있어야한다는 것입니다. 우리의 베팅 예제에서 유비쿼터스 언어는 'race', 'bet', 'odds'등과 같은 단어의 정의를 포함합니다.
UL이 설명하는 개념은 객체 지향 디자인의 기초를 형성합니다. DDD는 개체의 상호 작용 방식에 대한 명확한 지침을 제공하고 개체를 다음 범주로 나누는 데 도움을줍니다.
DDD는 또한 여러 패턴을 권장합니다.
이제이 시점에서 이러한 것들에 대해 들어 본 적이 없다면 마감 기한이있는 프로젝트에서 DDD를 사용해서는 안된다고 말해야합니다. DDD를 시도하기 전에 디자인 패턴 및 엔터프라이즈 디자인 패턴에 익숙해야합니다 . 이것들을 알면 DDD를 이해하기가 훨씬 쉬워집니다. 그리고 위에서 언급했듯이 InfoQ에서 제공 하는 DDD에 대한 무료 소개가 있습니다 (DDD에 대한 토론도 볼 수 있음).
StackOverflow를 예로 들어 보겠습니다. 일부 웹 양식을 디자인하기 시작하지 않고 먼저 사용자, 질문, 답변, 투표, 의견 등과 같은 문제 도메인 내의 개체에 대한 객체 지향 모델링을 수행하는 데 집중합니다. 도메인을 도메인 기반 디자인 이라고 합니다 .
Eric Evans의 책 에서 자세한 내용을 읽을 수 있습니다 .