[DDD] CONTEXT MAP

필요성

• 다른 팀에 속한 사람들은 CONTEXT 간의 경계를 인식하지못한다.
• 자신도 모르는 사이 CONTEXT의 경계를 흐리게 하거나 연결되는 방식을 복잡하게 바꾼다.
• 서로 다른 CONTEXT를 연결해야 하는 경우 CONTEXT는 서로에게 스며드는 경향이 있다.
• 관리자와 팀 구성원 모두에게 현재 진행중인 소프트웨어 모델과 설계의 개념적인 분할을 명확하게 바라볼수 있는 뷰가 필요하다.

정의

• 프로젝트 관리와 소프트웨어 설계 영역 사이에 걸쳐 있는 개념이다.
• 컨텍스트의 경계는 팀 조직의 윤곽을 따라 정해진다.

방법

• 프로젝트 상의 유요한 모델을 식별하고 각 BOUNDED CONTEXT를 정의하라.
• BOUNDED CONTEXT에 이름을 부여하고 이 이름을 UBIQUITOUS LANGUAGE의 일부로 포함시켜라
• 의사소통을 위해 컨텍스트 간의 번역에 대한 윤곽을 명확하게 표현하라.
• 컨텍스트 간에 공유해야 하는 정보를 강조함으로써 모델과 모델이 만나는 경계 지점을 서술하라.
• 각 컨텍스트의 현재 영역을 나타내는 지도를 작성하라.
• 컨텍스트의 배치를 바꾸는 일은 나중에 하라.

균열 대응 방법

• 정확한 전체적인 뷰를 가지고 혼란스러운점을 설명한다.
• 균열때문에 무너지지않게 적절한 프로세스를 활용해 이를 지탱한다.
• 관계가 모호하다면 가장 근접한 패턴을 선택해서 그 패턴을 향해 전질할 수 있다.
• 최우선 해결 과제는 분명한 CONTEXT MAP에 이르는 것이다.
• 필수적인 수선작업이 전체적인 구조를 재구성하는 작업으로 이어지면 안된다.
• 명확한 CONTEXT MA을 보유하기 전까지는 명백하게 드러나는 모순만 해결한다.

CONTEXT 경계에서의 테스트

• 다른 BOUNDED CONTEXT와 접촉하는 지점은 테스트할때 특히 중요하다.
• 테스트는 귀중한 조기경보체계의 역할을 할 수 있다.
• 통제할 수 없는 모델의 세부사항에 의존할 때는 안심할 수 있게 만들어준다.

CONTEXT MAP의 조직화와 문서화

• BOUNDED CONTEXT의 이름은 해당 BOUNDED CONTEXT에 관해 이야기할 수 있어야한다.
• 팀의 UBIQUITOUS LANGUAGE에 들어가야 한다.
• 모든 이들이 경계가 어디에 위치하는지 알아야 하며, 어떠한 코드나 환경의 CONTEXT도 인식할 수 있어야 한다.

BOUNDED CONTEXT 간의 관계

• SHARED KERNEL
• CUSTOMER/SUPPLIER
• SEPARATE WAYS
• OPEN HOST SERVICE
• ANTICORRUPTION LAYER

정리

• 소프트웨어를 만들다 보면 다양한 컨텍스트 환경이 나누어지게 되게 마련이다. 그러나 이런 경계 관리를 제대로 수행하지 못하면 코드 관리가 되지 않게 될 뿐만 아니라 의사소통도 어려워지는 현상이 발생하게 된다.
  그러므로 분명하고 응집성 높은 CONTEXT MAP을 구성하고 팀 간의 내용을 명확하게 공유하한다면 분명히 품질, 속도, 커뮤니케이션 등 많은 이점이 있을 거라고 생각한다.