경계 컨텍스트의 경계를 명확하게 정의하는 방법

한 달 정도 DDD를 읽고 연구 한 후, 나는 내 자신의 프로젝트를 시작하기로 결정하고 이러한 제한된 맥락으로 DDD를 만들었습니다.>

• 고객
• 제품
• 명령
• 청구

각 경계 컨텍스트에는 프리젠 테이션 계층, 도메인 계층, 영구 계층으로 나머지 API가 있습니다.

지금까지는 코드가 원활하게 실행되지만 모 놀리 식 세계에서 왔지만 여전히 다음을 알아 내려고 노력하고 있습니다.

• 새 고객을 만들려면 새 인보이스를 발행하고 새 주문을 작성하십시오 (예 : 국가 목록 액세스). 나는 :

a) BC 주마다 국가 목록을 작성하십시오.

b) 국가 BC-> API를 작성하여 사용 가능한 국가 목록을 얻는 데 사용하십시오.

c) 타사 API를 사용하고 각 BC에서 반부패 계층을 통해 데이터를 가져옵니다.

• 반부패 계층 또는 어댑터 계층을 사용하여 타사 API와 통합 할 때 도메인 모델에 어떤 데이터를 포함해야합니까? 예를 들어 zendesk API를 Client BC와 통합하려는 경우. 내 도메인에 ticketID 만 있으면됩니까, 아니면 클라이언트 BC에서 액세스하고 사용하려는 Zendesk에서 모든 데이터를 추출해야합니까?

내 MVC 앱이 실제로 API (제한된 컨텍스트의 표현 계층)에서 데이터를 가져 오는 경우 각 BC의 경계를 명확하게 정의하는 것이 매우 어렵다는 것을 알았습니다. 제대로 설계된 BC가 추가 API를 소비 할 필요없이 단일 MVC 컨트롤러를 제공한다는 의미입니까?

서로 다른 경계 컨텍스트가 국가의 의미 / 목적을 다르게 이해하는 경우 각 국가마다 다르게 다르게 모델링해야합니다. 그러나 우리가 단순히 ISO 코드와 이름의 참조 데이터에 대해 말하고 있다면, 편리한 곳이라면 어디든 보관하고 모든 이해 당사자가 액세스 할 수 있도록 만드는 것이 공정하고 표준 적이라고 생각합니다. 예를 들어 : 데이터베이스, 구성 파일, 웹 서비스 등

나는 또한 당신의 모델을 조금보고 싶었습니다. 회사의 구조에 따라 하나의 "제한된 컨텍스트"에서 "엔티티"가 될 수 있습니다. BC주는 종종 "유비쿼터스 언어"사이의 자연 경계이기 때문에 여러 지역 / 부서 / 팀 주위에 정의되는 경우가 많습니다. 예를 들어, 판매 / 제품 / 주문 대신 BC 주가 판매 / 제조 / 창고 라인을 따라야합니다.

BC 주에서는 명사에 초점을 맞추지 않습니다. 유스 케이스에 중점을두고 유스 케이스를 수행 할 수있는 명사의 모델을 작성합니다. "집계 루트"의 메소드는 유스 케이스를 실행하고 관련 모델을 적절히 변경합니다.

... 모든 모델이 잘못되었지만 일부 모델이 유용합니다.

또한 각 BC는 완전히 다른 시스템 또는 아키텍처를 사용할 수 있습니다. 주어진 BC 주에서는 "DDD 소프트웨어 구성 요소"를 전혀 사용하지 않을 수 있으며 대부분 그렇지 않을 수도 있습니다. DDD는 규범적인 소프트웨어 구성 요소가 아니라 소프트웨어 설계 프로세스에 대한 것입니다. 요점은 회사의 제한된 컨텍스트를 이해하고 각 컨텍스트의 유비쿼터스 언어를 매핑하고 유비쿼터스 언어를 사용하여 해당 컨텍스트의 코드를 모델링하는 데 중점을 둡니다. 그렇게하면 스테이크 소유자와 상호 작용하고 코드를 참조 할 때 이해하는 비즈니스 용어로 말하는 것처럼 들립니다. 그리고 같은 단어가 다른 BC 주에서 다른 의미를 가지고 있음을 인식합니다.

DDD (예 : 리포지토리, 특정 계층화 등)에 의해 발생하는 특정 패턴이 있습니다. 그러나 이러한 패턴이 DDD 내에서도 모든 경우에 가장 적합한 패턴 인 것은 아닙니다. DDD가 모든 프로젝트에 "답"인 것은 아닙니다. 당신은 당신의 분석이 제안하는 것이 가장 실용적인 일을해야합니다.

당신의 질문에서, 나는 당신이 제한된 맥락을 오해한다고 생각합니다. 당신은의 제 14 장 다시 읽도록 할 수 있습니다 파란색 책을 .

일반적으로 답변을 시도-두 개의 서로 다른 경계 컨텍스트간에 개념을 공유하는 데주의해야합니다. 결국 경계가 존재하는 이유 중 일부는 유비쿼터스 언어가 변하기 때문입니다. 엔티티의 동일한 데이터 (및 동일한 표현)가 두 컨텍스트에서 모두 사용될 수 있다고 가정하는 것은 순진합니다. 맞을 수도 있고 틀릴 수도 있지만 액세스 권한이없는 외부의 사람들에게는 좋은 방법이 없습니다. 도메인 전문가에게 판단합니다.

예를 들어 클라이언트 도메인에서 "국가"는 거주 또는 시민권과 관련이있을 수 있습니다. 청구시 환율과 관련이있을 수 있습니다. 이러한 도메인 중 일부에서는 관세 등에 대해 걱정해야 할 수도 있습니다.

두 번째로 제기해야 할 질문은 어떤 모델이 "공유 된"데이터에 대한 기록 일지입니다. "국가"의 경우 정답은 아마도 그들 중 누구도 아닐 것입니다! 지정 학적 토폴로지는 모델에 의해 제어되지 않습니다.

국가가 외국 권력에 의해 점령 될 때 도메인 모델에서 어떤 일이 발생합니까?

명심하십시오; 우리 중 많은 사람들이 데이터 구조에 대해 생각하는 데 익숙합니다. 한 데이터와 다른 데이터의 관계는 무엇입니까? 보고서를 고려하고 필요한 모든 데이터가 솔루션에 의해 수집되도록하려는 경우 유용합니다. 그러나 도메인 모델은 단순한 구조가 아니라 변화에 관한 것입니다. 그 부분에도주의를 기울여야하며, 데이터가 변경을 제한하는 방법 (및 제약 조건이 경계 컨텍스트마다 어떻게 다른지)을 잘 이해해야합니다.

언급 한 개념 (클라이언트, 제품, 주문, 청구)은 일반적으로 단일 도메인 모델로 표시되므로 경계 컨텍스트로 표시됩니다. 이러한 개념을 잘못 이해하고있는 것이 좋습니다.

이 주제에 대한 나의 견해 는 비즈니스 기능 매핑 또는 기타 가치 사슬 분석과 같은 유사한 기술을 사용하여 제한된 컨텍스트 를 정의 하는 것입니다. 다음 단계로 진행됩니다.

1. 시스템의 높은 수준의 책임 또는 비즈니스 기능을 정의하십시오. 내가 생각하는 가장 좋은 방법은 기업이 비즈니스 가치를 얻기 위해 겪는 단계와 결합하는 것입니다. 논리적 경계는 비즈니스 서비스 또는 원하는 경우 경계 컨텍스트입니다.
2. 각 서비스 내에서 더 깊이 탐구하십시오.
3. 처음 두 지점과 함께 서비스 간 통신을 식별하십시오.

따라서 초기 비즈니스는 비즈니스 운영 방식에 중점을 둡니다.

실용적인 조언 :

1. 컨텍스트 / 서비스 / 등 중 하나에 다른 컨텍스트의 데이터가 필요한 경우 경계가 잘못되었을 가능성이 큽니다.
2. 매우 바람직한 컨텍스트 통신 방법은 이벤트 기반입니다. 이것이 확장 성과 신뢰성의 열쇠입니다. 동기식 통신이 필요한 경우 경계가 잘못되지 않은 것 같습니다. 게다가, 동기식 통신은 시스템을 종료시킵니다.
3. 귀하의 도메인은 생각보다 더 일관성이 있습니다. 다른 사람들처럼. 모든 것을 100 % 일관성있게 만들려고하지 마십시오. 실질적인 의미는 없습니다.
4. 컨텍스트는 조정될 필요가 없습니다. 그들은 독립적입니다. 인간처럼.

이 접근 방식을 사용하면 자율적이고 유지 관리가 가능하며 안정적인 서비스가 제공됩니다. 컨텍스트 경계를 정의 하는 예제 를 확인할 수 있습니다 .