14장 모델의 무결성 유지 (2)

[bearics]

• CUSTOMER/SUPPIER DEVELOPMENT TEAM : 2개의 BOUNDED CONTEXT의 관계를 상.하 관계로 만들기
  • 하류 팀이 상류팀에 대한 고객 역할, 상류팀은 여러 고객이 있을 수 있으며 균형 유지
  • 상류 팀이 하류 시스템에서 벗어나기 위한 자동화 테스트는 필수
  • SHARED KERNEL은 양쪽 다 신경써야하지만, 이를 이용하면 쉬운 쪽에서 관리하고 번역만 해주면됨.(예제 참고)
  • SPL과의 관계랑 비슷
• CONFORMIST : 상류팀의 모델을 준수
  • 상류팀의 모델을 사용하기에 하류팀은 이상적인 모델을 만들기 어려워지나, 통합 자체는 단순해짐.
  • 회원과의 관계랑 비슷
• ANTICORRUPTION LAYER : 두 시스템 간의 번역용 격리 계층을 두어 두 시스템의 독립성(? 안정성도 높임)을 유지.
  • 하나의 모델과 다른 모델 간의 변환을 해주는 격리 계층. 해당 계층에서 변환해 다른 부분은 계속 유지 할 수 있도록. << 그러면 CONTEXT MAP이랑 뭐가 다른거지...?
  • 구현 (? 이해가 잘...)
  • FACADE : 기저 모델을 변경하지 않고, 다른 시스템을 위한 작성한 모델
  • ADAPTER : 클라이언트의 요청 방식을 가져옴.
  • 번역기 : ADAPTER에 포함되며, 데이터의 변환을 맡음.
• SEPARATE WAYS : 두 BOUNDED CONTEXT의 관계를 끊음.
  • 통합 비용이 너무 들거나, 혜택이 적은 경우는 관계를 끊고 독립적으로 개발.
• OPEN HOST SERVICE : 공유용 프로토콜로 개발해 모두가 쓸 수 있게 SERVICE 제공
  • 그냥 이미 정해져 있는거 쓰는 점에서 CONFORMIST랑 약간 비슷??
• PUBLISHED LANGUAGE : 두 BOUNDED CONTEXT 모델 간에 공통 언어 (ex. XML)
  • 개발 의도를 정확히 알지못하기에 기존 모델을 직접 번역하는 것은 좋지 않음
  • 누가 해석해도 의미가 동일하도록 작성.

모델의 컨텍스트 전략 선택

• 합리적으로 CONTEXT를 정하고 관계를 구축
• 경계를 세우면서 잘 고민해야한다
  • 규모가 큰 BOUNDED CONTEXT 선호
  • 하나의 모델을 기반으로 할 때
  • 두 모델 간의 번역이 어렵거나 불가능할 때
  • 하나의 모델로 이해하기 쉽고, 공유 언어로 의사소통 명확
  • 규모가 작은 BOUNDED CONTEXT 선호
  • 개발자 간의 의사소통 과부하가 줄어듦(아마도 큰 시스템보다는 이해가 쉬워서?)
  • 규모가 작아 통합하기 쉬움
  • 규모가 작으면 힘든 기술도 구현해줄 수 있음
  • 변경할 수 없다면 분리할 준비를 해야함. 통합되었더라도 주의해야함.
  • 외부시스템과의 관계는 SEPARATE WAYS를 고려, 통합이 불가피하면 CONFORMIST, ANTICORRUPTION LAYER 선택 ... 여러 상황에 맞게 컨텍스트 관계를 조정한다.

CONTEXT 관계 변경 상황

• SPEARATE WAYS > SHARED KERNEL
  • 두 CONTEXT가 단일화 되어 있는지 확인하고 코드 공유법과 명명규칙을 결정
  • 두 CONTEXT의 중복되는 부분은 하위 도메인으로 선택하거나, 두 모델의 책임을 담당할수 있는 새로운 모델 찾기
  • 위 단계에서 나온 결과물을 가지고 반복 작업해 최종 모델을 추출.
  • 단, 두 모델을 대체할 수 있는 언어가 없는 경우는 SHARED KERNAL을 미룬다.(공통분모가 없으면 의미가 없어서)
• SHARED KERNEL > CONTINUOUS INTEGRATION
  • 두 CONTEXT의 모든 프로세스가 공유되어야한다.
  • 여러 팀원들의 조율을 통해 SHARED KERNEL을 계속 확장하다보면 CONTINUOUS INTEGRATION
• 레거시 시스템의 단계적 폐기
  • 신규 시스템에 추가될 수도 있는 레거시 특징을 ANTICORRUPTION LAYER에 추가한다. ( 레거시에 최신 시스템 껍데기를 씌움)
  • 레거시가 대체가 되었거나 불필요하게 되었으면 제거
  • 위 작업을 계속 반복하다보면 폐기 완료.
• OPEN HOST SERVICE > PUBLISHED LANGUAGE
  • 업계 표준이 있다면 이를 최대한 따른다.
  • 각 협업 시스템 상대로 번역 계층 구축 << 이러면 OPEN HOST SERVICE 의미가 없는거 아닌가..?

[youngvly]

CONTEXT 간의 통합

• ANTICORRUPTION LAYER : 하류층에서 번역계층을 개발하고 유지보수할 책임을 전부 맡아야 한다.

• CONFORMIST : 하류층에서 전적으로 독립적인 모델을 포기하는것 , 상류층 모델을 준수한다.

• CUSTOMER / SUPPLIER DEVELOPMENT TEAM : 상류팀(공급자) 은 하류팀(고객)의 요구사항에 맞추어 일정수립, 개발한다.

• SHARED KERNEL : 두 시스템이 공용으로 관리하고 각자의 테스트를 통해 기능을 보장하는것

• OPEN HOST SERVICE : 상류시스템에서 프로토콜을 공개하여 다수의 하류층이 사용.

• SEPARATE WAYS : 상류팀에서 제공하는 기능의 사용을 포기

• 인물검색은 CUSTOMER/SUPPLIER.. cv 연동은 OPEN HOST SERVICE 이자 CONFORMIST ?

• UBIQUTIOUS LANGUAGE와 PUBLISHED LANGUAGE 차이점?? 그냥 같은건가?

• 저번주에서 여쭤봤던 번역계층의 위치?는 context간의 통합방법에 따라 달라질수있겠네요 😄

[chanhyeong]

CUSTOMER/SUPPLIER DEVERLOPMENT TEAM

• 명확한 CUSTOMER/SUPPLIER 관계 확립 - (upstream/downstream)
  downstream 에 대한 작업 협상을 통해 모든 사람들이 일정과 약속을 이해할 수 있게
• 결과로 예상되는 인터페이스를 검증할 인수 테스트를 같이 개발
  upstream 의 test suite 에 추가해서 CI 일부로 실행
  • (인터페이스를 정의해둔) 테스트 라이브러리를 공유해야하는건가? -> 근데 이건 SHARED KERNEL 이어서 아닌 것 같고 어떻게 하는건지

1. CUSTOMER 의 요구사항이 가장 중요하다
2. upstream 이 downstream 에 관계 없이 코드를 수정하고, downstream 이 upstream 을 의식하지 않고도 작업할 수 있는 test suite 가 필요

CONFORMIST

upstream 이 원하는대로 안 해주는데 downstream 에서는 거기서 더 기능이 더 필요한 경우

1. upstream 에서 제공하는 기능의 사용 포기 (SEPERATE WAYS)
   • 근데 이게 되나?
2. 캡슐화, 추상화 상태가 안 좋은 등의 상태 -> downstream 의 자체적인 모델 생성
   • 번역 계층 + 유지보수 필요 (ANTICORRUPTION LAYER)
3. (CONFORMIST) 품질이 괜찮다면 독립적인 모델을 포기하고 upstream 의 모델을 무조건 따름
   • BC 간의 번역 복잡도 제거
   • 설계가 upstream 에 속박되고, 이상적인 모델은 못 만들지만 통합은 단순해짐
   • SUPPLIER 와 UL 공유

ANTICORRUPTION LAYER

• 클라이언트 고유의 도메인 모델 측면에서 기능을 제공할 수 있는 격리 계층을 만들어라
• 격리 계층은 기존에 이미 존재하는 인터페이스를 거쳐 다른 시스템과 통신
• 개념적인 객체와 행위를 하나의 모델과 프로토콜에서 다른 모델과 프로토콜로 변환하기 위한 메커니즘

service model -> dao model 변환 개념인가?

외부 시스템을 모델 내에 단일 컴포넌트로 표현하는건 불가능
모델 관점에서 응집력있는 책임을 맡는 여러 SERVICE 를 사용하는게 최선

FACADE

하위 시스템에 대한 클라이언트의 접근을 단순화, 더 쉽게 하위 시스템을 사용할 수 있게 만드는 인터페이스 다른 시스템의 모델에 따라 엄격하게 작성해야 함

ADAPTER

다른 프로토콜을 클라이언트에서 사용하게 해주는 wrapper 클라이언트에서 ADAPTER 에 메시지를 전송하면 응답이 변환되어 adaptee 로 전송됨

Translator

ADAPTER 가 하는 일은 요청 방법을 파악하는 것 개념 객체나 데이터의 실제 변환. 번역기는 ADAPTER 에 속함, 아무런 상태가 필요하지 않음 필요할 때 인스턴스화 되는 가벼운 객체일 수도

SEPERATE WAYS

통합에는 비용이 많이 들고, 혜택이 적은 경우도 있음

middleware 나 UI layer 에 기능을 구성할 수 있지만, 로직은 공유하지 않고 번역 계층을 거쳐 최소한의 데이터만 전송

OPEN HOST SERVICE

하위 시스템 접근과 관련된 프로토콜을 일련의 SERVICE 로 정의
프로토콜을 공개해서 통합하고자 하는 모든 사람들이 해당 프로토콜을 사용할 수 있게 함
특수한 요구사항은 일회성 번역기로 프로토콜 보강 -> 공유 프로토콜을 단순하고 일관되게 유지

PUBLISEHD LANGUAGE

두 BC 모델 간에 이뤄지는 번역에 필요한 공통의 언어

필요한 도메인 정보를 표현할 수 있는 문서화된 공유 언어를 공통의 의사소통에 사용 이 언어로 혹은 이 언어로부터 번역 수행

---

변형 (Transformation): BC 에 관한 결정을 변경하는 것

SEPERATE WAYS -> SHARED KERNEL

번역 비용이 너무 클 때

방법

두 CONTEXT 에서 중복되는 부분을 포함하는 규모가 작은 하위 도메인 선택

• 하나의 단위로 개발된 모델의 일관성 유지 하거나
• 한 번에 한 부분을 골라 두 모델에 맞는 결과를 맞는 식으로 진행 (??)

하위 도메인에 대한 공유 모델을 만들기 위해, 각 팀에서 차출

• 원래 모델에 비해 두 모델의 책임을 모두 담당할 수 있는 새로운 모델을 찾아냄

후속

SHARED KERNEL 통합 -> 필요 없어진 번역 제거

SHARED KERNEL -> CI

SHARED KERNEL 이 확장 중일 때, BC 를 단일화

1. CI 에 필요한 권한 부여, 동일한 방식으로 업무 수행하도록 갖춤
2. 팀 간 인원 교류 시작
3. 모델 간 디스틸레이션 과정을 명확하게
4. 핵심 도메인을 SHARED KERNEL 에 시작
5. SHARED KERNEL 이 확장 -> 통합 빈도 늘림 -> CI 에 이름
6. SHARED KERNEL 이 기존 두 BC 를 포괄하면 CI 코드 기반을 갖춘 큰 하나의 팀 or 규모가 작은 두 팀(??)이 됨

레거시의 단계적 폐기

ANTICORRUPTION LAYER 를 거쳐 레거시와 소통하는 작은 최신 시스템으로 보완

1. 단일 iteration 내에 레거시 특정 기능 파악
2. ANTICORRUPTION LAYER 에 필요할 추가 사항 파악
3. 구현
4. 배포
5. ANTICORRUPTION LAYER 에서 불필요한 부분 파악해 제거
6. 레거시 모듈 삭제

OPEN HOST SERVICE -> PUBLISHED LANGUAGE

접근을 원하는 시스템이 늘어나거나 상호작용이 이해하기 어려워지는 경우

1. 업계 표준 언어 사용
2. 1이 안되면 CORE DOMAIN 을 다듬는다 (15장)
3. CORE DOMAIN 을 교환 언어의 기반으로 사용하고, 표준 교환 패러다임 활용 (우리의 경우엔 OAI 가 될 듯)
4. 협업에 참여하는 사람들에 공유
5. 새 시스템 아키텍처가 있다면 같이 공유
6. 각 협업 시스템을 상대로 번역
7. 전환

PL 은 안정적이어야 함, 끊임없는 리팩토링을 하며 호스트 모델을 자유롭게 변경 가능
교환 언어와 호스트 모델을 동일하게 보면 안됨