도메인 주도 설계 - 16 대규모 구조

도메인 주도 설계 16. 대규모 구조

아꿈사

박상혁 ([email protected])

대규모 구조

• 설계를 관리 가능한 응집력 있는 MODULE로 분해

• 굉장히 많은 MODULE이 생겨남

• 기능의 특정 측면을 보려면 어떤 패키지를 찾아야 할까?

• 새 클래스는 어디다 둬야 할까?

• 이런 작은 패키지 중 일부는 실제로 어떤 의미가 있는가?

• 그와 같은 패키지는 서로 얼마나 잘 어울릴까?

• MODULAR를 중심으로 분해하더라도 큰 모델은 파악하기에 너무 복잡할 수 있다!

대규모 구조

• 프로젝트의 규모와 상관없이 사람들은 시스템의 다른 부분에서 어느 정도 독립적으로 일해야 한다

• 큰 시스템에, 해당 시스템의 요소를 전체 설계에 걸친 패턴에서의 역할 측면에서 해석하게 할 수 있는 지배적익 원칙이 없다면 개발자들은 나무만 보고 숲을 보지 못한다.

• 전체의 세부 사항을 깊이 파고들지 않고도 전체의 각 부분이 담당하는 역할을 이해할 수 있어야 한다

대규모 구조의 패턴

MODEL-DRIVEN DESIGN

SYSTEM METAPHOR

RESPONSIBILITY LAYER

KNOWLEDGE LEVEL

PLUGGABLE COMPONENT FRAMEWORK

EVOLVING ORDER

EVOLVING ORDER 발전하는 질서

• 구조화 되지 않은 설계에서 발생하는 비용을 경험한 적이 있는가?

• 이런 혼란을 피하고자 프로젝트에서는 다양한 방법으로 개발을 제약하는 아키텍처를 부과한다

• 아무나 설계할 수 있다면 – 누구도 전체적으로 이해할 수 없는 시스템이 만들어지고

– 이런 시스템은 유지보수 하기 어렵다

• 그러나 아키텍처는 사전 설계와 관련한 가정을 둠으로써 프로젝트를 속박할 수 있고, 애플리케이션의 특정 부분에 대해 개발자/설계자의 권한을 너무 많이 앗아갈 수 있다.

EVOLVING ORDER 발전하는 질서

• 개념적인 대규모 구조가 애플리케이션과 함께 발전하게 해서 발전 과정에서 전혀 다른 형식의 구조로도 변화할 수 있게 하라.

• 반드시 세부적인 지식을 토대로 내려야 할 세부적인 설계 및 모델과 관련된 의사결정을 과도하게 제약해서는 안된다.


MODEL-DRIVEN DESIGN

SYSTEM METAPHOR


KNOWLEDGE LEVEL


EVOLVING ORDER

SYSTEM METAPHOR 시스템 은유

• 소프트웨어 설계는 매우 추상적이고 파악하기 힘든 경향이 있다.

• 개발자와 사용자가 모두 시스템을 이해하고 시스템을 전체적으로 바라보는 시각을 공유할 구체적인 수단이 필요하다

• '시스템 은유'는 어찌됐건 일종의 비유에 불과하므로 다양한 모델이 적절한 방법으로 '시스템 은유'에 매핑될 수 있다

• 어떤 시스템의 구체적인 비유가 나타나 팀원의 상상력을 포착하고 유용한 방향으로 사고를 이끄는 것으로 보인다면 그것을 대규모 구조로 채택하라


MODEL-DRIVEN DESIGN

SYSTEM METAPHOR


KNOWLEDGE LEVEL


EVOLVING ORDER

RESPONSIBILITY LAYER 책임 계층

• 각 개별 객체에 손수 만든 책임이 할당돼 있다면 가이드라인도 없고, 균일함도 없고, 넓은 범위에 걸친 도메인을 동시에 다룰 능력도 없는 셈이다. 큰 모델이 응집력을 부여하려면 그러한 책임 할당에 특정 구조를 도입하는 것이 도움이 된다.

• 계층은 시스템 구획으로서...

• 모델에 존재하는 개념적 의존성과 도메인의 여러 부분에 대한 다양한 변화율과 변화의 근원을 검토하라. 도메인에서 자연적인 층을 식별하면 그것을 광범위한 추상적 책임으로 간주하라

• AGGREGATE, MODULE과 같은 각 도메인 객체의 책임이 한 계층의 책임안에서 말끔히 맞아 떨어지로록 모델을 리팩터링하라


• 그림 16-3


• "운영" 책임과 "기능"책임

• 그림 16-6


• "의사결정 지원" 책임

• 그림 16-8


• 그림 16-11


MODEL-DRIVEN DESIGN

SYSTEM METAPHOR


KNOWLEDGE LEVEL


EVOLVING ORDER

KNOWLEDGE LEVEL 지식 수준

• 더 넓은 범위의 규칙으로 제약되기 전까지 모델의 특정 부분을 사용자의 손에 맡겨야 할 때 생기는 문제를 해결한다

• 도메일을 모델링하기 보다 모델을 구조화한다


• 그림 16-15


• 그림 16-17


• 그림 16-19


• ENTITY 간의 역할과 관계가 각 상황마다 다양하게 작용하는 애플리케이션에서는 복잡성이 폭발적으로 증가할 수 있다

• 완전히 일반화된 모델이나 고도로 맞춤화가 가능한 모델도 사용자의 욕구를 충족하지 못한다 – 다른 타입을 참조하거나

– 각종 상황에서 여러가지 방법으로 쓰일 속성을 갖게 된다

• 기본적인 모델의 구조와 행위를 서술하고 제약하는 데 쓸 수 있는 별도의 객체 집합을 만들어라

• 이러한 관심사를 두가지 '수준'으로 분리해서 하나는 매우 구체적으로 만들고 다른 하나는 사용자나 관리자의 맞춤화가 가능한 규칙과 지식을 반영하게 만들어라


• 그림 16-21


• 그림 16-22


MODEL-DRIVEN DESIGN

SYSTEM METAPHOR


KNOWLEDGE LEVEL


EVOLVING ORDER


• 인터페이스와 상호작용에 대한 ABSTRACT CORE를 정제하고 그러한 인터페이스의 다양한 구현이 자유롭게 대체될 수 있는 프레임워크를 만들어라

• 이와 마찬가지로 컴포넌트가 ABSTRACT CORE의 인터페이스를 통해 정확히 작동하는 한 어떠한 애플리케이션에서도 그러한 컴포넌트를 사용할 수 있게 하라.

• MAVEN ?

구조는 얼마나 제약성을 지녀야 하는가?

• 여러가지 대규모 구조가 가능하고, 심지어 일반화된 구조 패턴 안에서도 규칙을 얼마나 제약적으로 만드는가에 관한 선택의 여지는 많다

• 제약은 개발자가 필요로 하는 유연함을 앗아갈 수 있다

• 프레임워크를 만들고 대규모 구조의 구현을 엄격히 통제하고자 하는 유혹을 이겨내야 한다

• 대규모 구조가 공헌하는 가장 중요한 바는 개념적 응집성과 도메인에 대한 통찰력을 주는 것이다

잘 맞아떨어지는 구조를 향한 리팩터링

• 최소주의 – 구조를 간단하고 가볍게

– 초반에는 '시스템은유'나 몇 가지 '책임계층'과 같은 느슨한 구조

• 의사소통과 자기 훈련 – 새로운 개발과 리팩터링을 할 때 반드시 구조를 따른다

– 대부분의 대규모 구조가 느슨한 개념적 지침이라서 팀은 반드시 '자기 훈련'을 수행해야 한다

잘 맞아떨어지는 구조를 향한 리팩터링

• 재구조화가 유연한 설계를 낳는다 – 구조는 시스템의 복잡성이 증가하고 이해가 깊어질수록 발전한다

– 구조가 바뀔 때 전체 시스템은 새로운 질서를 따르도록 바뀌어야 한다

• 디스틸레이션은 부하를 줄인다 – 지속적인 디스틸레이션

끗

QnA

도메인 주도 설계 - 16 대규모 구조

Documents