도메인 기반 디자인 (DDD)이란 무엇입니까? [닫은]


276

DDD (Domain Driven Design)가 기사에서 많이 사용되는 것을 계속보고 있습니다. DDD에 대한 Wikipedia 항목을 읽었지만 실제로는 무엇이고 어떻게 사이트를 만들 때 어떻게 구현해야하는지 알 수 없습니까?

답변:


595

첫째, 필요한 것을 모른다면 필요하지 않을 수 있습니다. DDD로 해결되는 문제점을 인식하지 못하면 해당 문제점이없는 것일 수 있습니다. DDD 옹호자들조차도 DDD가 대규모 (> 6 개월) 프로젝트만을위한 것이라고 지적합니다.

이 시점에서 여전히 읽고 있다고 가정하면 DDD에 대한 나의 견해는 다음과 같습니다.

DDD는 소프트웨어를 실제 시스템 또는 프로세스의 모델로 만들려고합니다. DDD 를 사용할 때는 실제 시스템의 작동 방식을 설명 할 수 있는 도메인 전문가 와 긴밀히 협력해야 합니다. 예를 들어 경마에 베팅하는 것을 처리하는 시스템을 개발하는 경우 도메인 전문가는 숙련 된 북 메이커가 될 수 있습니다.

자신과 도메인 전문가 간에 유비쿼터스 언어 (UL) 를 구축합니다.이 언어 는 기본적으로 시스템에 대한 개념적 설명입니다. 아이디어는 도메인 전문가가 시스템을 읽고 시스템이 올바른지 확인할 수있는 방식으로 시스템이 수행하는 작업을 기록 할 수 있어야한다는 것입니다. 우리의 베팅 예제에서 유비쿼터스 언어는 'race', 'bet', 'odds'등과 같은 단어의 정의를 포함합니다.

UL이 설명하는 개념은 객체 지향 디자인의 기초를 형성합니다. DDD는 개체의 상호 작용 방식에 대한 명확한 지침을 제공하고 개체를 다음 범주로 나누는 데 도움을줍니다.

  • 하위 개체가있을 수있는 값을 나타내는 값 개체 (예 : 날짜는 일, 월 및 연도 일 수 있음)
  • 엔티티 ( identity)를 가진 오브젝트입니다 . 예를 들어, 각 고객 개체에는 고유 한 ID가 있으므로 이름이 같은 두 명의 고객이 같은 고객이 아님을 알고 있습니다
  • 집계 루트는 다른 객체를 소유 한 객체입니다. 이것은 복잡한 개념이며 소유자가없는 한 의미가없는 일부 개체가 있다는 점을 기반으로 작동합니다. 예를 들어 'Order Line'오브젝트는 'Order'가 없으면 의미가 없으므로 Order는 집계 루트이며 Order Line 오브젝트는 Order 오브젝트의 메소드를 통해서만 조작 할 수 있습니다.

DDD는 또한 여러 패턴을 권장합니다.

  • 저장소의 지속성 패턴 (일반적으로 데이터베이스와 데이터를 저장하고로드)
  • 팩토리 , 객체 생성 패턴
  • 도메인 자체의 일부가 아닌 기본 도메인 객체를 조작하는 객체를 생성하기위한 패턴 인 서비스

이제이 시점에서 이러한 것들에 대해 들어 본 적이 없다면 마감 기한이있는 프로젝트에서 DDD를 사용해서는 안된다고 말해야합니다. DDD를 시도하기 전에 디자인 패턴엔터프라이즈 디자인 패턴에 익숙해야합니다 . 이것들을 알면 DDD를 이해하기가 훨씬 쉬워집니다. 그리고 위에서 언급했듯이 InfoQ에서 제공 하는 DDD에 대한 무료 소개가 있습니다 (DDD에 대한 토론도 볼 수 있음).


33
와우 ... 정말 좋은 답변입니다! 매우 감사하고 가장 좋은 설명은 어디서나 읽었습니다. 고마워. 내일 그 책을 다운로드 할게
leen3o

3
"집단 뿌리는 다른 객체를 소유 한 객체입니다. 이것은 복잡한 개념이며 소유자가없는 한 이해가되지 않는 일부 객체가 있다는 점을 바탕으로 작동합니다." "전체 가치"인 반면 집계는 모든 비즈니스 불변 규칙을 적용해야하는 트랜잭션 경계에 더 관심이 있습니다.
super1ha1

6
솔직히 말해서 이것은 개발자가 한 달 이상 건축가와 협력하는 거의 모든 프로젝트처럼 들립니다. (적어도 내 경험에 따르면.) 어느 실현이 당신의 대답을 훨씬 더 높이 평가하게 해줍니다. :)
Jaroslav Záruba 5

4
DDD가 "대규모 프로젝트만을위한 것"이라는 진술에 동의하지 않습니다. DDD는 당신이 완전히해야하거나 전혀하지 말아야 할 것이 아닙니다. DDD에서 몇 가지 사례를 수행 할 수 있습니다. 예를 들어 "Value Objects"와 "ubiquitious language"를 수행 할 수 있으며 소규모 프로젝트에서는 근본을 집계 할 수 없습니다.
EasterBunnyBugSmasher

6
그건 그렇고, 우리가 수행하거나 모델링하는 모든 프로젝트에 대해 도메인 분석을 수행하지는 않습니다. 우리는 이미 프로젝트 영역과 범위를 이해하기 위해 고객 및 중소기업과 BA로서 대화를 끝내지 않았습니까? 나는 여전히 DDD에서 다른 뛰어난 소프트웨어 개발 프로젝트가 무엇인지 이해하지 못합니까?
초신성

51

StackOverflow를 예로 들어 보겠습니다. 일부 웹 양식을 디자인하기 시작하지 않고 먼저 사용자, 질문, 답변, 투표, 의견 등과 같은 문제 도메인 내의 개체에 대한 객체 지향 모델링을 수행하는 데 집중합니다. 도메인을 도메인 기반 디자인 이라고 합니다 .

Eric Evans의 책 에서 자세한 내용을 읽을 수 있습니다 .


5
Eric Evans의 짧은 책 이 무료로 제공 됩니다.
troelskn

문제는 웹 페이지를 사용하기 전에 유용한 것을 말할 수있을 정도로 도메인을 방해하는 방식으로 도메인을 이해하는 사람이 필요하다는 것입니다! 이것이 대단
Ian Ringrose

3
그러나 누가 정직하게 양식을 설계하여 시작합니까? 존경 할만한 모든 학업 과정은 비즈니스 요구 사항에 따라 분석, 설계 및 모델링 응용 프로그램을 거칩니다. 나는이 기술로 새로운 것을 얻지 못합니다.
Sebas

6
저도이 개념이 시작되기 전에 모든 사람이 사용하는 단순한 객체 지향 디자인입니다. 여기에 새로운 발명품이 없습니다.
Ronen Festinger

2
@RonenFestinger는이 답변으로 만 DDD를 판단하지 마십시오. Eric Evans의 책에는 많은 통찰력이 있습니다. 예를 들어 제한된 컨텍스트. 경계 컨텍스트 패러다임은 오늘날 우리가 구축하고있는 마이크로 서비스의 기둥 중 하나입니다. 이 책을 읽으면 마이크로 서비스 이해에 도움이됩니다.
Kerem Baydoğan
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.