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

첫째, 필요한 것을 모른다면 필요하지 않을 수 있습니다. 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에 대한 토론도 볼 수 있음).

답변