This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| doamin-driven_design:04_isolating_the_domain [2023/08/11 12:32] – [아키텍처 프레임워크] ledyx | doamin-driven_design:04_isolating_the_domain [2024/02/17 15:21] (current) – removed ledyx | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | = 04 도메인의 격리 = | ||
| - | |||
| - | 모델의 각 요소(객체)를 하나하나 구분하지 않고 **하나의 시스템**으로 바라 볼 수 있도록 | ||
| - | __시스템에서 도메인과 **관련이 적은 기능**으로부터 도메인 객체를 분리__ | ||
| - | |||
| - | {{tag> | ||
| - | |||
| - | |||
| - | == Layered Architecture == | ||
| - | |||
| - | // | ||
| - | |||
| - | |||
| - | <note important> | ||
| - | Model-Driven Design을 가능케 하는 것은 결정적으로 **도메인 계층을 분리**하는 데 있다. | ||
| - | </ | ||
| - | |||
| - | |||
| - | <note important> | ||
| - | 복잡한 프로그램을 여러 개의 계층으로 나눠라 | ||
| - | (같은 계층에서는) 응집력 있고 __오직 " | ||
| - | 표준 아키텍처 패턴에 따라 __상위 계층과의 결합을 느슨하게 유지하라__ | ||
| - | **도메인 모델과 관련된 코드는 모두 한 계층에 모으고** | ||
| - | 사용자 인터페이스 코드나 애플리케이션 코드, 인프라스트럭처 코드와 **격리**하라 | ||
| - | </ | ||
| - | |||
| - | |||
| - | === 계층화의 핵심 원칙 === | ||
| - | |||
| - | 계층화의 핵심 원칙은 | ||
| - | |||
| - | 한 계층의 모든 요소는 | ||
| - | **오직 같은 계층에 존재하는 다른 요소** 혹은 **계층상 "< | ||
| - | 에만 의존한다는 것이다. | ||
| - | |||
| - | 위로 거슬러 올라가는 의사소통은 반드시 간접적인 메커니즘을 거쳐야 한다. | ||
| - | |||
| - | === 계층화의 가치 === | ||
| - | |||
| - | 계층화의 가치는 | ||
| - | 각 계층에서 컴퓨터 프로그램의 **특정 측면만을 전문적을 다룬다**는 데 있다. | ||
| - | ... | ||
| - | |||
| - | 거듭 말하지만 경험과 관례를 바탕으로 널리 받아들여지는 계층화가 어느 정도 정해졌다. | ||
| - | ... 대다수의 성공적인 아키텍처에서는 아래의 네 가지 개념적 계층으로 나뉜다. | ||
| - | |||
| - | |||
| - | ^ 계층 | ||
| - | | User Interface (or Presentation Layer) | ||
| - | | Application Layer | 소프트웨어가 **수행할 작업을 정의**하고 표현력 있는 도메인 객체가 **문제를 해결하게 한다.** 이 계층에서 책임지는 작업은 **업무상 중요**하거나 다른 시스템의 **응용 계층과 상호작용**하는 데 필요한 것이다. \\ 이 계층은 얇게 유지된다. 여기에는 **<fc red> | ||
| - | | Domain Layer (or Model Layer) | ||
| - | | Infrastructure Layer | | ||
| - | |||
| - | |||
| - | |||
| - | === 계층 간 관계 설정 === | ||
| - | |||
| - | <note important> | ||
| - | 각 계층은 설계 의존성을 **오직 한 방향**으로만 둬서 느슨하게 결합된다. (상위 → 하위) | ||
| - | |||
| - | * 상위 → 하위 : 하위 계층에 대한 참조를 갖고(최소한 임시로라도) 직접 호출 | ||
| - | * 하위 | ||
| - | </ | ||
| - | |||
| - | ==== 응용 계층 → 도메인 계층 ==== | ||
| - | |||
| - | 응용 계층과 도메인 계층에 UI를 연결하는 패턴은 MVC에서 유래한다. 1970년 Smalltalk 분야에서 발견되어 MVC를 따르는 여러 UI 아키텍처에 영감을 준다. | ||
| - | |||
| - | * 패턴과 참고 서적 | ||
| - | * MVC | ||
| - | * Patterns of Enterprise Application Architecture (Martin Fowler 2003) | ||
| - | * MVP | ||
| - | * Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (Craig Larman 1998) | ||
| - | * Application coordinator pattern ☞ 애플리케이션 계층을 연결하는 접근법 가운데 하나 | ||
| - | |||
| - | |||
| - | ==== 도메인 계층 → 인프라스트럭처 계층 ==== | ||
| - | |||
| - | 인프라스트럭처 계층은 도메인 계층의 하위 계층이므로 **도메인의 어떤 지식**을 갖고, **도메인에 관련된 어떤 활동**이 일어나면 안된다. | ||
| - | 사실 도메인의 지식/ | ||
| - | 분리의 주된 이점은 애플리케이션 계층이 **단순**해져서 애플리케이션 __**본연의 책임에만 집중**__하게 되는 것이며 | ||
| - | 이로써 메시지를 **" | ||
| - | |||
| - | 응용 계층과 도메인 계층에서는 인프라스트럭처 계층에서 제공하는 SERVICE를 요청한다. | ||
| - | 그러나 모든 인프라스트럭처 계층이 상위 계층에서 호충할 수 있는 SERVICE의 형태로 만들어지는 것은 아니다. | ||
| - | 어떤 기술적인 구성요소는 다른 계층의 기본적인 기능을 직접적으로 지원하도록 만들어져(이를 테면, 모든 도메인 객체에 대한 Abstract class를 제공하는 것과 같이) | ||
| - | 그러한 계층과 관계를 맺는 메커니즘(MVC 및 그와 비슷한 패턴의 구현과 같은)을 제공하기도 한다. | ||
| - | 이러한 ' | ||
| - | |||
| - | |||
| - | === Architectural Framework === | ||
| - | |||
| - | |||
| - | |||
| - | == 도메인 계층은 모델이 살아가는 곳 == | ||
| - | |||
| - | |||
| - | == The Smart UI " | ||
| - | |||
| - | 지능형 UI " | ||
| - | |||
| - | |||
| - | == 다른 종류의 격리 == | ||
| - | |||
| - | |||