[DDD] CONFORMIST

skayjays·2021년 11월 8일
2

DDD

목록 보기
9/16

문제점

  • 두 개발 팀이 상류/하류 관계를 맺고 있고 상류 팀이 하류 팀의 필요성을 충족시킬 충분한 동기를 느낄수 없다면 하류팀은 속수무책으로 무력해질 수 밖에 없다.
  • 상류 개발자들이 약속을 할 수는 있어도 그 약속을 이행할 가능성은 희박하다.
  • 상류 팀의 선한 의도를 신뢰한 하류 팀은 결코 사용할 수 없을 기능을 기반으로 계획을 작성하게 된다.
  • 하류 팀의 필요에 맞춰진 인터페이스는 존재하지 않을 것이다.

방안

  • 상류 팀에서 제공하는 기능의 사용을 전적으로 포기한다. (SEPARATE WAYS)
  • 상류 소프트웨어에서 얻는 가치가 너무크므로 의존관계를 유지한다. (CONFORMIST)
  • 번역계층을 개발하고 유지보수할 책임을 전부 맡는다. (ANTICORRUPTION LAYER)

해결

  • 맹목적으로 상류팀의 모델을 준수해서 BOUNDED CONTEXT 간의 번역에 따른 복잡도를 제거하라.
  • CONFORMIST를 따를 경우 하류 팀 설계자들의 설계 형식이 상류 팀에 속박되고 에플리케이션을 위한 이상적인 모델을 만들지는 못해도 통합 자체는 매우 단순해진다.
  • SUPPLIER 팀과 UBIQUITOUS LANGUAGE를 공유 할수 있다.
  • SUPPLIER를 위해 의사소통을 용이하게 하는 것이 좋다.

정리

  • 소프트웨어를 개발하다보 면 협력관계가 만들어지기 마련이다. 이번 장에서는 상류 소프트웨어에서 얻는 가치가 클 때는 CONFORMIST 그저 따르는 것도 하나의 방안으로 제시해준다. 이 부분이 초반에는 공감이 잘되지 않았지만 계속 생각해보니 레이어를 계속 더 만들어서 시스템의 복잡성을 높이기보다 좋은 선택이 될 수 있다고 생각한다.
profile
기초를 탄탄하게

0개의 댓글