전체 루트는 유스 케이스에 따라 다르므로 실제로 많은 저장소가 생성 될 수 있습니다.

Question

Ive는 집계 루트가 유스 케이스에 달려 있다는 것을 많이 들었습니다. 그러나 코딩 컨텍스트에서 그 의미는 무엇입니까?

당신은 저장소에서 무언가를 성취 할 수있는 방법 (유스 케이스)을 유지하는 서비스 클래스를 가지고 있습니다. 따라서 집계 루트와 동일한 저장소를 사용하여 쿼리를 수행하십시오.

이제 첫 번째 서비스 클래스와 완전히 다른 유스 케이스를 사용하지만 동일한 엔티티를 사용하는 다른 종류의 작업을 수행해야합니다. 여기

표현 :

엔티티 : 고객, 주문, LineOrder

서비스 1 : 검색, 일부 고객을 삭제, 새로운 고객을 추가 고객의 주문 여기

집계 루트가 있기 때문에 고객이 될 것 같다 사용 사례를 수행하려면이 저장소가 필요합니다.

서비스 2 : 실제 위해 여기에 집계 루트

에서 고객을 검색하면이 사용 사례를 수행하기 위해이 저장소를 필요로하기 때문에 주문을 것 같다.

내가 잘못하면 저를 시정하십시오. 이제는 집계가 2 개라는 뜻입니다.

이제 내 생각에는 집계 루트가 유스 케이스에 의존하기 때문에 많은 유스 케이스가 생기면 정말 많은 저장소로 끝날 수 있습니다.

위 예제는 아마도 최상의 예제가 아니 었습니다 ... 그래서 JournalEntries를 보유하고있는 Journal에 각각의 항목이 Tasks, Problems and Notes를 보유하고 있다고 가정 해 보겠습니다. (이는 프로젝트에서 수행 된 작업을 시스템에 알려주는 컨텍스트에서입니다.)

결국 저장소가 2 개가 될 것입니까? (Journal, JournalEntry) 저널 항목에서 새 작업, 문제점 및 메모를 추가해야하는 사용 사례가 있습니까? (서비스로 볼 수 있음)

4 개의 저장소가있을 수 있습니다. (Journal, Task, Problems, Notes) 지시 작업에 액세스해야하는 사용 사례에서 문제 및 메모가 있습니까? (다른 서비스로 볼 수 있음)

하지만 두 개의 논문 모두 사용하려면 실제로 5 개의 저장소가 필요하다는 것을 의미합니다. ?

감사합니다.

Answer 1

처음에는 집계 대상을 정의해야합니다. 유스 케이스 집계에 대해서는 모른다. 다음 집계에 대해 알고 있습니다 ...
집계는 여러 항목의 합집합입니다. 엔티티 중 하나는 집계 루트이고 나머지 엔티티 (또는 값 유형)는 선택한 집계 루트 컨텍스트에서만 의미를가집니다.
예를 들어 OrderLine 엔티티에 대해 독립적 인 작업을 수행 할 필요가없는 경우 Order 및 OrderLine을 집합으로 정의 할 수 있습니다. OrderLine은 Order 컨텍스트에서만 의미가 있음을 의미합니다. 집계를 전혀 정의하지 않는 이유는 무엇입니까?객체 간의 참조를 줄여야합니다. 그러면 도메인 모델이 단순 해집니다.
물론 OrderLine이 Order 집계의 일부인 경우 OrderLineRepository가 필요하지 않습니다. 자세한 내용은 link입니다. 에릭 에반스 DDD 책을 읽을 수 있습니다. 그는 집합체를 아주 잘 설명합니다.

Answer 2

안녕하세요 저는 귀하의 게시물을 보았고 귀하에게 내 의견을 알려줄 수 있다고 생각했습니다. 먼저 나는 프로젝트에서 3 년 동안 DDD를 해왔다. 나는 전문가가 아니다. 하지만 저는 현재 DDD의 코칭 개발자로서 건축가로서의 프로젝트를 진행하고 있습니다. 공원에서 산책을하지 않는다고 말해야합니다 ... 모델과 엔터티를 몇 번이나 리팩토링했는지 모르겠습니다. 관계.

그러나 제 경험상 몇 가지 리포지토리 (몇 가지 있지만 많지는 않지만)가 많습니다. 내 집계에는 보통 몇 개의 클래스가 포함되어 있으며 집계 그래프는 그다지 깊지 않습니다 (내 뜻을 아는 경우).

는하지만 구체적으로하려고 :

1) 집계 뿌리는 사용자의 필요에 의해 정의됩니다. 나는 당신이 저널을 통해 Tasks 객체를 자주 필요로한다고 생각한다면, 그 다음에는 그것을 집계 루트로 업그레이드하기위한 서명을 할 것입니다.

2) 그러나 모든 것이 뿌리를 집계 할 수 없으므로 밀접하게 관련된 개체를 캡슐화하십시오. Notes는 루트 객체가 소유하고있는 후보로 보입니다. 아마도 Notes를 루트에 연결 시키거나 컨텍스트를 잃게됩니다. 메모는 그 자체로는 살 수 없습니다.

3) 집합체는 거대한 복잡한 영역을 더 작은 "섬"으로 나누어서 자신의 인류 사회를 돌보는 데 사용됩니다. 도메인을 더 복잡하게 만드는 것이 중요합니다.

4) 프로젝트 구현 단계까지 도달하기 전에 모델이 어떻게 보이는지 알 수 없습니다. 그 중 일부 저장소가 그렇게 많이 사용되지 않는다는 것을 알게되면 다른 루트 개체와 병합 할 후보가 될 수 있습니다 (이러한 종류의 관계가있는 경우). 컨텍스트없이 루트 객체를 통해 너무 많이 사용되는 객체를 분리 할 수 ​​있습니다. 예를 들어 Journal이 집계 루트이고 Notes 및 Tasks를 포함하는 경우를 의미합니다. 잠시 후 모델이 커지고 어쩌면 작업 은 작업 및 작업 기록, 사용자 및 규칙 및 사용 권한과 관련이 있습니다. 이제는 규칙/동작/사용자 권한 기능에서 일반적인 개체를 던집니다. 어쩌면이 결과는 다른 각도에서 Tasks에 접근하는 유스 케이스로 이어질 수 있습니다. "이 사용자가 수행 한 모든 작업보기"등. 작업은 일종의 State/Workflow 엔진에 더 많이 관련되며 그로 인해 집계 루트 자체가 될 수 있습니다.

Okey. 가장 좋은 예는 아니지만 어쩌면 아이디어를 줄 수 있습니다. 루트 객체는 자식을 포함 할 수 있습니다.이 자식의 일부는 루트 객체 일 수 있습니다. 우리는 다른 컨텍스트 (저널보다)에이 객체가 필요할 수 있기 때문입니다. 그러나 나는 신선한 모델로 시작할 때마다 벽에 머리를 두드렸다. 그냥 흐름을 따라 가서 모델이 클라이언트/하위 그룹을 통해 진화하도록하십시오. 사용법을 통해 모델을 구체화합니다. 물론 서비스 (응용 프로그램 서비스 및 도메인 서비스 아님)는 물론 UI 및 용도 (일대일)에 응답하는 방법으로 확장됩니다.

은 내가 어떻게든지에 당신을도 왔습니다 ... 여부를 바랍니다 : D

Answer 3

예, 당신이 가장 가능성이 5 개 저장소 (기사, JournalEntry, 작업, 문제, 노트)로 끝날 것입니다. 그런 다음 서비스는 이러한 저장소를 사용하여 각 유형의 엔터티에 대해 CRUD를 수행합니다.

DDD를 처음 사용하는 개발자의 경우 "너무 많은 저장소"에 대한 사용자의 반응은 드문 일이 아닙니다.

그러나 저장소는 모델과 DB 스키마가 상당히 균등하게 일치한다고 가정 할 때 대개 가볍습니다. nHibernate와 같은 ORM을 사용하거나 codesmith generator와 같은 도구를 사용하면 리파지토리를 더 쉽게 만들 수 있습니다.