DDD 04장 - 도메인의 격리

본 포스트는 도메인 주도 설계 라는 책을 참조하였습니다. 가능하면 본 책을 직접 보시고 DDD를 이해하는 것을 추천드립니다. http://www.aladin.co.kr/shop/wproduct.aspx?ItemId=12174216

LAYERED ARCHITECTURE (계층형 아키텍처)

도메인과 관련없는 코드들이 각 계층에 산재하게 되면?

• 응집력 있고, 모델 주도적인 객체를 구현하는 것이 비현실적인 이야기가 돼버린다.
• 자동화 테스트가 어렵다.
• 도메인에 관련된 코드를 확인하고 추론하기가 굉장히 힘들어진다.

이를 해결하기 위해서는

• 관심사의 분리 (separation of concern)
• 즉, 계층 분리

계층화의 핵심원칙

• 한 계층의 모든 요소는 오직 같은 계층에 존재하는 다른 요소나 계층상 아래 에 위치한 요소에만 의존한다.
• 위로 거슬러 올라가는 의사소통은 반드시 간접적인 매커니즘을 거쳐야 한다.

계층화의 가치 (장점)

• 응집력 강화
• 이해도 향상

대표적인 4계층 아키텍처

사용자 인터페이스 (표현 계층)

응용 계층

• 소프트웨어가 수행할 작업을 정의하고 표현력 있는 도메인 객체가 문제를 해결하게 한다. - 일종의 위임과 상호작용
• 실제 업무를 처리하는 것은 아래 도메인 계층에서 한다. 또한 상태를 가질 수도 없다.
• 트랜젝션 관리가 이 계층에서 이루어진다.

도메인 계층 (모델 계층)

• 실제 업무 처리. 업무용 소프트웨어의 핵심 계층

인프라스트럭쳐 계층

• 메세지 전송
• 도메인 영속화 (예를 들면 DB 저장)

계층화

MODEL-DRIVEN DESIGN을 가능하게 하는 것은 결정적으로 도메인 계층 분리

• 복잡한 프로그램을 여러 개의 계층으로 나눠라.
• 응집력 있고 오직 아래에 위치한 계층에만 의존하는 각 계층에서 설계를 발전시켜라.
• 표준 아키텍처 패턴에 따라 상위 계층과 결합을 느슨하게 유지하라.
• 도메인 모델과 관련된 코드는 모두 한 계층에 모으로 사용자 인터페이스 코드나, 어플리케이션 코드, 인프라스트럭처 코드와 격리하라.
• 도메인 객체(표현이나 저장, 애플리케이션 작업을 관리하는 등의 책임에서 자유로운)는 도메인 모델을 표현하는 것에만 집중할 수 있다.

계층화 결론

모델은 진화를 거듭해 본질적인 업무 지식을 포착해서 해당 업무 지식이 효과를 발휘할 수 있을 만큼 풍부하고 명확해질 것이다.

계층 간 관계 설정

• 계층 간 분리의이점을 잃지 않으면서 각 계층을 서로 연결하는 것이 중요 : 패턴 존재의 이유
• 상위 계층에서 하위 계층으로 공개 인터페이스를 통한 느슨한 연결
• 만약, 하위 계층에서 상위 계층으로 소통해야할 경우 Callback이나 Observer Parttern 등의 아키텍처 패턴을 활용한다.
• MVC 패턴 : 도메인, UI, 응용계층을 연결하는 패턴
• 인프라스트럭처 계층을 Service 추상화를 통해서 느슨하게 연결하는 것이 좋음
• 하지만, 직접적으로 인프라스트럭처를 바로 호출할 수도 있음 (Service를 통하지 않고)

아키텍처 프레임워크

• 일반적으로는 인프라스트럭처 계층을 이용할 시에는 Service를 통하는 것이 좋다
• 하지만 인프라 스트럭쳐로 직접 접근이 필요할 때가 있으며, 이런한 문제를 해결하기 위해서 아키텍처 프레임워크가 필요하다.
• 필요한 기능 만큼만으로 프레임워크를 구성하고, 도메인 모델에 집중할 수 있는 아키텍처를 만들자???? - 프레임워크가 아니라 기능에 의존하자??

잘 이해가 안됨 아키텍처 프레임워크의 필요성을 강조하나 명확하게 이해가 되지 않음

도메인 계층은 모델이 살아가는 곳

DDD에서 중요한 것은 도메인 계층 에 모델과 설계 요소에 관련 모든 것을 명시하고 격리하는 것이다.

SMART UI(지능형 UI) “안티 패턴”

SMART UI vs DDD

두 방법론은 양립할 수 밖에 없다.

• 간단한 요구사항에는 그에 맞는 구조가 필요하다. - SMART UI와 같은
• DDD는 복잡한 수준의 요구사항에 어울리다.

SMART UI 패턴이란?

UI와 콤포넌트가 강결합 상태로 구현 하는 것 예를들면 jsp 내부에서 DB 로직까지 제어하는 거와 같은 절차적프로그래밍에 가까운 그것을 의미한다.

빠르고 상대적으로 이해하기 쉬운 장점이 있으나, 단점은 추상화가 이루어지지 않기 때문에 재사용성이 낮고 리팩터링이 힘들고, 복잡성 대응에 힘들다. 결국은 유지보수가 점점 힘들어져 빠르게 레거시 시스템 이 되버린다.

SMART UI 교훈을 통해서 왜 격리(LAYRED ARCHITECTURE)가 필요한지를 역설적으로 알아본다.

트랜젝션 스크립트 패턴이란?

• SMART UI와 DDD 중간 쯤 위치
• UI와 로직은 분리하지만 객체에 모델은 제공하지 않는다.
• 아키텍처에서 응집력 있는 도메인 설계가 시스템의 다른 부분과 느슨하게 결할될 수 있게 도메인 관련 코드를 격리한다면 아마 그러한 아키텍처는 도메인 주도 설계를 지원할 수 있을 것이다.

복잡한 어플리케이션을 개발하고 있고, MODEL-DRIVEN DESIGN을 하기로 했다면 고통을 감내하고 필요한 전문가를 확보하며 SMART UI를 피해야한다.

다른 종류의 격리

다른 종류의 격리는 다른 챕터에서 다루므로 지금은 그런 게 있다는 정도만 알아두자

중요한 것은 도메인을 격리의 장점은 부수적인 것을 배제하고 도메인 설계에만 집중 할 수 있다는 것이다.