도메인 기반 디자인 : 비즈니스의 도메인 및 하위 도메인 정의

Question

내 모델의 도메인, 하위 도메인 및 한정된 컨텍스트를 정의하는 데 올바른 세분성을 찾는 데 문제가 있습니다.

공구 제조업체의 도메인에서 핵심 도메인은 "생산"이고 하위 도메인은 "Sales", "Finance", "예비 부품"및 "딜러 관리"입니다. 딜러 관리 시스템은 하위 도메인 "딜러 관리"내에서 제한된 컨텍스트가 될 수 있습니다.

그러나 프로젝트에서 딜러 관리 시스템을 개발하는 "딜러 관리"는 비즈니스 도메인으로 정의됩니다. 여기 핵심 도메인은 "소매 업체 네트워크", 하위 도메인 : "계약 관리", "활동"및 "소매 업체 관리"입니다. 핵심 도메인 "소매점 네트워크"의 한정된 컨텍스트는 "딜러 사이트"및 "지역"입니다.

예를 들어 전체 비즈니스의 하위 도메인 (소매업 자 관리)은 도메인으로 정의되고 하위 도메인으로 분리됩니다.

이 내용이 정확하고 도메인을 정의하는 것이 원근법의 문제입니까, 아니면 개념이 잘못 되었습니까?

Answer 1

의견 작성자 @AlexeyZimarev는 도메인 및 경계의 정의가 올바른지 여부를 전적으로 비즈니스 이해에 따라 결정했습니다. 우리는 여기서 실제로 할 수 없습니다.

그러나 적어도 경계 컨텍스트 (== microservices)을 만드는 데 도움이되는 기술적 인 신조를 제공하고 싶습니다.

제한된 컨텍스트는 비즈니스 논리를 실행하기 위해 다른 컨텍스트와의 동기식 통신이 필요하지 않아야합니다.

그리고 저는 동기식 기술을 의미하지 않습니다. 컨텍스트간에 비동기 메시징 시스템이 있지만 컨텍스트가 응답을 기다려야하는 경우에는 여전히 동기식입니다.

다른 모든 컨텍스트가 제거되면 (서비스가 중지되면) 제한된 컨텍스트가 여전히 작동해야합니다.

저는 이것이 어려운 부분이라고 생각하고, 도메인으로 그룹화하고, 어느 것이 핵심 도메인인지, 어떤 것을 지원하는지 등을 결정하는 것이 기술적 인 작업이 아닙니다.

참고 : "판매 업체 관리"및 "계약 관리"는 일반적으로 번 한정된 문맥에 대한 개의 후보입니다. 다른 컨텍스트가 "계약"또는 "딜러"와 함께 작동해야하는 경우 대개 동기 통신입니다. 그들은 계약을 "얻어야"하고 계약으로 뭔가를해야합니다. 이것은 컨텍스트가 실제로 제한되지 않음을 의미합니다.