3장. 컨텍스트 맵 / IDDD (도메인 주도 설계 구현)

개요

---

# 참고

IMPLEMENTING DOMAIN DRIVEN DESIGN (도메인 주도 설계 구현) - 반 버논 지음

 

# 개요

DDD에 대한 기술서적을 읽고 DDD가 무엇인지 이해하고 어떻게 코드에 적용시킬 수 있는지 고민해 보려고 한다.

 

# 3장의 로드맵

• 성공적인 프로젝트를 위해 컨텍스트 맵이 필수적인 이유
• 의미 있는 컨텍스트 맵을 그리는 방법
• 일반적인 조직과 시스템의 관계를 살펴보고 어떻게 프로젝트에 영향을 주는지

 

---

3장. 컨텍스트 맵

컨텍스트 맵은 두 가지 방법으로 표현할 수 있다.

1. 둘 이상의 기존 바운디드 컨텍스트들 사이의 매핑을 보여주는 다이어그램을 그리는 방법 

2. 통합의 소스 코드 구현을 사용하면 좀 더 상세하게 컨텍스트 맵을 나타내는 방법 

 

첫번째 방법은 쉽지만 이미 존재하고 있는 바운디드 컨텍스트를 다이어그램으로 다시 나타낼 뿐이다. 즉, 이 방법은 그림을 통해서 바운디드 컨텍스트가 통합을 통해 서로 어떻게 연결되어 있는 가를 나타낼 뿐이다. 

 

두번째 방법은 통합을 통해 상세한 컨텍스트 맵을 나타낼 수 있기 때문에 더 권장되는 방법이다. 

 

 

3-1. 컨텍스트 맵을 먼저 그리자 

컨텍스트 맵은 팀에서 상호 교류해야 하는 시스템의 목록을 제공할 뿐만 아니라, 웹 내부의 의사소통에서도 촉매 역할을 한다. 만약 개발자가 프로젝트를 만들며 자신의 API에 따르기만 한다면 어떤 방향을 택하든지 관심이 없을 수도 ㅇ있다. 그렇기 때문에 맵이나 API들이 무슨 일을 하는 지에 관해 어떠한 통찰도 얻지 못한다. 하지만 맵을 통해 맺고  있는 관계의 유형을 나타낸다면 팀에 필요한 통찰을 얻고 팀 내부의 의사소토에 필수적인 영역을 알 수 있다. 

 

즉, 복잡한 레거시 시스템을 구성한 팀은 우리에게 관심이 없기 때문에 프로젝트에 실패할 수 도 있다. 따라서 우리는 우리가 의지하는 다른 프로젝트들과의 관계를 컨텍스트 맵을 통해 신중하게 생각해 보아야 한다. 

 

 

3-2 컨텍스트 맵 그리기 

컨텍스트 맵은 기존 지형을 포착한다. 우선 현재를 매핑하고 만약 프로젝트를  진행하다 변경이 된다면, 그 시점에 맵을 업데이트하면 된다. 즉, 우리가 어디에 있는지 현재 상항에 집중하고, 그 이후 어디로 향할지 결정 하자.

 

모든 그림과 글은 팀에 가치를 더할 수 있으면 하나의 참고  문서로 묶어 관리하면 좋다. 이런 노력은 절차적인 부분을 줄이고 단숨함을 유지하며 애자일 하게 움직일 수 있다. 절차적인 부분을 추가하면 사람들은 싫어하고 사용하지 않으려 할 것이다. 따라서 다이어그램에 세부적인 내용을 적어 구현하기 보다는 대화를 통해 전략적 통찰을 드러내는 순각 컨텍스트 맵에 추가하면 된다.

 

컨텍스트 맵은 엔터프라이즈한 관점을 제공하기 때문에 높은 수준의 아키텍처를 나타낼 수 있따. 지행에 걸림돌이 되는 이슈나 다른 방법으로 밝혀내기 어려운 문제를 밝히는 데 도움이 된다.

 

 

3-3. 바운디드 컨텍스트 통합 패턴

두 바운디드 컨텍스트를 통합에는 항상 그 사이에 존재하는 패턴이 있다. 

 

파트너십 :

파트너십 관계는 두 팀(컨텍스트)이 성공이나 실패를 공유한다. 즉, 한 팀이 실패하면 다른 한 팀도 영향을 받아 실패하게 된다. 즉, 이 팀들은 개발과 통합의 공동 관리를 위해 잘 설계된 기획 과정을 도이해야한다. 팀들은 양측 시스템 모두의 개발 요구를 수용할 수 있는 인터페이스를 만들어 나가기 위해 반드시 협력해야 한다. 

 

공유 커널 :

양 팀에서 공유된 부분과 이에 관련되 코드는 아주 가까운 상호의존성을 형성하는데, 이는 설계 작업을 도울 수도 있고 약화시킬 수도 있다. 도메인 모델에서 팀이 공유하기로 부분을 명시적 경계로 지정하고, 커널은 작게 유지해야한다. 이러한 명시적 공유는 절대 다른 팀과 상의 없이 변경되어서는 안 된다. 또한 커널 모델은 단단하게 유지하고 팀의 공유언어를 정돈해주는 지속적 통합 프로세스를 정의해야 한다. 

 

고객-공급자 개발 : 

두 팀이 업스트림(공급자)와 다운스트림(고객)의 관계에 있고 업스트림의 성공이 다운스트림 팀의 운명과 상호의존적이라면, 다양한 방법으로 다운스트림 팀의 요구를 수용해야 한다. 업스트림 계획이 다운스트림에 상당한 영향을 미친다. 따라서 다운스트림의 요구사항에 집중해야 하며 모든 사람에게 약속과 일정을 이해시켜야 한다.

 

순응주의자 :

업스트림 팀이 다운스트림 팀의 요구사항을 제공해줄 동기가 전혀 없는 관계라면 다운스트림 팀은 속수무책의 상황에 빠진다. 다운스트림 팀은 맹목적으로 업스트림 팀의 모델을 준수해서, 바운디드 컨텍스트 사이에 나타나는 변환의 복잡성을 제거해야 한다. 

 

부패 방지 계층 :

변환 계층은 협조적인 팀 사이에서 잘 설계된 바운디드 컨텍스트를 연결할 떄 간결하고 좋다. 반면 공유커널, 파트너, 고객-공급자 관계를 만들기에 제어나 의사소통이 적절하지 않는다면 변환은 복잡해 진다. 변환계층은 방어적인 색깔을 띠며 다운스트림 클라이언트에는 불리 계층을 만들고 업스트림 시스템의 기능을 자신이 소유한 도메인 모델의 맥락에 맞춰 제공해야한다. 이 계층은 기존의 인터페이스를 통해 다른 시스템과 대화하며, 다른 시스템을 수정할 필요가 거의 없거나 전혀 없다. (전형적인 DDD, Hexagonal Architecture, DIP라고 생각.)  

 

오픈 호스트 서비스 : 

서브시스템에 접근할 수 있도록 해주는, 서비스 집합으로서의 프로토콜이다. 프로토콜을 통해 서비스를 이용해야 하는 모든 클라이언트가 사용할 수 있도록 해야 한다. 단일 팀이 특정한 요구를 하지 않는다면,  프로토콜을 강화하고 확장해서 새로운 통합 요구사항에 대응해야 한다. 또한 일회성 변환기를 사용해서 새로운 통합 요구사항에 대응하는 프로토콜을 추가하고, 공유된 프로토콜이 단순함과 일관성을 유지하도록 해야 한다. 

 

발행된 언어 :

두 바운디드 컨텍스트 모델 사이의 변환은 공통 언어를 필요로 한다. 공통의 의사소통 수단으로서 필수적인 도메인 정보를 표현할 수 있는 잘 문서화된 공유 언어를 사용해, 필요에 맞춰 변환을 수행해야 한다. 또한 발행된 언어는 오픈 호스트 서비스와 함께 많이 사용이 된다.

 

분리된 방법 : 

요구사항을 정의할 때는 엄격해야 한다. 만약 두 기능성 집합 사이에 유의미한 관계가 없다면, 이들은 서로가 완전히 불리돼야 한다. 통합에는 항상 높은 비용이 발생하기 때문에, 그에 따른 유익함이 너무 작을 때는 바운디드 컨텍스트가 다른 것과 아무 연관이 없음을 선포해서 개발자가 작은 범위 내에서 단순하고 전문화된 솔루션을 찾도록 해야 한다. 

 

큰 진흙공 : 

기존 시스템을 조사하다 보면 여러 모델이 서로 뒤섞이고 경계는 일정하지 않은 상황에서 시스템을 구성하는 부분들을 찾게 된다. 이러한 어지러운 시스템은 상황 전체를 아우르는 전체 경계를 큰 진흙공으로 선언하자. 또한 이 컨텍스트 안에 세련된 모델링을 적용하려고 애쓰지 말자, 또한 이 시스템이 다른 컨텍스트 안으로 퍼저나가는 것을 막자

 

 

# 현실적인 컨텍스트 맵

식별자와 액세스 컨텍스트를 통합하면, 협업 컨텍스트와 애자일 프로젝트 관리 컨텍스트가 보안과 권한에 따라 분리된 방법을 사용해야 하는 상황을 피할 수 있다. 사실 분리된 방법을 시스템의 컨텍스트 전반에 적용할 수도 있지만, 상황에 맞춰 사용할 수도 있다. 예를 중앙화된 보안 시스템의 사용을 거절하면서도 회사의 다른 표준 기능과는 통합하려 할 수 도 있다.

 

고객-공급자 역할에 협력하면 다른 팀의 순응주의자가 되도록 강요하는 상항을 피할수 있따. 하지만 순의주의가 꼭 불필요한 것은 아니다. 공급자가 고객의 지원을 제공한다는 약속을 요구하기 때문에 내부적인 팀 관계를 강화시킨다. 물론 고객이 언제나 옳은 것은 아니기 때문에 쌍방 양보를 통해 긍정적인 관계를 유지해야 한다.   

 

 

 

3-4. 세 가지 컨텍스트를 매핑하기

프로젝트 에서는 보안, 사용자, 권한 등의 개념이 협업 컨텍스트 내에 속하지 않는다는 점을 이해하고, 팀은 이를 핵심 도메인에서 분리하여 오로지 합의할 만한 조건일 때만 진입을 허용해야 한다. DDD에서 각 바운디드 컨텍스트의 언어는 모든 모델이 순수하게 유질 될 수 있도록 존중받아야 한다. 언어적 분리와 엄격한 준수를 통해 각 팀이 자신만의 고유한 바운디드 컨텍스트에 집중하도록 해주고, 역할과 임무에 집중할 수 있도록 하여야 한다. 바람직한 매핑은 하나의 바운디드 컨텍스트는 하나의 서브 도메인을 가지는 것이 이상적이다. 이를 위해서는 하나의 바운디드 컨텍스트를 둘로 분리해야 할 필요성이 있다.                                                                                                                                                                                             

 

위 그림을 보면 애자일 프로젝트 관리 컨텍스트는 가장 핵심적인 도메인이다. 핵심도메인 임을 감안하였을 때 애자일 프로젝트 관리 컨텍스트는 상위에 두는 것이 아닌 아래에 두어 다운스트림임을 시각적으로 표현하였다. 강 상류에서의 활동이 강 하류의 생물에게 긍정적이든 부정적인 영향을 주듯, 업스트림 모델은 다운스트림 모델에 영향을 준다. 가장 위에있는 식별자와 엑세스 컨텍스트는 가장 멀리 떨어진 업스트림이다. 이는 협업 컨텍스트와 애자일 프로젝트 관리 컨텍스트 모두에 영향을 미친다. 협업 컨텍스트는 애자일 프로젝트 관리 컨텍스트에 비해 업스트림인데, 이는 애자일 모델이 협업 모델과 서비스에 의존하기 때문이다.

 

ACL : 부패 방지 계층

OHS/PL : 오픈 호스트 서비스 / 발행된 언어

  

오픈 호스트 서비스 : 

이 패턴은 바운디드 컨텍스트 클라이언트와 상호작용하는 REST 기반 리소스로 구현할 수 있다. 일반적으로 오픈 호스트 서비스를 RPC API로 생각하지만, 메세지 교환을 사용해 구현할 수도 있다.

 

발행된 언어 : 

발행된 언어는 여러 방법으로 구현할 수 있지만, 대개는 XML 스키마로 구현한다. 이를 REST 기반 서비스로 나타낼 땐 발행된 언어가 도메인 개념의 표현으로 렌더링 된다. 예를 들어 XML과 JSON을 포함할 수 있다. REST를 사용하는 이점은 클라인언트가 선호하는 언어를 지정할 수 있고, 해당 리소스는 요청 내용 타입에 맞처서 표현을 렌더링 할 수 있다. 또한 REST는 하이퍼미디어 표현을 생성하는 이점도 있는데, 이를 HATEOAS를 촉진한다. 하이퍼미디어는 발행된 언어를 역동적이고 활발히 상호작요하도록 해준다. 하지만 REST뿐아니라 메세지 기반등 여러 방식으로 통신할 수 있다. 

 

HATEOAS를 조금더 설명하자면 흔히 REST에 대한 응답을 받을 때 이렇게 URL을 직접적으로 받을 수 있다. ​HATEOAS를 사용함으로써 역동적으로 서비스를 개발할 수 있다고 생각합니다. 

 

 

# 시스템 통합

시스템 통합은 주로 RPC에 의존한다. 높은 수준의 RPC는 일반적인 프로그래밍 프로시저 호출과 상당히 비슷하게 보인다. 라이브러리와 도구는 매려적인 모습이며 사용이 쉽다. 하지만 고유 프로세스 공간에 있는 프로시저의 호출과는 달리, 원격 호출은 성능을 떨어뜨리는 지연이나 전면적 실패가 발생할 잠재적 위험도가 높다. 네트워크와 원격 시스템의 부하는 RPC의 완료를 지연시킬 수 있다. 

 

# 애자일 프로젝트 관리 컨텍스트

애자일 프로젝트 관리 컨텍스트 팀은 RPC보다 더 높은 수준의 자율성을 달성하기 위해 신중히 사용에 관한 제약을 검토할 필요가 있다. 시스템 통합에는 제환되고 잘 배치된 RPC 호출을 하거나 유사한 요청을 통해 REST 기반 리소스를 가져와야 한다. 반면에 원격 모델의 변경에 따른 필수적 동기화는 원격 시스템이 게시하는 메세지 지향을 통해 가장 잘 이뤄질 수도 있다.