도메인 주도 설계 ch17

Ch.17 전략의 종합(Domain Driven Design)

chois79

12년 11월 11일 일요일

개 요

• 도메인 주도적인 전략적 설계를 위한 기본 원칙

• 컨텍스트

• 디스틸레이션

• 대규모 구조

• 이 장에서는 전략적 설계를 위한 방법을 제시

• 기본 원칙들이 어떻게 같이 사용되는가?

• 전략적 설계를 위해 해야 할 일의 우선 순위는?

• 전략을 고안하는 일은 어떻게 시작해야 하는가?


대규모 구조와 CONTEXT의 결합 형태 (1/3)

• 단일 Bound Context 안에서 Responsibility Layer

• Responsibility Layer의 가장 단순한 형태

• 구분된 Bound Context 사이에서의 Responsibility LayerSuch a local structure can be useful in a very complicated but unified model, raising the complexityceiling on how much can be maintained in a single BOUNDED CONTEXT.

But on many projects, the greater challenge is to understand how disparate parts fit together.They may be partitioned into separate CONTEXTS, but what part does each play in the wholeintegrated system and how do the parts relate to each other? Then the large-scale structure canbe used to organize the CONTEXT MAP. In this case, the terminology of the structure applies to thewhole project (or at least some clearly bounded part of it).

Figure 17.3. Structure imposed on the relationships of components ofdistinct BOUNDED CONTEXTS

Suppose you want to adopt RESPONSIBILITY LAYERS, but you have a legacy system whoseorganization is inconsistent with your desired large-scale structure. Do you have to give up yourLAYERS? No, but you have to acknowledge the actual place the legacy has within the structure. Infact, it may help to characterize the legacy. The SERVICES the legacy provides may in fact beconfined to only a few LAYERS. To be able to say that the legacy system fits within particularRESPONSIBILITY LAYERS concisely describes a key aspect of its scope and role.

Figure 17.4. A structure that allows some components to span layers

Such a local structure can be useful in a very complicated but unified model, raising the complexityceiling on how much can be maintained in a single BOUNDED CONTEXT.

But on many projects, the greater challenge is to understand how disparate parts fit together.They may be partitioned into separate CONTEXTS, but what part does each play in the wholeintegrated system and how do the parts relate to each other? Then the large-scale structure canbe used to organize the CONTEXT MAP. In this case, the terminology of the structure applies to thewhole project (or at least some clearly bounded part of it).

Figure 17.3. Structure imposed on the relationships of components ofdistinct BOUNDED CONTEXTS

Suppose you want to adopt RESPONSIBILITY LAYERS, but you have a legacy system whoseorganization is inconsistent with your desired large-scale structure. Do you have to give up yourLAYERS? No, but you have to acknowledge the actual place the legacy has within the structure. Infact, it may help to characterize the legacy. The SERVICES the legacy provides may in fact beconfined to only a few LAYERS. To be able to say that the legacy system fits within particularRESPONSIBILITY LAYERS concisely describes a key aspect of its scope and role.

Figure 17.4. A structure that allows some components to span layers



• 여러 Layer에 존재하는 단일 Bound Context

• Anti-corruption Layer의 Facade에서 제공하는 서비스가 별도의 계층에 존재

• Context 안에서는 동일하게 익숙한 Layer를 기준으로 모델을 정리

If the legacy subsystem's capabilities are being accessed through a FACADE, you may be able todesign each SERVICE offered by the FACADE to fit within one layer.

The interior of the Shipping Coordination application, being a legacy in this example, is presentedas an undifferentiated mass. But a team on a project with a well-established large-scale structurespanning the CONTEXT MAP could choose, within their CONTEXT, to order their model by the samefamiliar LAYERS.

Figure 17.5. The same structure applied within a CONTEXT and across theCONTEXT MAP as a whole



• 동일한 구조가 Context 범위 및 Context Map 전체에 걸쳐 적용됨

• Cargo, Route, Transport Leg의 구조가 여러 Context에서 사용됨

• 운영: Cargo, Route

• 잠재기능: Transport Leg

• 이와 같은 경우 단일한 개념 집합으로서 대규모 구조가 지닌 가치를 무너뜨릴 수 있음

If the legacy subsystem's capabilities are being accessed through a FACADE, you may be able todesign each SERVICE offered by the FACADE to fit within one layer.

The interior of the Shipping Coordination application, being a legacy in this example, is presentedas an undifferentiated mass. But a team on a project with a well-established large-scale structurespanning the CONTEXT MAP could choose, within their CONTEXT, to order their model by the samefamiliar LAYERS.

Figure 17.5. The same structure applied within a CONTEXT and across theCONTEXT MAP as a whole


대규모 구조와 디스틸레이션의 결합

• 대규모 구조와 디스틸레이션은 상호 보완적인 관계

• 대규모 구조는 Core Domain 안의 관계를 명확하게 함

• 대규모 구조 제체가 Core Domain이 될 수 도 있음

[ Team LiB ]

Combining Large-Scale Structures and DistillationThe concepts of large-scale structure and distillation also complement each other. The large-scalestructure can help explain the relationships within the CORE DOMAIN and between GENERICSUBDOMAINS.

Figure 17.6. MODULES of the CORE DOMAIN (in bold) and GENERIC SUBDOMAINSare clarified by the layers.

At the same time, the large-scale structure itself may be an important part of the CORE DOMAIN.For example, distinguishing the layering of potential, operations, policy, and decision supportdistills an insight that is fundamental to the business problem addressed by the software. Thisinsight is especially useful if a project is carved up into many BOUNDED CONTEXTS, so that the modelobjects of the CORE DOMAIN don't have meaning over much of the project.

[ Team LiB ]


평가 먼저

• 프로젝트에 대한 전략적 설계를 다룰 때는 현상황을 명확히 평가하는 일부터 시작

• Context Map을 그려라. 일관된 Context Map을 그릴 수 있는가? 그렇지 않다면 모호한 상황이 있는가?

• 프로젝트 상의 언어를 쓰는데 힘써라. Ubiquitous Language가 개발에 도움을 줄 만큼 풍부한가?

• 무엇이 중요한지 이해하라.

• Core Domain을 식별했는가?

• Domain Vision Statement가 있는가? Domain Vision Statement를 작성할 수 있는가?

• 프로젝트에 사용하는 기술이 Model Driven Design에 유리한가?

• 팀 내 개발자가 필요한 기술 역량을 갖췄는가?

• 개발자들이 도메인을 잘 알고 있는가? 개발자들이 도메인에 관심이 있는가?

• 처음부터 이러한 질문에 완벽한 대답을 찾을 순 없지만, 이러한 일들이 전략적 설계의 출발점을 마련해 준다.


누가 전략을 세우는가? (1/2)

• 전통적 아키텍처의 전략적 설계

• 개발이 시작되기전 영향력있는 팀이 구성되어 전략을 수립

• 일반적으로 효과적이지 못함.

• Why? 전략적 설계는 프로젝트 전반에 걸처 적용되어야 함

• 너무 규범적이지 않으면서, 효과적인 의사 결정을 위한 근본 원칙을 적용 필요


누가 전략을 세우는가? (2/2)

• 저자의 관점에서 상당한 가치를 제공하는 두가지 형식

• 애플리케이션에서 창발하는 구조

• 중앙 통제 없이도 운영되고, Evolving order에 따라 공유하는 일련의 원칙에 도달함으로써 질서가 명령이 아닌 유기적으로 성장

• 고객(애플리케이션 개발팀) 중심의 아키텍처 팀

• 전략을 여러팀에서 공유할 경우 의사 결정을 어느정도 중앙 집중화하는 것이 효율적

• 단, 아키텍처 팀의 구성원은 개발자와 긴밀히 협업하는 의 진정한 협력자여야 함


전략적 설계를 결정을 위한 6가지 필수 요소

• 의사 결정은 팀 전체에 퍼져야 한다

• 의사 결정 프로세스는 피드백을 흡수해야 한다

• 계획은 발전을 감안해야 한다

• Evolving Order는 통찰력이 깊어짐에 따라 대규모 구조의 지속적인 변화를 강조

• 아키텍처 팀에서 가장 뛰어나고 똑똑한 사람들을 모두 데려가서는 안된다

• 모든 애플리케이션 팀에는 반드시 능력이 출중한 설계자가 포함돼 있어야 한다

• 전략적 설계를 시도하는 모든팀은 반드시 도메인 지식을 겸비해야 한다

• 전략적 설계에는 최소주의와 겸손이 필요하다

• 객체는 전문가, 개발자는 다방면에 지식이 풍부한 사람

• 한 개인이 배울 수 잇는 양에는 한계가 있지만, 지나친 전문화는 도메인 주도 설계의 활력을 저해


기술 프레임워크도 마찬가지다

• 장점: 도메인을 다른 관심사로부터 격리되게 함으로서 개발 속도를 향상 시킴

• 단점: 도메인 모델에 대한 표현력 있는 구현과 손쉬운 변경을 방해할 수 있음

• 전략적 설계와 마찬가지로 발전, 최소주의 애플리케이션 개발팀의 관여는 기술 아키텍처에서도 많은 도움이 된다

• 확실히 프레임워크를 엉망으로 만드는 한가지 태도

• 멍청이들을 위한 프레임워크를 작성하지 마라

• 사용자의 수준을 낮게 평가: 지나친 제약사항을 부여하여 프레임워크와의 장벽을 쌓게 됨

• 프레임워크 사용자에 대한 존중이 필요


도메인 주도 설계 ch17

Technology

Transcript of 도메인 주도 설계 ch17