모델 주도 설계의 기본요소

도메인의 격리choong83

navigation map

도메인의 격리

LAYERED ARCHITECTURE (문제)

- 단기적으로 가장 쉬운방법.

-도메인관련 코드를 확인 및 추론이 힘들어진다.

- UI 변경으로 업무로직이 변경, 업무로직이 변경 되면서 UI를 변경.

- 응집력 없고 모델주도적인 객체는 구현은 어려워진다.

비즈니스 로직

UI + Database + 기타 등등 코드

LAYERED ARCHITECTURE (해결)

- 매우 복잡한 작업을 처리하는 소프트웨어는 관심사의 분리가 필요 하며 , 시스템내의 상호작용은 분리와 상관없이 유지.

- 소프트웨어를 분리하는 방법으로 LAYERED ARCHITECTURE, 좀더 구체적으로 몇개의 일반화된 계층을 사용한다.

LAYERED ARCHITECTURE (계층화)

- 직관적으로 보여짐

- 한계층의 모든 요소는 오직 같은 계층에 존재해야한다.

- 계층상 아래위치한 요소에만 의존한다.

- 위로 올라가는 의사 소통은 간접적인 메커니즘을 거쳐야한다.

LAYERED ARCHITECTURE (네가지 계념적 계층)

- 사용자 인터페이스(표현 계층) : 정보를 보여주고, 명령을 해석하는 일을 책임진다.

- 응용 계층: 수행할 작업을 정의하고, 도메인 객체가 문제를 해결하게 한다. 업무상 중요하거나 타 시스템의 응용계층과 상호작용 필요한 부분을 책임진다.

또한 이 계층은 얇게 유지된다.

-도메인 계층(모델 계층) : 업무 개념 과 정보, 규칙을 표현하는 일을 책임지며, 업무관련 상태를 제어한다.

- 인프라 스트럭처 계층 : 상위계층을 지원하는 일반화된 기술적 기능을 제공.

메시지 전송, 도메인 영속화 및 아키텍쳐 프레임워크를 통해 네가지 계층에 대한 상호작용 패턴 지원

LAYERED ARCHITECTURE (예제)

LAYERED ARCHITECTURE (계층간 관계 설정#1)

- 각 계층은 의존성을 오직 한 방향으로 느슨하게 결합

- 상위 계층은 하위 계층의 공개 인터페이스를 호출

- 상호 작용 수단을 이용해 하위 계층의 구성요소를 직접적으로 사용하거나 조작가능하다.

- 하위 수준의 객체가 상위 객체와 소통해야하는 경우 콜백(callback)이나 observer 패턴을 이용한다.

- 응용계층과 도메인계층에 UI를 연결하는 패턴은 MVC에서 유래한다.

LAYERED ARCHITECTURE (계층간 관계 설정#2)

- 보통 인프라스트럭처 계층은 도메인 계층 아래에 있으므로 도메인의 대한 정보를 가져서는 안된다.

- 인프라스트럭처 기능은 대개 SERVICE로 제공 되어진다.

- 응용계층과 도메인 계층에서는 인프라스트럭처 계층에서 제공하는 SERVICE를 요청한다.

- 모든 인프라스트럭처가 상위계층에서 호출 할 수 있는 SERVICE 형태로 만들어지는것은 아니고 다른계층의 기본적인 기능적인 기능을 직접적으로 지원하도록 제공되어지는 아키텍쳐프레임워크도 제공한다.

LAYERED ARCHITECTURE (아키텍처 프레임워크 #1)

- 인프라스트럭처가 SERVICE 형태로 제공되면 직관적 이지만 일부 기술적인 문제는 더욱 침습적인 형태의 아키텍쳐프레임워크가 필요하다.

- 요구사항을 통합하는 프레임워크는 다른계층이 특수한 방식으로 구현되기를 요구

- 가장 좋은 프레임워크는 도메인 개발자가 모델을 표현 하는데만 집중하게 해서 복합적 기술을 해결하게 한다.

- 프레임워크에서 도메인설계와 관련 의사결정을 제약하면 개발을 더디게 하는 문제가 있다.

LAYERED ARCHITECTURE (아키텍처 프레임워크 #2)

- 프레임워크의 목적은 도메인 모델을 표현하고 해당 도메인 모델을 이용해 문제를 해결하는데 있다.

- 프레임워크의 모든기능을 사용할 필요가 없다.

- 프레임워크의 유용한 기능만 분별력있게 적용 구현하면 프레임워크간 결합이 줄어 든다.

LAYERED ARCHITECTURE (도메인계층은 모델이 살아가는 곳)

- LAYERED ARCHITECTURE는 다양한 계층화 계획에 사용되지만, 도메인 주도 설계에서는 오직 한 가지 특정한 계층이 존재 할 것을 요구한다.

- '도메인 계층'은 일련의 개념 모델과 설계요소에 직접적 으로 관계되는 있는것을 명시한다.

- 도메인 주도 설계의 전제 조건은 도메인 구현을 격리하는것이다.

LAYERED ARCHITECTURE(결론)

- 복잡한 프로그램을 여러계층으로 나눠라

-응집력 있고 아래에 위치한 계층에만 의존하는 각계층에서 설계를 발젼 시켜라

- 상위계층과 결합을 느슨하게 유지하라

- 도메인 모델과관련된 코드는 모두 한계층으로

- 도메인 모델은 사용자 인퍼테이스 코드나 애플맄이션 코드, 인프라스트럭쳐 코드와 격리하라

SMART UI(지능형 UI) '안티 패턴'

- 수많은 프로젝트에서는 SMART UI라고 하는 훨씬 덜 복잡한 설계 접근법을 취한다.

- 도메인 주도 설계 접근법과 상호 배타적.

- 모든 업무로직을 사용자 인터페이스에 작성

SMART UI(지능형 UI) '안티 패턴'

(장점)

- 애플리케이션이 단순하면 생산성이 높고 효과가 즉각적.

- 능력이 부족한 개발자도 가능.

- 요구사항 분석단계에서 결함이 발생하더라도 프로토 타입을 배포한 후에 요구에 맞게 제품을 변경해서 문제를 해결.

- 애플리케이션 서로 분리되므로 규모가 작은 모듈의 납기 일정을 비교적 정확하게 계획 할수 있다.

- 관계형 데이터베이스와 잘어울리고 데이터 수준의 통합이 가능하다.

- 4세대 언어도구와 잘어울린다.

-유지보수 프로그래머가 이해하지 못하는 부븐을 신속하게 재작업 할 수 있다.

SMART UI(지능형 UI) '안티 패턴'

(단점)

- 데이터베이스를 이용하는 방식 말고는 여러 애플리케이션을 통합하기 어렵다.

- 행위의 재상용성이 없으며, 업무에대한 추상화가 이뤄지지 않는다.

- 추상화의 부재로 리팩터링의 여지가 제한된다.

- 복잡성에 금방 압도되어 애플리케이션의 성장 경로는 부가적인 단순 응용으로만 향한다.