[DDD] 모델의 무결성 유지

모델 무결성 패턴에 대한 네비게이션 맵

송장 발급 모듈 팀에서의 Charge 객체 vs 청구서 결제 모듈 팀에서의 Charge 객체

• 대규모 시스템의 도메인 모델을 완전하게 단일화한다는 것은 타당하지 않거나 비용 대비 효과적이지 않다.

위험요소

• 한 번에 지나치게 많은 레거시를 교체하려고 할지도 모른다.
• 대규모 프로젝트에서는 능력에 비해 조율에 드는 비용이 너무 커서 난관에 처할지도 모른다.
• 특화된 요구사항이 있는 애플리케이션에서는 요건을 완전하게 충족하지 못해 어플리케이션의 행위를 다른 곳에 둘 수 밖에 없는 모델을 사용해야 할지도 모른다.
• 이와 반대로 단일 모델로 모두를 만족시키려 해서 모델을 사용하기 어렵게 만드는 복잡한 대안으로 이어질지도 모른다.

모델의 무결성 유지 방법

• CONTEXT MAP

  • 프로젝트의 컨텍스트와 각 컨텍스트 간의 관계의 전체적인 개관을 제공해준다.

• BOUNDED CONTEXT

  • 각 모델의 적용가능성의 범위를 정의한다.

• CONTINUOUS INTEGRATION

  • 지속적인 통합 프로세스를 토대로 모델의 단일화를 유지할 수 있을 것이다.

• SHARED KERNEL

  • 밀접하게 관련된 컨텍스트를 이룬다.

• SEPERATE WAYS

  • 느슨한 결합된 모델을 이룬다.

BOUNDED CONTEXT

문제 상황

• 규모가 큰 프로젝트에서는 다수의 모델이 사용되기 마련이다.
• 개별적인 모델을 기반으로 작성된 코드가 한데 섞이면 버그 발생이 높고 이해하기 힘든 소프트웨어가 만들어진다.
• 팀구성간의 의사소통이 어려워진다.
• 어떤 컨텍스트에서 어떤 모델을 사용해서는 안 되는지 불분명한 경우도 있다.

BOUNDED CONTEXT

• 모델이 적용되는 컨텍스트를 명시적으로 정의하라.
• 컨텍스트의 경계를 팀 조직, 애플리케이션의 특정 부분에서의 사용법, 코드 기반이나 데이터베이스 스키마와 같은 물리적인 형태의 관점에서 명시적으로 설정하라.
• 경계 내에서는 모델을 엄격하게 일관된 상태로 유지하고 경계 바깥의 이슈 때문에 초점이 흐려지거나 혼란스러워져서는 안된다.
• 팀 구성원이 어떤 부분에서 일관성을 지녀야 하고 다른 CONTEXT와 어떤식으로 관련돼 있는가를 서로 명확하게 이해할 수 있게 특정 모델의 적용 범위를 제한한다.
• Context 내에서는 모델을 논리적으로 통일된 상태로 유지한다.
• 경계외부에 대한 적절성에 대해서는 신경쓰지 않는다.
• 서로 다른 컨텍스트에 대해서는 용어, 개념과 규칙, Ubiquitous language에 포함된 독특한 표현방식에 차이를 보이는 서로 다른 모델을 적용한다.
• 명확한 경계를 정의함으로써 해당 모델을 적용할 수 있는 영역 내에서 모델을 순수하게 유지한다.
• 이런 경계에 걸쳐 이뤄지는 통합에는 필수적으로 어느 정도의 번역이 수반된다.

BOUNDED CONTEXT 안의 균열 인식

• 중복된 개념
  • 실제로 같은 개념을 나타내는 두개의 모델요소가 존재하는 것이다.

• 허위 동적 언어
  • 같은 용어를 사용하는 두 사람이 서로 같은 것을 이야기하고 있다고 생각하지만 실제로는 그렇지 않은 경우.

정리

• 팀 단위로 개발을 진행하다 보면 개념적 충돌이 팀 간에 발생하는 경우가 많다. 그래서 실제로 재사용을 해야 할지 아님 새롭게 만들어서 써야 할지 고민을 많이 하는 것 같다.
  이러한 문제를 해결하기 위해 컨텍스트의 경계를 명시적으로 설정해 자율성을 보장하고 일관성을 유지할 수 있다면 좋은 소프트웨어를 만들 수 있지 않을까 생각해본다.