This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| domain-driven_design:part_4_strategic_design:14_maintaining_model_integrity [2024/07/16 12:30] – [변형] ledyx | domain-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[" | sharedKernel[" | ||
| customerSupplierDevelopmentTeam[" | customerSupplierDevelopmentTeam[" | ||
| + | | ||
| + | openHostService[" | ||
| + | publishedLanguage[" | ||
| end | end | ||
| | | ||
| Line 60: | Line 63: | ||
| end | end | ||
| - | + | ||
| - | openHostService[" | + | |
| - | publishedLanguage[" | + | |
| end | end | ||
| Line 73: | Line 74: | ||
| contextMap --" | contextMap --" | ||
| - | contextMap --" | + | contextMap --" |
| openHostService --" | openHostService --" | ||
| Line 327: | Line 328: | ||
| 이 패턴에는 두 가지 중요한 요소가 있다. | 이 패턴에는 두 가지 중요한 요소가 있다. | ||
| - | - 관계는 **고객과 공급자** 간의 관계여야 하며, 이는 **고객의 요구사항이 가장 중요**하다는 것을 의미한다. \\ 하류 팀처이 유일한 고객은 아니므로 협의를 거쳐 서로 다른 고객의 요구사항 간에 균형을 맞춰야 한다(그래도 우선순위는 유지해야 한다). \\ 이 상황은 하류 팀이 상류 팀에 필요한 사항을 부탁해야만 하는 초라한 동반자(poor-cousin) 관계와는 대조적이다. | + | - 관계는 **고객과 공급자** 간의 관계여야 하며, 이는 **고객의 요구사항이 가장 중요**하다는 것을 의미한다. \\ 하류 팀이 유일한 고객은 아니므로 협의를 거쳐 서로 다른 고객의 요구사항 간에 균형을 맞춰야 한다(그래도 우선순위는 유지해야 한다). \\ 이 상황은 하류 팀이 상류 팀에 필요한 사항을 부탁해야만 하는 초라한 동반자(poor-cousin) 관계와는 대조적이다. |
| - 상류 팀이 하류 시스템을 망가뜨릴지도 모른다는 두려움 없이 코드를 수정하고 \\ 하류 팀이 지속적으로 상류 팀을 감지하지 않고도 \\ __자신의 작업에 집중할 수 있게 **자동화된 Test suite**__가 마련돼 있어야 한다. | - 상류 팀이 하류 시스템을 망가뜨릴지도 모른다는 두려움 없이 코드를 수정하고 \\ 하류 팀이 지속적으로 상류 팀을 감지하지 않고도 \\ __자신의 작업에 집중할 수 있게 **자동화된 Test suite**__가 마련돼 있어야 한다. | ||
| Line 348: | Line 349: | ||
| * 상류 팀에서 제공하는 기능의 사용을 전적으로 포기 → **SEPARATE WAYS** | * 상류 팀에서 제공하는 기능의 사용을 전적으로 포기 → **SEPARATE WAYS** | ||
| * 상류 소프트웨어를 사용하는 데서 얻는 가치가 너무 커서(또는 팀에 변경할 권한이 없는 정치적인 결정으로) 의존관계를 유지해야 할 때가 있다. \\ 이 경우 두 가지 길이 있다. \\ __선택은 상류팀이 제작한 소프트웨어 소프트웨어 설계의 품질과 스타일에 달려 있다.__ (캡슐화, 추상화, 패러다임등) | * 상류 소프트웨어를 사용하는 데서 얻는 가치가 너무 커서(또는 팀에 변경할 권한이 없는 정치적인 결정으로) 의존관계를 유지해야 할 때가 있다. \\ 이 경우 두 가지 길이 있다. \\ __선택은 상류팀이 제작한 소프트웨어 소프트웨어 설계의 품질과 스타일에 달려 있다.__ (캡슐화, 추상화, 패러다임등) | ||
| - | * (수용이 어려운 경우) 자체적인 모델을 만들고 복잡해질 가능성이 있는 번역 계층을 개발하고 유지보수할 책임을 전부 맡아야 한다. → **ANTICORRUPTION | + | * (수용이 어려운 경우) 자체적인 모델을 만들고 복잡해질 가능성이 있는 |
| - | * (수용이 가능한 경우) 독립적인 모델을 포기하는 것이 최선. → **CONFORMIST** | + | * (수용이 가능한 경우) 독립적인 모델을 포기하는 것이 최선. 상위 팀 모델을 따른다. → **CONFORMIST** |
| < | < | ||
| Line 459: | Line 460: | ||
| == OPEN HOST SERVICE == | == OPEN HOST SERVICE == | ||
| - | 각 하위 시스템에 대한 번역기가 많은 경우 사용하는 패턴 | + | 각 하위 시스템에 대한 번역기가 많은 경우 사용하는 패턴. |
| + | |||
| + | 여러 종류의 Downstream Bounded Context를 고려하여 설계되는 Upstream Bounded Context. | ||
| + | |||
| + | 하류 컨텍스트의 기능을 외부에 Service로 공개하여 상류 컨텍스트가 접근. | ||
| + | |||
| + | 예를 들어, 상류 Context " | ||
| <note important> | <note important> | ||
| Line 589: | Line 596: | ||
| === 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 참조. | ||
| + | |||
| + | |||