DDD와 관련하여 경계 컨텍스트는 무엇입니까?

본 버논 (Vaughn Vernon)의 "도메인 구동 설계 구현"책을 통해 작업 할 때, 제한된 컨텍스트가 실제로 무엇인지 잘 이해하지 못했습니다.

이 책은 경계 된 문맥을 "도메인 모델이 적용되는 개념적 경계로 정의합니다. 팀이 말하고 정교하게 설계된 소프트웨어 모델로 표현 된 유비쿼터스 언어"( "본 안내서 안내서"섹션)를 정의합니다. 이 정의는 경계 컨텍스트가 하위 도메인의 모델 및 언어 인 것처럼 들리게합니다. 여기서 해당 하위 도메인은 핵심 도메인이 될 수 있습니다 ( "핵 하위 도메인"이라고 함). 다른 토론 ...). 이것은 여전히 ​​제한된 컨텍스트가 제공하는 것에 대해 약간의 모호성을 남깁니다. 하나 이상의 하위 도메인으로 구성된 그룹입니까? 하나의 하위 도메인 만 제한된 컨텍스트에 해당하는 경우 실제로 제한된 컨텍스트는 무엇입니까?

그러나 같은 책의 3 장에서는 경계 컨텍스트 간의 통합 기술을 참조합니다. 그러나 이것은 제한된 맥락이 실제로 소프트웨어 시스템이거나 다양한 다양성의 인공물임을 암시하는 것처럼 보인다.

마틴 파울러 (Martin Fowler)는 바운드 컨텍스트 ( http://martinfowler.com/bliki/BoundedContext.html ) 의 개념에 대해 간략히 설명 하지만 실제로 문제를 명확 하게 설명 하지는 않습니다.

하루가 끝날 무렵 , 제한된 맥락 은 무엇 입니까? 하위 도메인 그룹입니까? 하위 도메인의 모델과 언어는 무엇입니까? 하위 도메인의 구현? 이러한 답변이 없으면 실제 문제 공간을 경계 컨텍스트로 분해하는 방법을 이해하기가 다소 어려워 보입니다.

경계 컨텍스트와 하위 도메인은 다른 수준으로 존재합니다.

하위 도메인 문제 공간의 일부분, 그것의 인 천연 분할 종종 조직의 구조를 반영하는 시스템. 따라서 물류 및 운영 은 송장 및 청구와 분리 될 수 있습니다 . Eric 은 주어진 시나리오에서 비즈니스 관련성에 따라 핵심 , 지원 및 일반 하위 도메인을 차별화 합니다.

컨텍스트 는 솔루션 공간의 일부입니다. 그들은 모델 입니다. 그것들을 갖는 것이 좋을 것입니다. 도메인-하위 도메인 파티셔닝을 반영하십시오 ... 그러나 인생이 항상 그렇게 쉬운 것은 아닙니다. 그리고 모든 것을 포괄하는 레거시 도메인을 부풀 렸거나 동일한 하위 도메인의 컨텍스트를 더 많이 사용했을 수 있습니다 (예 : 누군가가 구축하는 대체 앱인 기존 레거시 앱).

경계 컨텍스트 를 가지려면 모델과 그 주위에 명시 적 경계가 있어야합니다. 데이터베이스를 사용하여 데이터를 공유하는 많은 데이터 중심 응용 프로그램에서 정확히 누락 된 사항입니다.

그것을 보는 또 다른 직교 방법은 다음과 같습니다. 모든 용어가 하나의 명확한 정의를 갖는 특수한 조건 인 유비쿼터스 언어 는 확장되지 않습니다. 확대할수록 모호성이 더 커집니다. 정확하고 모호하지 않은 모델을 달성하려면 경계를 명시 적으로 정의하고 잘 정의 된 목적으로 단일 경계 컨텍스트 내에있는 많은 작은 유비쿼터스 언어를 말해야합니다. .

Domain Driven Design 기술은 우리가 살고있는 세상의 모델을 만드는 데 도움이됩니다.이 모델은 프로젝트에 관련된 사람들의 마음에 아이디어로 존재합니다.

텔레파시는 아직 초기 단계에 있기 때문에 이러한 아이디어는 단어와 문구를 사용하여 사람들 사이에 전달됩니다.

단어와 문구는 최상의 시간에 모호 할 수 있습니다. 모호성을 줄이기 위해 '문맥'을 사용하여 의미를 명확하게합니다.

사람들이 수년에 걸친 소프트웨어 프로젝트에 깊이 몰두하면 코드로 구워진 변수 이름으로 바뀌는 단어로 바뀌는 아이디어가 나온 맥락을 잊어 버리는 것 같습니다.

초보자는 프로젝트에 도착하여 언어를 사용하고 소비하기 시작합니다. 아마도 사용자 일 수도 있고 개발자 일 수도 있습니다. 그들에게 어떤 맥락이 없다면, 그들은 그들 자신의 삶의 경험으로부터 자신의 맥락 (따라서 의미)을 생각해 낼 것입니다.

이 새로 적용된 컨텍스트는 새로운 개발자가 코드를 리팩터링하거나 개발하는 방법을 안내합니다. 만약 그들이 잘못된 문맥을 적용했다면, 아마도 약간의 잘못된 방향으로 코드를 리팩토링하고 개발할 것입니다. 그러나 약간의 잘못된 방향은 줄 아래로 훨씬 더 큰 문제를 일으킬 수 있습니다.

보시다시피, '바운드 컨텍스트'는 초보자를 영입하기 위해 전달되는 '명확한 컨텍스트'일 뿐이므로, 아름답게 연마 된 모델을 손상시키기 위해 자신의 임의 컨텍스트를 적용하지 않습니다.

그것은 것을 팀에 의해, 일부 명시 적으로 인정하다 this phrase에, this part of the project수단 정확하게 this thing(그리고, 당신이 아니라, 생각 that thing).

정원과 이웃 정원 사이의 경계를 표시하는 것이 좋습니다. 완벽하게 잘 다듬어 진 잔디밭에서 화단을 파기 시작할 때 화를 내지 않도록 경계를 명시 적으로 지정하십시오.

그게 다야. 그것에 대해 많은 글을 썼기 때문에 매우 중요한 아이디어입니다.

네 경계 컨텍스트는 말 그대로 하나의 하위 도메인의 컨텍스트와 프로젝트의 다른 하위 도메인의 컨텍스트를 구별하는 경계인 '울타리'입니다.

하위 도메인의 모델 및 언어는 다른 모델 및 언어와 분리되어 의미가 모호하지 않습니다.

그러나 그렇습니다. 세상은 그렇게 간단하지 않습니다.

귀하와 팀은 정의 된 상황을 엄격히 준수해야합니다. 소프트웨어 구성 과정에서 코너를 자르기 위해 게으르고 상황을 재구성하는 것이 정말 쉽습니다.

또한 사물은 다른 사물과 상호 작용하며, 제한된 컨텍스트는 서로 상호 작용해야합니다. 따라서 이러한 상호 작용이 발생하는 방식을 설명하는 다양한 패턴이 있습니다. 공유 커널, 고객 공급 업체, 준수 자, 부패 방지 계층, 별도의 방법, 공개 호스트 서비스, 공개 언어 등 다양한 패턴에 대해서는 Eric Evan의 책 도메인 기반 설계 14 장을 참조하십시오.

기본적으로 경계 컨텍스트는 일부 하위 도메인의 적용 가능성에 대한 실질적인 경계를 정의합니다. 특정 하위 도메인이 의미가있는 추상 영역이지만 다른 하위 영역은 그렇지 않습니다. 따라서 이것은 대화, 프리젠 테이션, 아티팩트로 정의 된 물리적 경계가있는 코드 프로젝트가 될 수 있습니다.

다른 상황에서는 경계 컨텍스트 개념의 세 가지 관점 또는 은유를 사용합니다.

런타임 관점에서 모델이 구현되는 서비스 계약으로 정의 된 논리적 경계를 나타냅니다. 계약은이 서비스의 API 또는 계약 및 게시 및 소비 이벤트로 표시 될 수 있습니다. 따라서 이러한 관점에서 경계 컨텍스트는 물리적 경계와 관련이 없습니다.

도메인 전문가의 관점에서 경계 컨텍스트는 특정 비즈니스 프로세스가 구현되고 특정 유비쿼터스 언어가 적용되며 특정 용어는 분명한 반면 다른 용어는 그렇지 않은 영역입니다. 종이나 화이트 보드에 그려진 사각형 일뿐입니다.

정적 코드 관점에서 볼 때 소프트웨어 개발자의 경우 경계 컨텍스트는 해당 하위 도메인을 중심으로 내 모델을 설계 한 방식을 나타냅니다. 특정 하위 도메인이 몇 개의 코드베이스로 구현됩니까? 어떤 개념으로 구성되어 있습니까? 각 개념에 적용 할 수있는 개념은 무엇입니까? 이것이 제한된 컨텍스트가 솔루션 공간에 속한다고 말하는 이유입니다.

나는 Bounded Context 개념 의이 예제를 정말 좋아 한다 .

또 다른 중요한 질문은 (가장 중요한 질문이 아닌 경우) 제한된 컨텍스트를 식별하는 방법 입니다. 그렇게 잘못하면 분산 모 놀리 식 (distributed monolith)으로 알려진 유지 보수가 불가능하고 밀접하게 결합 된 서비스가 생길 수 있습니다.