Sidebar

Recent changes

Menu

Trace: • Domain-Driven Design • Spring • 14 모델의 무결성 유지
Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
domain-driven_design:part_4_strategic_design:14_maintaining_model_integrity [2024/07/16 11:49] – [설계 중인 시스템] ledyxdomain-driven_design:part_4_strategic_design:14_maintaining_model_integrity [2024/11/07 08:00] (current) – [OPEN HOST SERVICE] 설명 보충 ledyx
Line 46: Line 46:
     sharedKernel["SHARED KERNEL"]     sharedKernel["SHARED KERNEL"]
     customerSupplierDevelopmentTeam["CUSTOMER/SUPPLIER DEVELOPMENT TEAM"]     customerSupplierDevelopmentTeam["CUSTOMER/SUPPLIER DEVELOPMENT TEAM"]
 +    
 +    openHostService["OPEN HOST SERVICE"]
 +    publishedLanguage["PUBLISHED LANGUAGE"]
   end   end
      
Line 60: Line 63:
  
   end   end
-   +
-  openHostService["OPEN HOST SERVICE"] +
-  publishedLanguage["PUBLISHED LANGUAGE"]+
 end end
  
Line 73: Line 74:
 contextMap --"일방적으로 겹치는 방식으로 활용"--> conformist contextMap --"일방적으로 겹치는 방식으로 활용"--> conformist
  
-contextMap --"다수의 클라이언트를 지원하는 데 활용"--> openHostService+contextMap --"다수의 클라이언트를 지원하는 데 활용.<br>하류 컨텍스트의 기능을 외부에 Service로 공개하여 상류 컨텍스트가 접근"--> openHostService
 openHostService --"공식화 수단으로 사용"--> publishedLanguage openHostService --"공식화 수단으로 사용"--> publishedLanguage
  
Line 327: Line 328:
 이 패턴에는 두 가지 중요한 요소가 있다. 이 패턴에는 두 가지 중요한 요소가 있다.
  
-  - 관계는 **고객과 공급자** 간의 관계여야 하며, 이는 **고객의 요구사항이 가장 중요**하다는 것을 의미한다. \\ 하류 팀처이 유일한 고객은 아니므로 협의를 거쳐 서로 다른 고객의 요구사항 간에 균형을 맞춰야 한다(그래도 우선순위는 유지해야 한다). \\ 이 상황은 하류 팀이 상류 팀에 필요한 사항을 부탁해야만 하는 초라한 동반자(poor-cousin) 관계와는 대조적이다.+  - 관계는 **고객과 공급자** 간의 관계여야 하며, 이는 **고객의 요구사항이 가장 중요**하다는 것을 의미한다. \\ 하류 팀이 유일한 고객은 아니므로 협의를 거쳐 서로 다른 고객의 요구사항 간에 균형을 맞춰야 한다(그래도 우선순위는 유지해야 한다). \\ 이 상황은 하류 팀이 상류 팀에 필요한 사항을 부탁해야만 하는 초라한 동반자(poor-cousin) 관계와는 대조적이다.
   - 상류 팀이 하류 시스템을 망가뜨릴지도 모른다는 두려움 없이 코드를 수정하고 \\ 하류 팀이 지속적으로 상류 팀을 감지하지 않고도 \\ __자신의 작업에 집중할 수 있게 **자동화된 Test suite**__가 마련돼 있어야 한다.   - 상류 팀이 하류 시스템을 망가뜨릴지도 모른다는 두려움 없이 코드를 수정하고 \\ 하류 팀이 지속적으로 상류 팀을 감지하지 않고도 \\ __자신의 작업에 집중할 수 있게 **자동화된 Test suite**__가 마련돼 있어야 한다.
  
Line 348: Line 349:
   * 상류 팀에서 제공하는 기능의 사용을 전적으로 포기 → **SEPARATE WAYS**   * 상류 팀에서 제공하는 기능의 사용을 전적으로 포기 → **SEPARATE WAYS**
   * 상류 소프트웨어를 사용하는 데서 얻는 가치가 너무 커서(또는 팀에 변경할 권한이 없는 정치적인 결정으로) 의존관계를 유지해야 할 때가 있다. \\ 이 경우 두 가지 길이 있다. \\ __선택은 상류팀이 제작한 소프트웨어 소프트웨어 설계의 품질과 스타일에 달려 있다.__ (캡슐화, 추상화, 패러다임등)   * 상류 소프트웨어를 사용하는 데서 얻는 가치가 너무 커서(또는 팀에 변경할 권한이 없는 정치적인 결정으로) 의존관계를 유지해야 할 때가 있다. \\ 이 경우 두 가지 길이 있다. \\ __선택은 상류팀이 제작한 소프트웨어 소프트웨어 설계의 품질과 스타일에 달려 있다.__ (캡슐화, 추상화, 패러다임등)
-    * (수용이 어려운 경우) 자체적인 모델을 만들고 복잡해질 가능성이 있는 번역 계층을 개발하고 유지보수할 책임을 전부 맡아야 한다. → **ANTICORRUPTION  LAYER** +    * (수용이 어려운 경우) 자체적인 모델을 만들고 복잡해질 가능성이 있는 **번역 계층**을 개발하고 유지보수할 책임을 전부 맡아야 한다. → **ANTICORRUPTION  LAYER** 
-    * (수용이 가능한 경우) 독립적인 모델을 포기하는 것이 최선. → **CONFORMIST**+    * (수용이 가능한 경우) 독립적인 모델을 포기하는 것이 최선. 상위 팀 모델을 따른다. → **CONFORMIST**
  
 <flow> <flow>
Line 459: Line 460:
 == OPEN HOST SERVICE == == OPEN HOST SERVICE ==
  
-각 하위 시스템에 대한 번역기가 많은 경우 사용하는 패턴+각 하위 시스템에 대한 번역기가 많은 경우 사용하는 패턴. 
 + 
 +여러 종류의 Downstream Bounded Context를 고려하여 설계되는 Upstream Bounded Context. 
 + 
 +하류 컨텍스트의 기능을 외부에 Service로 공개하여 상류 컨텍스트가 접근. 
 + 
 +예를 들어, 상류 Context "네이버 검색"에서 하류 Context인 블로그, 카페, 웹페이지 컨텍스트의 기능을 이용할 것이다. 이 때, 하류 Context N개 만큼 상류 Context에 맞춰 번역 레이어가 필요할 것이고, 유사한 코드가 반복될 것이다. 이를 외부 서브시스템을 서비스의 제공자로 바라보는 관점으로, 외부 서브시스템을 서비스로 감싼다.
  
 <note important> <note important>
Line 553: Line 560:
 === 개별 모델의 특수한 요구사항 충족하기 === === 개별 모델의 특수한 요구사항 충족하기 ===
  
-=== 배치 ===+무엇보다 **이러한 사용자 집단의 특별한 전문 용어가 __얼마나 가치 있는가?__** \\ 
 +번역의 위험에 비춰 팀의 좀더 독립적인 활동이 지닌 가치를 따져봄으로써 가치가 없는 용어상의 **변종을 합리화하는 활동을 주시**해야 한다. 
 + 
 + 
 +=== Deployment === 
 + 
 +BOUNDED CONTEXT의 전략을 선택하는 것은 배포에 영향을 미친다. 
  
 === 타협점 === === 타협점 ===
 +
 +독립적인 활동과 순조로운 의사소통을 맞바꾸는 셈
 +
 +{{:domain-driven_design:part_4_strategic_design:domain_driven_design_14_tradeoff.jpg?500}}
 +
  
 === 프로젝트가 이미 진행 중일 때 === === 프로젝트가 이미 진행 중일 때 ===
 +
 +**현재 상태**에 따라 BOUNDED CONTEXT를 정의하라.
 +일단 실제 BOUNDED CONTEXT의 현재 상태를 서술하고 현존하는 관계를 기술했다면
 +다음으로 **현재 조직을 중심으로 팀의 업무 관행을 밀접하게 정비**해야 한다.
 +
 +  - CONTEXT 내 CONTINUOUS INTEGRATION을 개선한다.
 +  - 빗나간 번역 코드를 ANTICORRUPTION LAYER로 들어가게끔 리팩터링한다.
 +  - 기존 BOUNDED CONTEXT에 이름을 부여하고 반드시 이러한 BOUNDED CONTEXT가 프로젝트의 UBIQUITOUS LANGUAGE에 속하게 한다.
  
  
 == 변형 == == 변형 ==
 +
 +Transformations
 +
 +이미 결정한 CONTEXT의 경계를 실제로 변경하는 방법
 +
 +
  
 === CONTEXT 병합: SEPARATE WAYS → SHARED KERNEL === === CONTEXT 병합: SEPARATE WAYS → SHARED KERNEL ===
 +
 +번역 따르는 과부하가 높은 경우.
 +
 +두 CONTEXT에서 중복되는 부분을 포함하는 규모가 작은 하위 도메인을 선택하여 병합한다.
 +
 +p420 참조.
 +
  
 === CONTEXT 병합: SHARED KERNEL → CONTINUOUS INTEGRATION === === CONTEXT 병합: SHARED KERNEL → CONTINUOUS INTEGRATION ===
 +
 +SHARED KERNEL이 확장되어 단일 BOUNDED CONTEXT로 통합할 가능성이 있을 때 사용.
 +
 +p422 참조.
 +
  
 === 레거시 시스템의 단계적 폐기 === === 레거시 시스템의 단계적 폐기 ===
 +
 +반복적인 배포 프로세스 중에
 +ANTICORRUPTION LAYER에서 불필요한 부분을 파악해 제거.
 +
 +p423 참조.
 +
  
 === OPEN HOST SERVICE → PUBLISHED LANGUAGE === === OPEN HOST SERVICE → PUBLISHED LANGUAGE ===
 +
 +접근을 원하는 시스템이 늘거나
 +상호작용이  점차 이해하기 어려워져 유지보수 부담이 가중될 경우.
 +
 +표준적인 언어를 정의하라.
 +
 +p425 참조.
 +
 +
domain-driven_design/part_4_strategic_design/14_maintaining_model_integrity.1721126967.txt.gz · Last modified: 2024/07/16 11:49 by ledyx