필요성
-
두 개발 팀이 상류/하류 관계를 맺고 있고 상류 팀이 하류 팀의 필요성을 충족시킬 충분한 동기를 느낄 수 없다면 팀은 속수무책으로 무력해질 수밖에 없다.
-
이타주의를 발판 삼아 상류 개발자들이 약속을 할 수는 있어도 그 약속을 이행할 가능성은 희박하다.
-
상류 팀의 선한 의도를 신뢰한 하류 팀은 결코 사용할 수 없는 기능을 기반으로 계획을 작성하게 된다.
-
위와 같은 이유로 상류 팀을 신뢰할 수 없으면,
SEPRATE WAY로 진행되기도 하는데 품질이 그렇게 떨어지지 않고 합리적으로 두 형식을 모두 수용할 수 있다면 독립적인 모델을 포기하고CONFORMIST로 진행된다.
준수가 항상 나쁜 것은 아니다.
-
거대한 인터페이스를 제공하는 기성 컴포넌트를 사용할 경우 일반적으로 해당 컴포넌트에 포함된 암시적인 모델을 준수(
CONFORM)해야 한다. -
컴포넌트가 담당하는 범위는 좁기 때문에 더 발전된 지식이 존재할 수 있다.
-
모델을 준수하면서, 더 나은 설계로 이어질 수도 있다.
준수
-
맹목적으로 상류 팀의 모델을 준수해서
BOUNDED CONTEXT간의 번역에 따른 복잡도를 제거해야 한다. -
CONFOMRIST를 따를 경우 하류 팀 설계자들의 설계 형식이 상류 팀에 속박되고 애플리케이션을 위한 이상적인 모델을 만들지는 못해도 통합 자체는 매우 단순해질 수 있다.
SHARED KERNEL
-
CONFORMIST는 동일한 모델을 이용하는 영역과 추가를 통해 모델을 확잫안 영역, 다른 모델이 영향을 미치는 영역을 보유한다는 점에서SHARED KERNEL과 유사 -
두 패턴 간의 차이점은 의사결정과 개발 과정에 있다.
SHARED KERNEL이 밀접하게 조율하는 두 팀 간의 협력관계를 다룬다면CONFORMIST는 협력에 관심이 없는 팀과의 통합 문제를 다룬다.
