1. Ch.17 전략의 종합
(Domain Driven Design)
chois79
12년 11월 11일 일요일

2. 개요
• 도메인 주도적인 전략적 설계를 위한 기본 원칙
• 컨텍스트
• 디스틸레이션
• 대규모 구조
• 이 장에서는 전략적 설계를 위한 방법을 제시
• 기본 원칙들이 어떻게 같이 사용되는가?
• 전략적 설계를 위해 해야 할 일의 우선 순위는?
• 전략을 고안하는 일은 어떻게 시작해야 하는가?
12년 11월 11일 일요일

3. 대규모 구조와 CONTEXT의 결합 형태 (1/3)
• 단일 Bound Context 안에서 Responsibility Layer
• Responsibility Layer의 가장 단순한 형태
Such a local structure can be useful in a very complicated but unified model, raising the complexity
ceiling 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 whole
integrated system and how do the parts relate to each other? Then the large-scale structure can
be used to organize the CONTEXT MAP. In this case, the terminology of the structure applies to the
whole project (or at least some clearly bounded part of it). unified model, raising the complexity
Such a local structure can be useful in a very complicated but
ceiling on how much can be maintained in a single BOUNDED CONTEXT.
• But on many projects, the greater challenge is to사이에서의each play in thetogether. ofLayer
구분된 Bound Context , understand how disparateof components
Figure 17.3. Structure imposed on but what part does
They may be partitioned into separate CONTEXTS
Responsibility
the relationships
parts fit
whole
distinct BOUNDED CONTEXTS
integrated system and how do the parts relate to each other? Then the large-scale structure can
be used to organize the CONTEXT MAP. In this case, the terminology of the structure applies to the
whole project (or at least some clearly bounded part of it).
Figure 17.3. Structure imposed on the relationships of components of
distinct BOUNDED CONTEXTS
Suppose you want to adopt RESPONSIBILITY LAYERS, but you have a legacy system whose
organization is inconsistent with your desired large-scale structure. Do you have to give up your
12년 일요일
11월 11일No, but you have to acknowledge the actual place the legacy has within the structure. In
LAYERS ?

4. 대규모 구조와 CONTEXT의 결합 형태 (2/3)
• 여러 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 to
design 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 presented
as 11일 일요일
12년 11월an undifferentiated mass. But a team on a project with a well-established large-scale structure

5. 대규모 구조와 CONTEXT의 결합 형태 (3/3)
• If 동일한 구조가 Context 범위 및 Context Map 전체에 걸쳐 적용됨 , you may be able to
the legacy subsystem's capabilities are being accessed through a FACADE
design 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 presented
• Cargo, Route, Transport Leg의 구조가 여러 Context에서 사용됨
as an undifferentiated mass. But a team on a project with a well-established large-scale structure
spanning the CONTEXT MAP could choose, within their CONTEXT , to order their model by the same
familiar LAYERS .
• 운영: Cargo, Route
Figure 17.5. The same structure applied within a CONTEXT and across the
CONTEXT MAP as a whole
• 잠재기능: Transport Leg
• 이와 같은 경우 단일한 개념 집합으로서 대규모 구조가 지닌 가치를 무너뜨릴 수 있음
12년 11월 11일 일요일

6. 대규모 구조와 디스틸레이션의 결합
[ Team LiB ]
• 대규모 구조와 디스틸레이션은 상호 보완적인 관계
Combining Large-Scale Structures and Distillation
The concepts of large-scale structure and distillation also complement each other. The large-scale
• 대규모 구조는 Core Domain 안의 관계를 명확하게 함
structure can help explain the relationships within the CORE DOMAIN and between GENERIC
SUBDOMAINS.
Figure Core Domain이 될 CORE 있음
• 대규모 구조 제체가 17.6. MODULES of the 수 도DOMAIN (in bold) and GENERIC SUBDOMAINS
are 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 support
12년 11월 11일 일요일 distills an insight that is fundamental to the business problem addressed by the software. This

7. 평가 먼저
• 프로젝트에 대한 전략적 설계를 다룰 때는 현상황을 명확히 평가하는 일부터 시작
• Context Map을 그려라. 일관된 Context Map을 그릴 수 있는가? 그렇지 않다면 모호한 상황이 있는가?
• 프로젝트 상의 언어를 쓰는데 힘써라. Ubiquitous Language가 개발에 도움을 줄 만큼 풍부한가?
• 무엇이 중요한지 이해하라.
• Core Domain을 식별했는가?
• Domain Vision Statement가 있는가? Domain Vision Statement를 작성할 수 있는가?
• 프로젝트에 사용하는 기술이 Model Driven Design에 유리한가?
• 팀 내 개발자가 필요한 기술 역량을 갖췄는가?
• 개발자들이 도메인을 잘 알고 있는가? 개발자들이 도메인에 관심이 있는가?
• 처음부터 이러한 질문에 완벽한 대답을 찾을 순 없지만, 이러한 일들이 전략적 설계의 출발점을 마련해 준다.
12년 11월 11일 일요일

8. 누가 전략을 세우는가? (1/2)
• 전통적 아키텍처의 전략적 설계
• 개발이 시작되기전 영향력있는 팀이 구성되어 전략을 수립
• 일반적으로 효과적이지 못함.
• Why? 전략적 설계는 프로젝트 전반에 걸처 적용되어야 함
• 너무 규범적이지 않으면서, 효과적인 의사 결정을 위한 근본 원칙을 적용 필요
12년 11월 11일 일요일

9. 누가 전략을 세우는가? (2/2)
• 저자의 관점에서 상당한 가치를 제공하는 두가지 형식
• 애플리케이션에서 창발하는 구조
• 중앙 통제 없이도 운영되고, Evolving order에 따라 공유하는 일련의 원칙에 도달
함으로써 질서가 명령이 아닌 유기적으로 성장
• 고객(애플리케이션 개발팀) 중심의 아키텍처 팀
• 전략을 여러팀에서 공유할 경우 의사 결정을 어느정도 중앙 집중화하는 것이 효율적
• 단, 아키텍처 팀의 구성원은 개발자와 긴밀히 협업하는 의 진정한 협력자여야 함
12년 11월 11일 일요일

10. 전략적 설계를 결정을 위한 6가지 필수 요소
• 의사 결정은 팀 전체에 퍼져야 한다
• 의사 결정 프로세스는 피드백을 흡수해야 한다
• 계획은 발전을 감안해야 한다
• Evolving Order는 통찰력이 깊어짐에 따라 대규모 구조의 지속적인 변화를 강조
• 아키텍처 팀에서 가장 뛰어나고 똑똑한 사람들을 모두 데려가서는 안된다
• 모든 애플리케이션 팀에는 반드시 능력이 출중한 설계자가 포함돼 있어야 한다
• 전략적 설계를 시도하는 모든팀은 반드시 도메인 지식을 겸비해야 한다
• 전략적 설계에는 최소주의와 겸손이 필요하다
• 객체는 전문가, 개발자는 다방면에 지식이 풍부한 사람
• 한 개인이 배울 수 잇는 양에는 한계가 있지만, 지나친 전문화는 도메인 주도 설계의 활력을 저해
12년 11월 11일 일요일

11. 기술 프레임워크도 마찬가지다
• 장점: 도메인을 다른 관심사로부터 격리되게 함으로서 개발 속도를 향상 시킴
• 단점: 도메인 모델에 대한 표현력 있는 구현과 손쉬운 변경을 방해할 수 있음
• 전략적 설계와 마찬가지로 발전, 최소주의 애플리케이션 개발팀의 관여는 기술 아키텍처에서도 많은
도움이 된다
• 확실히 프레임워크를 엉망으로 만드는 한가지 태도
• 멍청이들을 위한 프레임워크를 작성하지 마라
• 사용자의 수준을 낮게 평가: 지나친 제약사항을 부여하여 프레임워크와의 장벽을 쌓게 됨
• 프레임워크 사용자에 대한 존중이 필요
12년 11월 11일 일요일