[DDD] 도메인 주도 설계의 계층 분리에 관하여

들어가며

 MSA와 함께 사용되는 도메인 주도 설계 방식에 대해서 정리하려고 한다. 도메인 주도 설계에 대해 이희창 님의 강의에서 처음 접하게 되었다. MSA의 서비스 분리 콘셉트와, 도메인 주도 설계에서 모델을 중심으로 분리하는 콘셉트가 유지보수나 추후 기능 개선 등 궁합이 잘 맞아떨어지는 것 같다는 정도로 생각하고 있었다. 하지만 시간이 지남에 따라 이 설계기법은 MSA와는 독립적으로 질 좋은 코드를 개발하기 위한 노하우의 결정체라는 것을 느낄 수 있었다. 이번 글에서는 에릭 에반스의 도메인주도 설계(72p)의  업무용 소프트웨어 계층에 대해서 살펴보도록 한다.

---

도메인 주도 설계의 계층 분리

도메인주도 설계 Layerd Architecture

복잡한 프로그램을 여러 개의 계층으로 나눠라. 응집력 있고 오직 아래에 위치한 계층에만 의존하는 각 계층에서 설계를 발전시켜라. 표준 아키텍처 패턴에 따라 상위 계층과의 결합을 느슨하게 유지하라. 도메인 모델과 관련된 코드는 모두 한 계층에 모으고 사용자 인터페이스 코드나 애플리케이션 코드, 인프라스트럭처 코드와 격리하라. 도메인 객체는 도메인 모델을 표현하는 것에만 집중할 수 있다. 이로써 모델은 진화를 거듭해 본질적인 업무 지식을 포착해서 해당 업무 지식이 효과를 발휘할 수 있을 만큼 풍부하고 명확해질 것이다.

- 도메인주도 설계, 에릭 에반스 

 도메인주도 설계의 Layerd Architecture와 일반적인 Layerd Architecture의 차이가 있다. 일반적인 Layerd Architecutre는 상위 레이어에서 하위 레이어로 단방향 의존을 한다. (예시: 인터페이스 계층에서는 응용 계층에서 제공하는 인터페이스들을 기반으로 구현)

Layered Architecture 규칙

• 상위 계층이 하위 계층을 호출하는 단방향성을 유지한다.
• 상위 계층은 하위의 여러 계층을 모두 알 필요없이 바로 밑의 근접 계층만 활용한다.
• 상위 계층이 하위 계층에 영향을 받지 않게 구성해야 한다. (중간 계층을 기준으로)
• 하위 계층은 자신을 사용하는 상위 계층을 알지 못하게 구성해야 한다.
• 계층 간의 호출은 인터페이스를 이용한다. (구현 클래스에 직접 의존하지 않음으로써 약한 결합을 유지해야 한다.)

 도메인 계층의 입장에서 이런 식으로 구현을 하게 되면 인프라 스트럭처 계층의 변화에 따라서 도메인 계층의 구현이 영향을 받게 된다. 그래서 DIP(의존성 역전)를 이용하여 도메인 계층에서 정의한 인터페이스를 인프라스트럭처에서 구현 하는 식으로 설계한다. 

 도메인 계층에 비즈니스에 대한 해석을 보관하여 엑기스로 만들어 놓고, 나머지 3개의 계층에서 사용하는 방식이다. 이렇게 구조를 가져가게 되면 도메인 모델의 구현체에 최소한의 영향을 주면서 확장이나 개선이 가능해진다. 또한 비즈니스 로직이 아닌 프로그램 구동에 필요한 군더더기 소스코드들이 인프라스트럭처 계층으로 빠지기 때문에, 도메인 모델이 표현된 코드의 가독성을 높일 수 있다는 장점이 있다.  

DIP 예시 (이희창님 강의자료에서 참고)

---

참고자료

[1] 패스트캠퍼스 MSA 강의자료 | 2021 | 이희창 

[2] 도메인주도 설계 | 2016 | 에릭 에반스 | 링크

도메인 주도 설계 - 교보문고

[3] 도메인주도 설계로 시작하는 마이크로서비스 개발 | 2021 | 한정헌, 유해식, 최은정, 이주영 | 링크

도메인 주도 설계로 시작하는 마이크로서비스 개발 - 교보문고