분산 도메인 기반 디자인의 값 개체 목록

Question

분산 DDD 응용 프로그램에서 값 개체 목록을 구현하는 데 필요한 구체적인 지침이 필요합니다. 다음은 내가 가지고있는 것입니다.

내 응용 프로그램은 여러 클라이언트 응용 프로그램에 서비스를 제공하는 서버에서 실행되는 RESTful 서비스 응용 프로그램을 기반으로합니다. 내 엔터티 중 하나 인 Customer에는 많은 Region 값 유형 중 하나에 대한 참조가 포함 된 Region 속성이 있습니다. Regions 목록은 백 엔드 데이터베이스에 저장되지만이 목록을 유지 관리하기위한 인터페이스는 제공하지 않습니다. 모든 변경 사항은 데이터베이스에서 직접 작성되며 (드문 경우이므로) 이름 변경 및 추가/제거가 아닌 대부분의 변경이 가능합니다. 새로운 시장으로의 확장과 같은 경우에는 새로운 항목이 추가 될 수 있으므로 목록이 '동적'이어야합니다.

클라이언트 UI 중 하나에서 고객 레코드를 편집 할 때 고객 도메인 개체의 Region 속성과 연결된 선택한 항목이있는 드롭 다운 목록에 지역 목록을 표시해야합니다.

나는 UI 측면을 처리 할 수 ​​있지만 내 도메인 계층에서 영역 목록을 얻고 유지 관리해야하는 방법을 모호하게 다루고 있습니다. 별도의 RegionRepository가 있습니까? 아니면 CustomerRespository에서 목록을 가져와야합니까? 고객이 Value Object를 참조한 유일한 주체 인 경우에는 어떻게해야합니까? 여러 개체가 VO를 참조하면 접근 방식이 변경됩니까?

저는 실제로 이러한 유형의 조회가 많으며 추천하지 않는 한 각각의 저장소에 대해 별도의 저장소 (및 웹 서비스)를 만들고 싶지 않습니다. API에 대한 단일 Lookup 서비스에 대해 생각해 보았지만이 경로에 미치는 영향을 더 잘 이해할 때까지 구현하는 것을 주저합니다.

목록 항목은 '키순'이지만 자체 ID가있는 항목의 정의에 적합하지 않으며 상위 도메인 개체 (이 경우 Customer)의 컨텍스트를 제외하고 존재하지 않습니다. 그래서 저는 그것들이 값 객체라고 가정하고 있습니다. 그러나 다시 말하지만, 클라이언트가 위에서 설명한 것과 같은 시나리오에 대한 VO 목록을 검색 할 수 있도록 앱을 어떻게 구성해야하는지 명확하지 않습니다.

Answer 1

이 문제의 핵심은 한 걸음 물러서서 조회 목록이 실제로 존재하는지 평가하는 것이 었습니다. 예를 들어, 지역 목록은 판매 지역, 지역 등일 수 있습니다.이를 식별하면 일반적으로 목록이있는 다른 컨텍스트 개체로 안내됩니다.

Answer 2

어디서나 사용할 수 있습니다. 재산을 공개하고 저장소를 구현하기로 결정한 곳에서는 DDD의 계약을 위반하지 않습니다. 나는 다음과 같은 사용 예를 들어

:

interface IAddress 
{ 
    List<State> GetStatesByCountry (string country); 
} 

과 나는 또한 나의 경우

interface ITaxes 
{ 
    List<State> GetStates(); 
} 

이 두 가지가 그 특정 백엔드 시스템이 방법은 단순히 때문에 ILookupRepository에 의해 구현 얻을이 디자인. 그러나 우리 시스템 중 다른 시스템에서는 백엔드와 서비스가 위의 시스템과 다르므로 실제 ICountryRepository가 있으며이 시나리오에서는 더 이해하기 쉽습니다.