3
저는 회사에서 대부분의 LOB 항목을 관리하는 응용 프로그램을 구축하고 있습니다. DDD에서 머리를 감싸려고 노력 중입니다. 고객 관리부터 시작합니다. 많은 예제는 도메인 모델과 관련하여 매우 도움이되지 않는 매우 간단합니다.DDD 고객, 연락처 및 주소 (집계 루트)
내 집계 루트는 주소록 (주소록), 연락처 모음 및 통신 기록 모음을 포함하는 고객 클래스입니다.
주소록, 연락처 (전화 번호 x 개를 가질 수 있음) 및 통신 기능을 갖춘이 집계 루트가 거대한 것 같습니다.
E.G.
UpdateCustomerName(...)
SetCustomerType(...) // Business or individual
SetProspect(...) // if the customer is a prospect
SetDefaultPaymentTerms(...) // line of credit, etc. for future orders
SetPreferredShippingMethod(...) // for future orders
SetTaxInfo(...) // tax exempt, etc.
SetCreditLimit(...)
AddAddress(...)
RemoveAddress(...)
UpdateAddress(...)
VerifyAddress(...)
SetDefaultBillingAddress(...)
SetDefaultShippingAddress(...)
AddContact(...)
UpdateContact(...)
RemoveContact(...)
SetPrimaryContact(...)
AddContactPhoneNumber(...)
RemoveContactPhoneNumber(...)
UpdateContactPhoneNumber(...)
AddCommunication(...)
RemoveCommunication(...)
UpdateCommunication(...)
etc.
나는 값 개체가 신원을 가지고 있지 않다는 것을 읽었습니다. 이 시스템에서 각 (데이터베이스의) 주소는 ID를 가지며 customerId를 외래 키로 갖습니다. Address가 자신의 집계 루트 인 경우 기본 청구/출고를 설정하는 데 비즈니스 로직을 사용할 수 없습니다. 많은 예제는 ID가없는 값 객체를 가지고 있습니다 ... 나는 그것없이 Customer 테이블의 변경 사항을 유지하는 방법을 모릅니다.
누구나 내 구조가 잘못된 길을 지나가고있는 것처럼 느껴진다. 누구나 비슷한 것을합니까? 구조를 분석하고 기본 비즈니스 규칙을 유지하는 방법 (주소가 고객에게 기본 청구 또는 운송으로 설정되기 전에 할당되었는지 확인하는 방법)을 잘 모릅니다.
위대한 설명. 고맙습니다. –
이제 별도의 경계 컨텍스트에서로드 된 데이터 모델간에 동기화하는 방법을 알아야합니다 (이벤트 소싱을 사용하지 않고 있음). E.G. 대금 청구 고객 도메인 모델에는 주소 목록이 있어야 할당되는 기본 대금 청구 주소가 실제로 존재합니다 ... 그러나 주소는 고객 서비스의 제한된 컨텍스트에서 관리됩니다 –
업데이트 기능은 해당 업데이트가 발생하는 컨텍스트에 있어야합니다 . 요점은 기본 청구서 수신 주소를 채우기위한 등록 정보 만있는 청구 컨텍스트 모델을 작성할 수 있다는 것입니다. 결제 환경에 업데이트가 없으면 해당 기능이 필요 없습니다. – Larry