14 | 모델의 무결성 유지

[youngvly]

#14. 모델의 무결성 유지
모델과 다른 모델과의 관계가 지닌 한계를 인식하고 전달하며, 선택하는 기법을 설명하는 장.

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

• 단일화를 추구할때 따르는 위험요소
  1. 한번에 많은 레거시 교체를 하려할 지도 모른다.
  2. 능력에 비해 조율에 드는 비용이 커서 난관에 처할지 모른다.
  3. 요구사항이 있는 애플리케이션에서 요건 충족을 하지못해 애플리케이션 행위를 다른모델에 두어야 할 수있다.
  4. 반대로, 요구사항을 단일모델로 모두 만족시키려 해서, 모델을 사용하기 어렵게 만드는 복잡한 대안으로 이어질 지도 모른다.

BOUNDED CONTEXT 제한된 컨텍스트

• 모델은 컨텍스트에 적용된다.

• 모델 컨텍스트란 모델에서 사용된 용어를 특정한 의미로 의사소통하기위한 조건의 집합이다.

• 모델이 적용되는 컨텍스트를 명시적으로 정의하라.
  : 컨텍스트의 경계를 팀,애플리케이션 특정부분의 사용법, 코드기반, db스키마 같은 물리적 형태의 관점에서 명시적으로 설정하라.

• context 내에서는 모델을 논리적으로 통일된 상태로 유지하되, 경계 외부에 대한 적절성에 대해서는 신경쓰지 않아도 된다.

• Bonded context 와 module은 다르다.

  • module은 단일 모델내에 포함된 요소 구성에도 사용되고, 다른 모델의 경계를 제공하는데에도 사용된다. 개별 context에 의도를 전하는것은 아니다.
  • bounded context 내 module이 만들어낸 개별 네임스페이스가 포함되면 우발적으로 발생하는 모델의 단편화를 파악하기가 어려워진다. (?)

• 예약 컨텍스트 예제

  • 예약시스템 : 기준 bounded context
  • 레거시 예약 관리 시스템 : 새로운 모델과 구분하기로 사전에 논의됨 / 번역 메커니즘은 bounded context 내에 존재하지 않는다.
  • 홤루선 운항일전 관리 시스템 : 예약시스템과 같은 모델을 사용한다고 생각하지만, 같은 context안에 있지 않다면 코드를 공유하려해서는 안된다.

• context 안에서 업무 진행하는 팀에서 얻는것은 모델의 일관성 등 명확함.

• context 밖에서 업무 진행하는 팀에서 얻는것은 자유로움. (번역도 context 밖에 있음)

• 안과 밖 각각의 팀은 정보를 공유했을때 발생하는 비용과 이득의 타협점을 결정하고 ㅓ정보 공유가 잘될수있게 프로세스로 정립할 필요가 있다.

• bounded context 안의 균열 인식
  : 중복된 개념과 허위 동족언어(false cognates) 사용할경우

  • 허위 동족언어 : 같은 용어/객체를 사용하는 사람들이 서로 다른것을 같은것으로 이야기하고있는것.

CONTINUOUS INTEGRATION 지속적인 통합

내부적으로 균열이 발생할때 이를 빠르게 포착하고 정정할 수 있을 정도로 컨텍스트 내의 모든 작업을 빈번하게 병합해서 일관성을 유지하는것.

• 다수의 사람이 동일한 bounded context를 작업할 경우 모델이 단편화될 가능성이 높다. 단편화가 발생한 사실을 빠르게 알려줄 수 있는 자동화된 테스트와 함께 모든 코드와 그밖의 구현 산출물을 빈번하게 병합하는 프로세스를 수립하라
• 병합/빌드/테스트 프로세스를 토대로 통합된다.
• 효과적인 프로세스의 공통점
  • 단계적이고 재생가능한 병합/빌드기법
  • 자동화된 테스트 스위트
  • 수정사항이 통합되지 않은 상태로 존재할 수 있는 시간을 적당히 짧게 유지하는 규칙
• 개념적인 통합 : 논의시에 UBIQUITOUS LANGUAGE 사용

CONTEXT MAP

서로 다른 context 간의 관계를 정의하고 프로젝트상의 모든 모델 컨텍스트를 아우르는 전체적인 뷰
프로젝트에 속한 모든 사람들은 map을 이해하고 공유해야한다.

1. 프로젝트 상의 모델을 식별하고 bounded context 정의 (비객체지향적인 하위 시스템에 대한 암시적인 모델도 포함)
2. Bounded context의 이름을 ubiquitous language 로 포함
3. 모델과 모델이 만나는 경계지점을 서술 : Context간의 번역에 대한 윤곽을 명확하게 표시하고, context간 공유해야하는 정보를 강조
4. 각 context의 현재 영역을 나타내는 지도를 작성.
5. Context의 배치를 바꾸는일은 나중에!

• 예시에서 translator를 별도의 객체로 두는데, 각각의 context에서 역할을 가져가는게 낫지않나? 왜 따로있지?? 여기가 경계인가??

SHARED KERNEL 공유커널

• 두 팀간에 공유하기로한 도메인 모델의 부분집합을 명시하라. 이는 다른 팀과의 협의없이는 변경할 수 없다.
  모델 요소와 연관된 코드나 db설계의 부분집합도 포함된다.
• 기능 시스템을 자주 통합하라. CI보다는 적은 빈도로 통합하라. 통합할때는 양팀에서 작성한 테스트를 모두 실행하라.
• 목표는 중복을 줄이고 두 하위시스템간의 통합을 용이하게 만드는것에 있다.

[youngvly]

CUSTOMER / SUPPLIER DEVELOPMENT TEAM (고객/공급자 개발팀)

• 상류 하위 시스템과 하류 하위 시스템은 두개의 BOUNDED CONTEXT로 나뉜다.
• 하류팀과 상류팀간의 변경권은 팀간의 공식적 관계를 확립하자.
  • 두 사용자 집단이 내세우는 요구사항의 균형을 유지하고, 하류팀에서 필요하는 기능을 위한 일정을 잡는 프로세스로 구성.
• 상/하류 팀간의 명확한 고객/공급자 관계를 확립하라.
• 계획 회의에서 하류팀이 상류팀에 대한 고객 역할을 맡게 하라.
• 결과로 예상되는 인터페이스를 검증하게될 자동화된 인수테스트를 함께 개발하라.
  • 테스트를 토대로 상류팀은 하류시스템에서 발생할지도 모르는 부수효과를 두려워하지않고 자유로이 코드변경이 가능하다.
• 고객의 요구사항이 가장 중요하다.
  • 이 상황은 하류팀이 상류팀에 필요한 사항을 부탁해야만 하는 초라한 동반자 관계와는 대조적이다.
• 상류팀이 하류시스템을 망가뜨릴지도 모른다는 두려움 없이 코드를 수정하고, 하류팀이 지속적으로 상류팀 감시하지 않고도 집중하도록 자동화된 테스트 스위트가 마련되어 있어야 한다.

개발중인 시스템의 고객/공급자 를 분리해보자.

CONFORMIST 준수자

• 맹목적으로 상류팀의 모델을 준수해서 BOUNDED CONTEXT 간의 번역에 따른 복잡도를 제거하라.

• 두 개발팀이 상.하류 관계를 맺고있고, 상류팀이 하류팀의 필요성을 충족시킬 충분한 동기를 느낄 수 없다면 하류팀은 속수무책으로 무력해질 수 밖에 없다.

• 대응방안

  1. 상류팀에서 제공하는 기능의 사용을 포기 > SEPARATE WAYS로 나아가는것.
  2. 하류층에서 번역계층을 개발하고 유지보수할 책임을 전부 맡아야 한다. > ANTICORRUPTION LAYER
  3. 하류층에서 전적으로 독립적인 모델을 포기하는것 > CONFORMIST
  4. 두 시스템이 공용으로 관리하고 각자의 테스트를 통해 기능을 보장하는것 > SHARED KERNEL

• 컴포넌트와 관련된 인터페이스가 차지하는 부분이 작다면 단일 모델을 공유하지 않아도 무장하며, 이경우 번역이 실용적인 대안이 될 수 있다.

• 인터페이스가 거대하고 통합이 좀더 중요하다면 일반적으로 선도자를 따르는 편이 타당하다.

• 장점

  • 하류팀 설계가 상류팀에 속박되고 이상적인 모델은 만들지 못해도, 통합자체는 매우 단순해질 수 있다.
  • 상류팀과 UBIQUITOUS LANGUAGE를 공유할 수 있다.

ANTICORRUPTION LAYER 오류방지 계층

• 개념적인 객체와 행위를 하나의 모델과 프로토콜에서 타 모델과 프로토콜로 변환하기위한 메커니즘에 해당한다.
• 클라이언트 고유의 도메인 모델 측면에서 기능을 제공할 수 있는 격리계층을 만들라.
• 기존에 이미 존재하는 인터페이스를 거쳐 다른 시스템과 통신하므로, 다른 시스템을 거의 수정하지 않아도 된다.
• 해당 계층 내에서는 내부적으로 필요에 따라 두 모델을 상대로 양방향으로 번역을 수행한다.
• 오류방지 계층의 공용 인터페이스는 간혹 entity이기도 하지만, service의 집합으로 표현된다.
• FACADE
  • 하위 시스템에 대한 클라이언트의 접근을 단순화하고, 더 쉽게 하위 시스템을 사용할 수 있게 만들어주는 대안 인터페이스.
  • 다른 시스템의 모델에 따라 엄격하게 작성해아하며, 기저시스템의 모델은 변경하지 않는다.
  • 다른 시스템의 BOUNDED CONTEXT에 속한다.
• ADAPTER
  • 행위를 구현하는 측에서 이해한 것과 다른 프로토콜을 클라이언트에서 사용하게 해주는 wrapper
  • ADAPTER가 하는 일은 요청 방법을 파악하는것.
• 번역기
  • ADAPTER에 속하고, 아무런 상태도 필요하지않으며, 분산될 필요도 없다. 필요할때 인스턴스화될 수도 있다.
• 고려해야할 사항
  • 다른 하위시스템에서 ANTICORRUPTION LAYER의 SERVICE를 호출할 수 있게 바꿔야할수도 있다.
  • ADAPTER와 FACADE 사이에 통신연결을 두는것이 바람직하다.

SEPARATE WAYS 각자의 길

• 통합에는 언제나 비용이 많이 든다. 때로는 통합의 혜택이 적은 경우도 있다.
• BOUNDED CONTEXT를 독립적으로 선언하여, 개발자들이 작은 범위 내에서 단순하고 특화된 해결책을 찾을 수 있게 하라.

OPEN HOST SERVICE 공개 호스트 서비스

• 하위 시스템 접근과 관련된 프로토콜을 일련의 SERVICE로 정의하라.
• 프로토콜을 공개해서 개발중인 시스템과 통합하고자 하는 모든 이들이 해당 프로토콜을 사용할 수 있게 하라.
• 독특한 요구사항은 제외하고, 이럴 경우 일회성 번역기로 프로토콜을 보강해서 공유 프로토콜을 단순하고 일관되게 유지하라.

PUBLISHED LANGUAGE 공표된 언어

• 필요한 도메인 정보를 표현할 수 있는 적절히 문서화된 공유언어를 공통의 의사소통 매개체로 사용해서 필요에 따라 해당 언어로, 또는 해당 언어로부터 번역을 수행하라.

UBIQUTIOUS LANGUAGE와 차이점?? PUBLISHED 는

[youngvly]

모델의 컨텍스트 전략 선택

팀 의사결정 또는 그 이상.

• BOUNDED CONTEXT 정의, 관계 결정.

우리 자신을 컨텍스트에 배치하기

• 작업중인 주요 CONTEXT의 일부를 구성한다.

경계의 변형

[youngvly]

https://www.codeproject.com/Articles/1131462/Domain-Driven-Design-My-Top-Best-Practices
https://github.com/zkavtaskin/Domain-Driven-Design-Example