도메인 주도 설계 - 16 대규모 구조
- 1. 도메인 주도 설계 16. 대규모 구조 아꿈사 박상혁 (kazuyapsh@gmail.com)
- 2. 대규모 구조 • 설계를 관리 가능한 응집력 있는 MODULE로 분해 • 굉장히 많은 MODULE이 생겨남 • 기능의 특정 측면을 보려면 어떤 패키지를 찾아야 할까? • 새 클래스는 어디다 둬야 할까? • 이런 작은 패키지 중 일부는 실제로 어떤 의미가 있는가? • 그와 같은 패키지는 서로 얼마나 잘 어울릴까? • MODULAR를 중심으로 분해하더라도 큰 모델은 파악하기에 너무 복잡할 수 있다!
- 3. 대규모 구조 • 프로젝트의 규모와 상관없이 사람들은 시스템의 다른 부분에서 어 느 정도 독립적으로 일해야 한다 • 큰 시스템에, 해당 시스템의 요소를 전체 설계에 걸친 패턴에서의 역할 측면에서 해석하게 할 수 있는 지배적익 원칙이 없다면 개발 자들은 나무만 보고 숲을 보지 못한다. • 전체의 세부 사항을 깊이 파고들지 않고도 전체의 각 부분이 담당 하는 역할을 이해할 수 있어야 한다
- 4. 대규모 구조의 패턴 SYSTEM METAPHOR MODEL-DRIVEN RESPONSIBILITY DESIGN LAYER EVOLVING ORDER KNOWLEDGE LEVEL PLUGGABLE COMPONENT FRAMEWORK
- 5. EVOLVING ORDER 발전하는 질서 • 구조화 되지 않은 설계에서 발생하는 비용을 경험한 적이 있는가? • 이런 혼란을 피하고자 프로젝트에서는 다양한 방법으로 개발을 제약하는 아키텍처를 부과한다 • 아무나 설계할 수 있다면 – 누구도 전체적으로 이해할 수 없는 시스템이 만들어지고 – 이런 시스템은 유지보수 하기 어렵다 • 그러나 아키텍처는 사전 설계와 관련한 가정을 둠으로써 프로젝트 를 속박할 수 있고, 애플리케이션의 특정 부분에 대해 개발자/설계 자의 권한을 너무 많이 앗아갈 수 있다.
- 6. EVOLVING ORDER 발전하는 질서 • 개념적인 대규모 구조가 애플리케이션과 함께 발전하게 해서 발전 과정에서 전혀 다른 형식의 구조로도 변화할 수 있게 하라. • 반드시 세부적인 지식을 토대로 내려야 할 세부적인 설계 및 모델 과 관련된 의사결정을 과도하게 제약해서는 안된다.
- 7. 대규모 구조의 패턴 SYSTEM METAPHOR MODEL-DRIVEN RESPONSIBILITY DESIGN LAYER EVOLVING ORDER KNOWLEDGE LEVEL PLUGGABLE COMPONENT FRAMEWORK
- 8. SYSTEM METAPHOR 시스템 은유 • 소프트웨어 설계는 매우 추상적이고 파악하기 힘든 경향이 있다. • 개발자와 사용자가 모두 시스템을 이해하고 시스템을 전체적으로 바라보는 시각을 공유할 구체적인 수단이 필요하다 • '시스템 은유'는 어찌됐건 일종의 비유에 불과하므로 다양한 모델 이 적절한 방법으로 '시스템 은유'에 매핑될 수 있다 • 어떤 시스템의 구체적인 비유가 나타나 팀원의 상상력을 포착하고 유용한 방향으로 사고를 이끄는 것으로 보인다면 그것을 대규모 구조로 채택하라
- 9. 대규모 구조의 패턴 SYSTEM METAPHOR MODEL-DRIVEN RESPONSIBILITY DESIGN LAYER EVOLVING ORDER KNOWLEDGE LEVEL PLUGGABLE COMPONENT FRAMEWORK
- 10. RESPONSIBILITY LAYER 책임 계층 • 각 개별 객체에 손수 만든 책임이 할당돼 있다면 가이드라인도 없 고, 균일함도 없고, 넓은 범위에 걸친 도메인을 동시에 다룰 능력 도 없는 셈이다. 큰 모델이 응집력을 부여하려면 그러한 책임 할당 에 특정 구조를 도입하는 것이 도움이 된다. • 계층은 시스템 구획으로서... • 모델에 존재하는 개념적 의존성과 도메인의 여러 부분에 대한 다 양한 변화율과 변화의 근원을 검토하라. 도메인에서 자연적인 층 을 식별하면 그것을 광범위한 추상적 책임으로 간주하라 • AGGREGATE, MODULE과 같은 각 도메인 객체의 책임이 한 계 층의 책임안에서 말끔히 맞아 떨어지로록 모델을 리팩터링하라
- 11. RESPONSIBILITY LAYER 책임 계층 • 그림 16-3
- 12. RESPONSIBILITY LAYER 책임 계층 • "운영" 책임과 "기능"책임 • 그림 16-6
- 13. RESPONSIBILITY LAYER 책임 계층 • "의사결정 지원" 책임 • 그림 16-8
- 14. RESPONSIBILITY LAYER 책임 계층 • 그림 16-11
- 15. 대규모 구조의 패턴 SYSTEM METAPHOR MODEL-DRIVEN RESPONSIBILITY DESIGN LAYER EVOLVING ORDER KNOWLEDGE LEVEL PLUGGABLE COMPONENT FRAMEWORK
- 16. KNOWLEDGE LEVEL 지식 수준 • 더 넓은 범위의 규칙으로 제약되기 전까지 모델의 특정 부분을 사 용자의 손에 맡겨야 할 때 생기는 문제를 해결한다 • 도메일을 모델링하기 보다 모델을 구조화한다
- 17. KNOWLEDGE LEVEL 지식 수준 • 그림 16-15
- 18. KNOWLEDGE LEVEL 지식 수준 • 그림 16-17
- 19. KNOWLEDGE LEVEL 지식 수준 • 그림 16-19
- 20. KNOWLEDGE LEVEL 지식 수준 • ENTITY 간의 역할과 관계가 각 상황마다 다양하게 작용하는 애 플리케이션에서는 복잡성이 폭발적으로 증가할 수 있다 • 완전히 일반화된 모델이나 고도로 맞춤화가 가능한 모델도 사용 자의 욕구를 충족하지 못한다 – 다른 타입을 참조하거나 – 각종 상황에서 여러가지 방법으로 쓰일 속성을 갖게 된다 • 기본적인 모델의 구조와 행위를 서술하고 제약하는 데 쓸 수 있는 별도의 객체 집합을 만들어라 • 이러한 관심사를 두가지 '수준'으로 분리해서 하나는 매우 구체적 으로 만들고 다른 하나는 사용자나 관리자의 맞춤화가 가능한 규 칙과 지식을 반영하게 만들어라
- 21. KNOWLEDGE LEVEL 지식 수준 • 그림 16-21
- 22. KNOWLEDGE LEVEL 지식 수준 • 그림 16-22
- 23. 대규모 구조의 패턴 SYSTEM METAPHOR MODEL-DRIVEN RESPONSIBILITY DESIGN LAYER EVOLVING ORDER KNOWLEDGE LEVEL PLUGGABLE COMPONENT FRAMEWORK
- 24. PLUGGABLE COMPONENT FRAMEWORK • 인터페이스와 상호작용에 대한 ABSTRACT CORE를 정제하고 그 러한 인터페이스의 다양한 구현이 자유롭게 대체될 수 있는 프레 임워크를 만들어라 • 이와 마찬가지로 컴포넌트가 ABSTRACT CORE의 인터페이스를 통해 정확히 작동하는 한 어떠한 애플리케이션에서도 그러한 컴포 넌트를 사용할 수 있게 하라. • MAVEN ?
- 25. 구조는 얼마나 제약성을 지녀야 하는가? • 여러가지 대규모 구조가 가능하고, 심지어 일반화된 구조 패턴 안 에서도 규칙을 얼마나 제약적으로 만드는가에 관한 선택의 여지는 많다 • 제약은 개발자가 필요로 하는 유연함을 앗아갈 수 있다 • 프레임워크를 만들고 대규모 구조의 구현을 엄격히 통제하고자 하 는 유혹을 이겨내야 한다 • 대규모 구조가 공헌하는 가장 중요한 바는 개념적 응집성과 도메 인에 대한 통찰력을 주는 것이다
- 26. 잘 맞아떨어지는 구조를 향한 리팩터링 • 최소주의 – 구조를 간단하고 가볍게 – 초반에는 '시스템은유'나 몇 가지 '책임계층'과 같은 느슨한 구조 • 의사소통과 자기 훈련 – 새로운 개발과 리팩터링을 할 때 반드시 구조를 따른다 – 대부분의 대규모 구조가 느슨한 개념적 지침이라서 팀은 반드시 '자기 훈련'을 수행해야 한다
- 27. 잘 맞아떨어지는 구조를 향한 리팩터링 • 재구조화가 유연한 설계를 낳는다 – 구조는 시스템의 복잡성이 증가하고 이해가 깊어질수록 발전한다 – 구조가 바뀔 때 전체 시스템은 새로운 질서를 따르도록 바뀌어야 한다 • 디스틸레이션은 부하를 줄인다 – 지속적인 디스틸레이션
- 28. 끗 QnA