1. IV STRATEGIC DESIGN
14. 모델의 무결성 유지

2. 모델 무결성 사례
하나의 모듈(모델)을 두 팀에서 다르게 적용.
각각의 모듈로 나눈다
(Customer Charge, Supplier Charge)
자동화 테스트 수행.
모델의 단일화(unification)

3. 모델 단일화
대규모 시스템의 모델 단일화는 효과적이지 않다.
여러 모델간의 경계와 관계를 표시해줄 수단.
모델간 관계 인식, 선택.
‣ Context Map
‣ Bounded Context

4. 모델 무결성
모델 무결성 패턴에 대한 내비게이션 맵

5. BOUNDED CONTEXT
모델에 적용되는 컨텍스트를 명시적으로 정의.
컨텍스트 경계를 명시적으로 설정, 유지.

6. CONTINUOUS INTEGRATION
모델의 설계를 유지.
자동화 테스트 수행.
자주 통합.
UBIQUITOUS LANGUAGE를 보완/유지.

7. CONTEXT MAP
특정한 형식보단,
의사 소통이 유용하게,
이해하고 공유.
Bounded Context의 명확한
이름 제공,
경계지점과 특성을 표현.

8. SHARED KERNEL
팀간 공통 모델.
수정이 자유롭지 않다.
수정시 팀의 모든 테스트
를 통과.

9. CUSTOMER/SUPPLIER
DEVELOPMENT TEAM
하류 팀 권한으로
상류 팀 개발을 속박.
‣ 복잡한 요구 사항.
‣ 하류 시스템 오류 야기.
상류 팀 권한은
하류 팀의 개발을 무력화.
‣ 상류 팀의 개발 우선 순위.

10. CONFORMIST
상류 팀에서 일방적인 개발을 진행할 경우,
상류 팀에 맹목적으로 따르라.
상류 팀에 종속되고,
이상적인 모델을 만들지 못한다.
통합이 단순해진다.
상류 팀의 UBIQUITOUS LANGUAGE를 공유.
의사 소통이 용이.

11. ANTICORRUPTION LAYER
외부 모델의 기능을 이용할 수 있는
격리 계층을 만들어라.
FACADE:하위 시스템에 대한 인터페이스 제공.
ADAPTER:외부 인터페이스를 래핑.

12. SK, CSDT 는 협력적.
CONFORMIST는
편향적.
AL 은 유용한 설계가 없
다는 비관적.

13. SEPARATE WAYS
통합의 비용이 큰 경우
Bounded Context 간에 관계를 가지지 않도록 선언.
‣ 작은 범위내에서
단순하고 특화된 해결책을 만들도록 해라.
‣ 작은 범위내 작업은 결국 통합해야 하며,
그 중 비교적 비용이 큰 경우도 발생한다.
‣ 번역 계층을 만들어 해결해야 한다.

14. OPEN HOST SERVICE
하위 시스템 번역기를
조정하기 힘듦.
하위 시스템 접근과
관련된 프로토콜을
서비스로 정의.
프로토콜을 공개, 사용하도록.

15. PUBLISHED LANGUAGE
OPEN HOST SERVICE 에 프로토콜을
언어로 공표.
사람들이 손쉽게 언어를 사용.
언어의 문서화로 인해 해석의 일관성(호환성).

16. 코끼리 통일하기
개별적 Bounded Context를
통합하는 것은 어렵다.
단순한 통합 모델은
원시적이다.
새로운 요구 사항과
의사 소통으로 모델을
심화하고 정제할 수 있다.
자신의 인식이
불완전하다고 가정.

17. 모델의 컨텍스트 전략 선택
팀 의사결정 또는 그 이상
- 통합시 발생하는 비용을 평가하고, 완화 조치
자신을 컨텍스트에 배치
- 작업중인 컨텍스트뿐만 아니라,
시스템 전체에 집중(???)
..... (생략)

18. 변형
Bounded Context 에 대한 결정을 변경할 수 있다.
여러번의 반복주기로 달성.