[DDD] 도메인 주도 설계 - 04. 도메인의 격리

도메인주도 설계(에릭 에반스) 개발도서 관련 : 도메인 격리의 중요성과 방법에 대해 알아보자

소프트웨어의 복잡성을 다루는 지혜

우리는 시스템에서 도메인과 관련이 적은 기능으로부터 도메인 객체를 분리할 필요가 있다.

격리를 위한 정교한 기법을 알아보자.

LAYERED ARCHITECTURE (계층형 아키텍쳐)

특정 도메인을 다루는 프로그램 중에 정말로 도메인에 대해 다루는 코드는 일부분일 것이다.

도메인에 대한 코드 중 상당부분이 도메인과 관련 없는 코드로 구성되어 있게 되면 실제로 필요한 도메인과 관련된 코드를 확인하고 추론하는데 어려움을 겪게 될 것이다.

매우 복잡한 작업을 처리하는 소프트웨어를 만드는 경우 관심사의 분리가 필요하며,
격리된 상태에 있는 각 설계 요소에 집중할 수 있게 된다.
그럼과 동시에 시스템 내의 정교한 상호작용은 그러한 분리와는 상관없이 유지돼야 한다.

계층화의 핵심 원칙

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

계층화의 가치

계층화의 가치는 특정 측면만을 전문적으로 다룬다는 데 있다.
이러한 전문화를 토대로 각 측면에서는 더욱 응집력 있는 설계가 가능해지며, 설계를 훨씬 더 쉽게 이해할 수 있게 된다.

성공적인 아키텍처의 네 가지 개념적 계층

계층	설명
사용자 인터페이스 (표현 계층)	사용자에게 정보를 보여줌 사용자의 명령을 해석
응용 계층	소프트웨어가 수행할 작업을 정의 도메인 객체가 문제를 해결하도록 함 업무상 중요한 부분을 다루며, 다른 시스템의 응용 계층과 상호작용하는 책임을 가짐 이 계층은 얇게 유지되며, 업무 규칙이나 지식이 포함되지 않음, 오직 작업을 조정하고 아래에 위치한 계층에 포함된 도메인 객체의 협력자에게 작업을 위임 업무 상황을 반영하는 상태가 없지만, 진행상황을 반영하는 상태는 가질 수 있음.
도메인 계층 (모델 계층)	업무 개념과 업무 상황에 관한 정보, 업무 규칙을 표현하는 일을 책임짐 업무 상황을 반영하는 상태를 제어하고 사용 상태 저장과 관련된 기술적인 세부사항은 인프라스트럭처에 위임 이 계층은 업무용 소프트웨어의 핵심
인프라스트럭처 계층	상위 계층을 지원하는 일반화된 기술적 기능을 제공 아키텍처 프레임워크를 통해 네 가지 계층에 대한 상호작용 패턴을 지원할 수도 있음

사용자 인터페이스와 응용 계층을 구분짓지 않는 경우, 인프라스트럭처가 여러 개인 경우 등 다양한 형태의 프로젝트가 존재하지만,
MODEL-DRIVEN-DESIGN 가능케 하는 것은 결정적으로 도메인 계층을 분리하는데 있다.

• 복잡한 프로그램을 여러 개의 계층으로 나눠라.
• 응집력 있고 오직 아래에 위치한 계층에만 의존하는 각 계층에서 설계를 발전시켜라.
• 상위 계층과의 결합을 느슨하게 유지하라.
• 도메인 모델과 관련된 코드는 모두 한 계층에 모으고, 그 외 계층과 격리하라.
• 도메인 객체는 도메인 모델을 표현하는 것에만 집중해야 한다.
• 이를 통해 모델은 진화하여 본질적 업무 지식을 포함하는 실질적으로 효과를 발휘하는 풍부하고 명확한 상태가 될 수 있다.

계층 간 관계 설정

도메인 계층 설계의 향상을 위해 계층 분리를 하였지만, 그럼에도 각 계층은 서로 연결돼야 한다. 계층 분리의 이점을 잃지 않으면서 각 계층을 서로 연결하는 것이야말로 각종 패턴이 존재하는 이유다.

각 계층은 설계 의존성을 오직 한 방향으로만 둬서 느슨하게 결합된다.

그러나 하위 수준의 객체가 상위 수준의 객체와 소통해야 할 경우에는 또 다른 메커니즘이 필요한데, 콜백(Callback)이나 Observer 패턴처럼 계층 간에 관계를 맺어주는 아키텍처 패턴을 활용할 수 있다.

이를 돕기위해 MVC 패턴, 모델-뷰 분리 패턴, 애플리케이션 조율자 패턴 등 다양한 패턴들이 존재하지만,
이 모든 패턴의 목적은 도메인 객체를 설계할 때 사용자 인터페이스, 에플리케이션 계층 등에 대한 생각을 하지 않도록 만들어주는 것이다.

인프라스트럭처 계층에서는 도메인 계층에서 어떤 활동이 일어나게 하지 않는다.
도메인의 구체적인 지식을 가져서는 안 된다.

예를들어, 메시지 전송 인터페이스는 인프라스트럭처 계층에 위치할 수 있다.
애플리케이션 계층의 각 요소는 인프라스트럭처 계층에 요청하여 메시지를 전송 할 수 있다.
이러한 분리를 통해 애플리케이션 계층이 더욱 단순해지며 본연의 책임에만 집중할 수 있게 된다.
이로써 메시지를 “언제” 보내는지 알아도 “어떻게” 보내는지는 알 필요가 없어졌다.

아키텍처 프레임워크

가장 바람직한 아키텍처 프레임워크라면 도메인 개발자가 모델을 표현하는 것에만 집중하게 해서 복잡한 기술적 난제를 해결한다.

그러나 프레임워크가 오히려 도메인 설계에 방해되는 경우도 있다.(의사결정을 제약하는 가정이 많거나, 구현을 과중하게 만들어 개발을 더디게 하는 경우)

그럼에도 어찌됐건 아키텍처 프레임워크와 같은 것은 필요하다.
프레임워크의 목적은 도메인 모델을 표현하고 해당 도메인 모델을 이용해 중요한 문제를 해결하는 구현을 만들어내는 데 있다.
프레임워크의 모든 기능을 사용하기보단, 분별력 있게 유용한 기능만 추출하여 설계의 유연성을 높히도록 하자.

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

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

도메인 모델은 일련의 개념을 모아놓은 것이다. 도메인 계층은 모델과 설계 요소에 직접적으로 관계돼 있는 모든 것들을 명시한 것이다.

도메인 로직이 다른 관심사와 섞여 있다면 모델의 개념을 반영할 수 없게 된다.
도메인 주도 설계의 전제 조건은 도메인 구현을 격리하는 것이다.