최상의 집계 루트 및 데이터 저장소 제안

Question

집계 루트를 기반으로 데이터 리포지토리를 구현하려고합니다. 그러나 이것이 최선의 방법인지 잘 모르겠습니다. 귀하의 의견이 필요합니다. 여기

내가 (포함 자신의 차일 아래에 들여 쓰기)과 함께 왔어요 내 시스템의 집계 뿌리입니다

Customer (Has Data Repository) 
    CustomerAccount 
    CustomerAccountPerson 
    CustomerOptions 
    CustomerCustomField 
    CustomerCustomFieldData 
    CustomerFile 
    CustomerNote 
    CustomerLoginLog 
    ..... and more 
Order (Has Data Repository) 
    OrderLineItem 
    OrderStatusLog 
    OrderFlag 
    OrderOutsourcing 
    ..... and more 
Lead (Has Data Repository) 
    LeadNote 
    LeadSource 
    LeadStatus 
    LeadStatusLog 
    ..... and more 
Invoice (Has Data Repository) 
    InvoiceOrder 
    InvoicePayment 

플러스 더 ... 내가 가지고있는 투쟁은 적절한 데이터 저장소 인 경우,이다 집계 루트에 따라 기술적으로 내가 고객 저장소에 주문 저장소를 사용하고 고객과 주문에 대해 두 개의 별도 리포지토리가 있어야하는 대신 고객에게 주문이 포함되어 있어야합니다.

고객 및 주문 데이터 저장소 아래의 많은 수의 하위 테이블/항목 때문입니다. 이토.

저는 데이터 저장소를 디자인 할 때 다른 사람들이 어떻게 이런 상황을 어떻게 처리 할 것인지, 그리고 그들이 나를 위해 가질 수있는 다른 제안을 듣는 것에 정말로 관심이 있습니다.

미리 감사드립니다.

Answer 1

사용 사례를 모른 채 말할 수 없습니다.

집합 루트는 작업을 전체적으로 실행할 수있는 논리 단위를 나타냅니다.

주문이 독 립적 일 수 있다면 집계 루트 여야합니다. 할 수 없다면, 그렇게해서는 안됩니다. 예 : LineItem은 순서를 벗어난 의미가 없습니다. 그러나 일반적으로 주문은 고객 개체없이 사용할 수 있습니다. 귀하의 운송 부서는 고객과 상관없이 선적 된 주문을 표시 할 수 있으므로 일반적으로 AR입니다.

DDD (좋음 또는 나쁨)를 수행하려고하면 설계가 기본 데이터 기술 및 테이블 레이아웃으로 인해 이루어지지 않아야합니다. 누가 RDBMS를 사용해야한다고 말합니까?

DDD에 관한 책은 물론 Eric Evans의 "도메인 중심 디자인"으로 사람들이화물 숭배 DDD를 시작할 때 흔히 잃어버린 많은 컨텍스트를 제공합니다.

지미 닐슨 (Jimmy Nilsson)의 "도메인 기반 디자인 및 패턴 적용"서적도 자주 권장되지만, 개인적으로는 그리 만족스럽지 않습니다.

DDD는 비즈니스 규칙이 많고 엔터티 상태에서 인코딩되지 않은 동작/논리가있는 복잡한 도메인이있는 경우에 유용합니다. 대부분의 어플리케이션은 그보다 훨씬 간단하며 더 나은 디자인 대안이 있습니다.

마틴 파울러 (Martin Fowler)의 탁월한 책 "엔터프라이즈 응용 프로그램 아키텍처의 패턴"을 읽는 것이 좋습니다. 이것은 DDD 서적보다 넓은 영역을 다루고 응용 프로그램 동작을 처리하고 백엔드에서 GUI까지 모든 응용 프로그램 계층을 처리하는 데 유용한 방법을 제공합니다 .