14장 모델의 무결성 유지

[jongfeel]

Chapter Fourteen. Maintaining Model Integrity

두 팀에서 서로 다른 모델을 쓰고 있지만 아무도 알아차리지 못했고
이를 탐지하는 프로세스조차 마련돼 있지 않았다.
각 팀은 자신들만의 맥락에서만 유효한 요금 속성을 대상으로 작업 했고
이런 모순점을 해결하지 않고 코드를 결합했기에 신뢰할 수 없는 소프트웨어가 만들어진 것이다.

현실을 제대로 인식해야 문제를 어떻게 해결할지 판단할 수 있다.
공통 모델을 만들기 위해 협력하고 자동화 테스트를 작성할 수도 있고
별도의 모델을 개발해도 각자 코드를 간섭하지 않는 합의를 해도 된다.
어느 쪽이든 문제 해결은 각 모델이 적용되는 경계를 분명하게 합의하는 것에서부터 출발한다.

모델은 내적으로 일관성을 유지하고 용어는 의미가 동일하며 어떠한 모순되는 규칙도 없어야 한다.
하지만 대규모 시스템 개발의 세계에서는 단일화를 유지하기란 생각보다 복잡하다.
모델의 주요 부분을 밀접하게 단일화 하는 수단이 필요한데
이건 저절로 되거나 선의의 의도가 있다고 해서 되는 것이 아니며,
의식적인 설계 결정과 구체적인 프로세스를 거쳐서만 달성될 수 있다.
대규모 시스템의 도메인 모델을 완전하게 단일화한다는 것은
타당하지 않거나 비용 대비 효과적이지 않을 수 있다.

복수 모델에 대한 거부감은 단일 모델 하에서 대규모 프로젝트에 속하는 소프트웨어 일체를 통합하려는 의욕적인 시도로 이어진다.
지나친 과욕은 잘못된 것일 수 있지만 다음과 같은 위험 요소를 고려해야 한다.

1. 한 번에 많은 레거시 교체
2. 대규모 프로젝트에서 조율에 드는 비용이 너무 큼
3. 특화된 요구사항이 있는 애플리케이션에서 요건을 충족하지 못해 애플리케이션의 행위를 다른 곳에 둘 수 밖에 없는 모델의 사용
4. 단일 모델로 모두를 만족시키려 해서 모델을 사용하기 어렵게 만드는 복잡한 대안으로 이어짐

모델의 분화는 정치적 분열과 경영상의 우선순위로 발생한다.
팀 구성과 개발 프로세스의 결과로도 서로 다른 모델이 나타날 수도 있다.
통합을 가로막는 기술적 요인이 전혀 없더라도 프로젝트에는 여전히 다수의 모델이 나타날 수 있다.

어떤 것을 단일화해야 하는지에 관한 적극적인 의사결정과
어떤 것을 단일화해서는 안 되는지를 실용적으로 인식하는 안목이 결합되면
현재 처한 상황을 나타내고 다른 이와 공유할 수 있는 형상을 만들어낼 수 있다.
그래서 단일화되기를 바라는 부분은 그대로 유지하고
단일화되지 않는 부분이 혼란을 초래하거나 다른 부분을 손상시키지는 않는지 확인하는 일에 착수할 수 있다.

다른 여러 모델 간의 경계와 관계를 표시해줄 수단이 필요하다.
의식적으로 전략을 결정해야 하며, 그러고 나서 이런 전략을 지속적으로 따라야 한다.

Figure 14.1. A navigation map for model integrity patterns

• BOUNDED CONTEXT(제한된 컨텍스트) #897
• CONTINUOUS INTEGRATION (지속적인 통합) #906
• CONTEXT MAP(컨텍스트 맵) #912
• SHARED KERNEL(공유 커널) #924
• CUSTOMER/SUPPLIER DEVELOPMENT TEAM(고객/공급자 개발 팀) #925
• CONFORMIST(준수자) #929
• ANTICORRUPTION LAYER(오류 방지 계층) #936
• SEPARATE WAYS(각자의 길) #941
• OPEN HOST SERVICE(공개 호스트 서비스) #942
• PUBLISHED LANGUAGE(공표된 언어) #943

---

• Unifying an Elephant(코끼리 통일하기) #949
• Choosing Your Model Context Strategy(모델의 컨텍스트 전략 선택) #950
• Transformations(변형) #957