매퍼 컨텍스트 수퍼 컨텍스트 : 도메인 별 및 도메인 일반 바운드 컨텍스트 분리

(2019 년 8 월 1 일)

새 시스템을 구축하고 있으며 두 팀원이 알림을 보내기위한 대체 아키텍처를 제안합니다. 어느 것이 맞습니까?

첫 번째 개발자는 푸시 모델을 제안합니다. 경계가있는 컨텍스트는 알림 컨텍스트에 알림을 보내도록 지시해야합니다. 알림 컨텍스트 (알림)는 다른 컨텍스트의 명령을 따르고 지시가있을 때 알림을 보내야합니다.

두 번째 개발자는 푸시 모델을 싫어하고 안무 된 솔루션을 제안합니다. 제한된 컨텍스트가 이벤트를 발생시키는 경우 알림은 수신하고 알림을 보낼시기를 결정해야합니다.

솔루션을 어떻게 설계 하시겠습니까? 더 중요한 것은 팀에서이 결정을 어떻게 해결 하시겠습니까? 단기 목표와 장기적인 발전을 지원하는 가장 효과적인 아키텍처를 어떻게 설계 하시겠습니까?

팀에서 DDD 기술을 보유하는 것이 주요 이점입니다. 핵심, 지원 및 일반 기능을 이해하기 위해 도메인을 분석 할 수 있으면 건전한 엔지니어링 트레이드 오프를 만들 수 있습니다.

DDD 관점에서이 시나리오를 자세히 살펴 보겠습니다.

도메인 기능 분석

옵션 1 (푸시 된 명령)의 주장은 일반 (알림)이 특정 항목에 의존해서는 안된다는 것입니다. 어떤 것이 여러 도메인에 걸쳐 일반적인 경우 단일 도메인의 어떤 것과 결합되면 논리적으로 잘못된 것입니다.

추상적 인 추론을 넘어서 보면이 발견 적 경고는 무엇에 대한 것입니까? 우리가 알아야 할 엔지니어링 결과는 무엇입니까?

피하고 싶은 두 가지 시나리오가 있습니다.

  1. 도메인 특정 로직이 일반 컨텍스트로 누출되어 co가 발생하는 것을 방지합니다. -change
  2. 도메인 특정 경계 컨텍스트와 너무 밀접하게 결합되어있어 일반 컨텍스트를 재사용하거나 기성 솔루션으로 대체 할 수 없음

도메인 및 일반 책임 결합

옵션 1을 사용하면 도메인 별 API와 도메인 일반 API간에 공동 변경이 없습니다. 새 알림이 필요한 경우 도메인 별 컨텍스트 만 변경됩니다. 그러나 이것은 옵션 2의 경우가 아닙니다.

옵션 2 (안무)를 사용하면 알림이 필요한 새 이벤트가 도입되면 도메인 별 API가 새 이벤트와 알림 서비스를 게시해야합니다. 이벤트를 구독하고 알림을 보내야합니다. 이것은 옳지 않다고 생각합니다. 도메인에 대한 지식이 일반적인 컨텍스트 안에 숨어 있습니다.

일반 기능 분리

알림 서비스가 진정으로 일반적이고 많은 팀에서 재사용되거나 수백 개의 도메인 이벤트에 대해 알아야합니다. 그리고 알림 컨텍스트에 의존하는 팀이 너무 많기 때문에 조직 전체에서 재사용 가능성을 줄이는 병목 현상이 발생할 것입니다.

디자인 피드백의 또 다른 부분은 일반적인 컨텍스트를 다음으로 대체 할 수 없다는 것입니다. 기성 솔루션. 실제로 많은 도메인에서 일반적이지만 더 많은 기능을 제공하고 실행 비용이 더 적은 기성 솔루션으로 대체 할 수없는 경우 설계는 무언가 잘못되었다는 피드백을 제공합니다.

특정에서 일반으로의 명령이 모범 사례입니까?

모든 증거는 옵션 1이 정확함을 시사합니다. 도메인 별 컨텍스트는 도메인 논리에서 분리하기 위해 도메인 별 컨텍스트로 명령을 보내야합니다. 그러나 우리의 분석은 얕았습니다. 우리는 좋은 엔지니어링 선택을하고 있다는 확신을주기 위해 도메인을 더 분석해야합니다.

심층 도메인 분석

옵션 1 (특정 지침은 일반 지시), 모든 도메인을 더 자세히 살펴 봅니다. 알림을 보내야하는 특정 컨텍스트에 추가 책임이 있습니다. 알림을 보낼시기와 보낼 알림 유형을 알아야합니다.

모든 제한된 컨텍스트에 알림 로직을 분산시키는 것이 합리적입니까? 얽힌 코드와 함께 이는 알림 접근 방식이 변경 될 경우 많은 팀간에 대규모 조정을 의미 할 수 있습니다.

각 팀이 알림에 대한 자체 접근 방식을 채택하면 위험이나 불일치 및 중복 / 낭비가 증가합니다. 공유 라이브러리는 가능성이 있지만 모든 문제를 해결하지 못하고 타협도 가져옵니다.

일부 도메인 개념은 명확하게 분할되지만 (빨간색, 회색, 노란색 삼각형, 파란색 원) 일부는 서로 다른 차원에 걸쳐 겹치며 여러 방법으로 분류 될 수 있습니다 (파란색 삼각형)

책임이 한 컨텍스트에 속해야하는지 다른 컨텍스트에 속해야하는지 결정하는 데 어려움이있을 때마다, 확대하고 책임을 더 분해하십시오. 분리 될 수있는 하위 책임을 찾습니다. 숨겨진 도메인 개념이있을 수 있습니다.

하나의 개념이 하나의 제한된 컨텍스트에 명확하게 맞지 않으면 추가 분석하여 하위 책임을 식별하십시오. 명확하게 분할 된 모델을 생성 할 수있는 숨겨진 도메인 개념이있을 수 있습니다.

알림 전송의 논쟁적인 책임을 확대하면 누락 된 개념이있을 수 있습니다. ? 더 우아한 모델을 제공하기 위해 도메인 별을 도메인 일반에 연결하는 세 번째 개념이있을 수 있습니다.

도메인 매퍼 컨텍스트

도메인 별을 분리하는 데 사용할 수있는 하나의 패턴 domain-generic은 도메인 매퍼 컨텍스트입니다. 컨텍스트가이 역할을 맡으면 특정 도메인 이벤트를 수신하고이를 일반 컨텍스트로 전송 된 명령에 매핑합니다.

이 패턴의 장단점이 초기 두 옵션의 장단점과 어떻게 비교되는지 확인하십시오. 두 가지 장점을 모두 제공합니다. 알림 관련 복잡성으로 인해 모든 도메인 별 컨텍스트를 복잡하게 만들지 않고도 알림이 전송되는 방식을 자유롭게 변경할 수 있습니다.

시나리오를 고려하십시오. 내부 알림 시스템은 다음으로 대체됩니다. 기성 솔루션. 도메인 매퍼는 도메인 별 컨텍스트에 영향을주지 않고 모든 명령을 새 알림 서비스로 라우팅합니다.

다른 시나리오를 고려하십시오. 새 알림이 추가됩니다. 등록은 매퍼 내에서 구성됩니다. {domain event}가 {notification}을 트리거 할 때

알림은 도메인 일반 기능입니다. 많은 도메인에서 이메일 및 푸시 알림을 활용합니다.
Twitter의 알림 환경 설정 — 도메인 별 이벤트에서 도메인 일반 작업 (이메일)으로 매핑

매퍼 컨텍스트라고하는 이유

이 패턴의 이름은 중요합니다. 한 도메인 내에서 발생하는 작업은 다른 도메인에서 발생하는 작업에 매핑됩니다 (일반 컨텍스트는 여러 도메인에서 일반적이므로 부분적으로 다른 도메인에 있음).

메시징 번역기 , 그러나 번역은 일부 동등성을 의미합니다. 번역 된 값은 원래 값의 다른 표현입니다. 매퍼의 경우에는 그렇지 않습니다.

매퍼는 도메인 내에서 일어나는 일을 관찰하는 청취자에 가깝습니다. 다른 도메인의 작업을 사용하여 도메인의 이벤트에 응답하는 방법을 결정합니다.

게이트웨이 도메인 매퍼 컨텍스트

사용자 지정 빌드를 교체하기로 결정한 경우 SaaS 솔루션을 사용하는 일반 컨텍스트에서 도메인 매퍼 컨텍스트는 게이트웨이 도메인 매퍼 컨텍스트가됩니다.

A 게이트웨이는 정보의 유입 및 유출을 관리하는 시스템의 가장자리에 있습니다.

게이트웨이 도메인 매퍼 컨텍스트는 기본적으로 동일한 기능을 수행하지만 이제는 다음 위치에 있습니다. 시스템 경계를 넘어서 통신합니다. 시스템을 드나 드는 정보의 경로입니다.

구현은 동일하게 보일 수 있지만보다 정확한 용어를 사용하면 아키텍처를보다 명확하게 전달할 수 있습니다.

도메인 매퍼 엔지니어링 트레이드 오프

도메인 매퍼 컨텍스트 패턴과 관련된 패턴은 중요하지 않습니다. 추가 매핑 레이어는 이제 세 명의 공동 작업자가 관련되어 있음을 의미합니다. 실패 할 수있는 더 많은 것.

공동 변화도 있습니다. 새 이벤트가 도입되거나 기존 이벤트가 변경되면 이벤트를 소유하는 도메인 별 컨텍스트와 매퍼 컨텍스트가 모두 변경되어야합니다.

이러한 비용을 최소화하기 위해 널리 사용되는 솔루션이 있습니다.

셀프 서비스 도메인 매퍼 컨텍스트

야생에서 자주 발생하는 한 가지 패턴은 셀프 서비스 제한 컨텍스트입니다. 이 역할을 수행하는 제한된 컨텍스트를 통해 소비자는 컨텍스트를 소유 한 팀에 의해 차단되지 않고 컨텍스트의 기능을 활용할 수 있습니다.

첫 번째 변형은 소스 제어를 통한 컴파일 시간 메커니즘이고 두 번째는 다음을 통한 런타임 메커니즘입니다. API 호출.

알림 시나리오에서 셀프 서비스 컨텍스트는 DSL을 제공 할 수 있습니다. 도메인 별 컨텍스트를 소유 한 팀은 DSL을 사용하여 구독 할 도메인 이벤트와 알림 사이의 매핑을 구성하는 구성 파일 (더 나은-컴파일 및 테스트되는 코드)의 변경 사항을 포함하는 풀 요청을 만듭니다. 전송됩니다.

동적 버전에서는 해당 구성이 API 호출 또는 UI를 통해 수행됩니다. 동적 구성이 가능하고 도메인에 대한 컴파일 시간 종속성이없는 경우 컨텍스트는 완전히 일반화되는 방향으로 이동합니다. 이것은 일반적인 진화 패턴 ()입니다.

게시 된 언어

이 유형의 시나리오에서 고려해야 할 또 다른 DDD 패턴은 게시 된 언어입니다. 알림을 트리거하는 모든 이벤트는 게시 된 언어의 일부를 형성해야합니다.

게시 된 언어는 제한된 컨텍스트에 의해 생성되는 메시지 형식에 대한 계약 또는 계약입니다. 알림이 필요한 이벤트가 게시 된 언어의 일부임을 보장한다는 것은 이전 버전과의 호환성을 보장하고 소비자에게 향후 변경 사항을 알리기 위해 더 많은주의를 기울여야한다는 것을 의미합니다.

항상 도메인 매퍼 컨텍스트를 사용해야합니까?

확실히 아닙니다. 게시물에 제시된 각 패턴은 유효하며 다양한 시스템에서 성공적으로 사용됩니다. 도메인 매퍼 컨텍스트는 대체 모델링 가능성을 탐색하는 데 사용할 수있는 명확한 절충안이있는 또 다른 패턴입니다.

슈퍼 컨텍스트 검색

순진하거나 피상적 인 수준에서 도메인을 모델링하는 것은 쉽습니다. . 알림과 같은 단어를들을 때 단어가 하나의 개념처럼 들리기 때문에 시스템에서 단일 경계 컨텍스트로 표현되어야한다고 가정하면 응집 된 이름 오류에 빠지기 쉽습니다.

DDD를 사용하여 더 깊은 수준에서 분석하고 도메인 별 개념과 도메인 일반 개념을 분리하려고 할 때 종종 도메인을 모델링하는 여러 가지 방법이 있음을 알게됩니다. — 단일 수퍼 컨텍스트 내에서.

도메인 일반에서 특정 도메인을 분리하는 것은 고대 DDD 규칙을 따르는 아름다운 추상 모델을 만드는 것이 아니라 서로 다른 이유로 함께 변경되는 개념을 분리하여 거래를 엔지니어링 할 수 있도록하는 것입니다. -offs는 시스템을보다 쉽게 ​​발전시킬 수 있도록합니다.

단일 도메인 분류 오류를 피하십시오. 하나의 상위 수준 기능인 알림이 단일 도메인 분류 (예 : 일반)를 가져야한다고 가정합니다.

진행 중 r 더 깊은 도메인 통찰력을 얻으려면 DDD 기술과 DDD 활동을 팀의 작업 방식에 도입하는 것이 좋습니다. EventStorming 및 (The Bounded Context Design Canvas)를 더 나은 경계 컨텍스트를 모델링하는 방법을 배우기위한 시작점으로 실험하십시오.

교육 및 컨설팅

탐색에 도움이 필요한 경우 도메인, 시스템 설계 또는 팀 교육에 대한 자세한 내용은 저에게 문의 하십시오. 저는 비즈니스 목표와 영역에 맞는 효과적인 사회 공학 시스템을 설계하는 데 열정적 인 경험이 많은 DDD 실무자 네트워크와 협력합니다.