에릭 에반스의 ‘도메인 주도 설계’ 책과 조영호의 ‘도메인 주도 설계의 사실과 오해’ 강의를 기반으로 이해한 내용을 작성해보려고 합니다.
빌딩 블록과 바운디드 컨텍스트에 대해 알아봅시다.

도메인 주도 설계 2편

빌딩블록

도메인 주도 설계 DDD에서 구현 가능한 도메인 모델을 구성하는 목록으로 “빌딩 블록”을 사용합니다. 빌딩 블록은 도메인 모델을 효율적으로 구축하기 위해 필요한 구성 요소들을 의미합니다.

도메인 주도 설계의 구성 요소

도메인 모델을 빌드하는 데 필요한 요소들은 다음과 같습니다:

1. 도메인을 표현하기 위한 빌딩 블록
   • ASSOCIATION(연관관계), MODULE, ENTITY, VALUE OBJECT, SERVICE 등이 포함됩니다.
2. 생명주기를 관리하기 위한 빌딩 블록
   • AGGREGATE, REPOSITORY, FACTORY가 포함됩니다.

이렇게 나눈 이유는 구현에 대한 가이드를 제공하여 복잡도를 낮추기 위함입니다. 개발자는 이러한 빌딩 블록을 통해 복잡한 도메인 모델을 체계적으로 구성하고 관리할 수 있습니다.

불변성(불변식)과 AGGREGATE

도메인 모델에는 불변성 또는 불변식이라는 중요한 요소가 있습니다. 불변식은 비즈니스 규칙이나 로직이 반드시 만족해야 하는 조건을 의미합니다. 예를 들어, “주문 금액의 총액은 주문의 리밋금액보다 낮아야 한다”는 불변식입니다. 이러한 불변식은 어떠한 상황에서도 깨져서는 안 됩니다.

집합체(AGGREGATE)는 특정 엔티티에 의해 연관된 다른 엔티티나 값 객체의 규칙을 보장하는 역할을 합니다.
집합체(AGGREGATE)는 도메인의 일관성 유지에 중요한 역할을 수행합니다.
이 범위를 지정함으로써 불변식을 보호하고, 도메인 로직의 복잡성을 효율적으로 관리할 수 있게 됩니다.
따라서 애그리게이트를 저장의 단위, 수정의 단위, 트랜잭션의 단위로 생각하면 편합니다.

Aggregate단위로 repository를 추가하고, 객체간의 복잡성을 낮추기 위해 id를 이용해 참조하고 관리합니다.
이렇게 도메인 모델을 관리하면 결과의 일관성을 보장할 수 있게 됩니다.

왜 DDD를 추천하는 것일까? 왜 단일 도메인 모델은 문제가 있다고 하는 것일까?
실무를 하다보면 늘어가는 요구사항에 맞추어 지식을 탐구하고 기능을 추가 하게 될텐데요.
이때 코드 수정이 일어나게 된다면 충돌이 발생할 가능성이 높고, 통제하기 어려운 사이드 이펙트가 발생하게 됩니다.
이를 협업 오버헤드가 증가했다고 말하며, 릴리즈 일정을 다시 조정하게되는 문제가 발생합니다.
이렇게 하나의 커다란 도메인 모델은 비현실적입니다.
그래서 나온 해결방안으로 사용되는 컨텍스트에 따라 모델을 분리하자! 이것이 바로 바운디드 컨텍스트 입니다.

바운디드 컨텍스트

바운디드 컨텍스트란?

특정 도메인 모델의 범위 및 적용 영역을 말합니다.
이는 사용되는 언어, 규칙, 용어 및 모델의 논리적 경계를 결정하며, 동일한 바운디드 컨텍스트 내에서는 도메인 모델의 일관성과 통합성을 유지하는 것이 중요합니다. 서로 다른 바운디드 컨텍스트 사이에서는 통합성에 신경 쓰지 않는다는 것입니다.

바운디드 컨텍스트의 가장 중요한 특징중 하나는, 같은 이름의 모델이라 할지라도 서로 다른 바운디드 컨텍스트 안에서는 다른 의미를 가질 수 있다는 것입니다.
하나의 바운디드 컨텍스트는 각각의 도메인 모델에 대해 완전히 다른 해석을 허용하므로, 이런 방식으로 복잡성을 관리할 수 있습니다. 쉽게 말하자면 바운디드 컨텍스트는 하나의 거대한 모듈을 팀 단위로 할당해서 가져간 것이라고 볼 수 있습니다.

바운디드 컨텍스트는 마이크로서비스 아키텍처(MSA)

바운디드 컨텍스트는 마이크로서비스 아키텍처(MSA)와 유사점이 있습니다. 마이크로서비스 아키텍처는 서비스마다 독립적인 배포가 가능한 반면, 모놀리식 구조에서는 모든 서비스가 함께 배포되어야 합니다. 따라서 바운디드 컨텍스트는 작은 팀 또는 독립적인 서비스 단위로 관리될 수 있는 아키텍처적 구조를 제공합니다.

바운디드 컨텍스트는 프레젠테이션 계층부터 영속성 계층까지 수직적으로 통합된 서비스 계층을 포함합니다. 이는 도메인 모델을 완전히 포괄하는 독립적인 애플리케이션 단위를 형성합니다. 컨텍스트 맵(Context Map)은 여러 바운디드 컨텍스트들간의 상호관계를 정의하며, 일반적으로 컨텍스트 사이의 모델 변환 방식도 정의합니다. 예를들어 주문 컨텍스트 -> 변환 -> 판매 컨텍스트 (컨텍스트 사이의 관계와 모델 변환 방식을 정의한 곳)

마지막으로, 바운디드 컨텍스트는 조직 구조와 소프트웨어 설계를 연결하는 지점에서 중요한 역할을 합니다. 팀이 하나의 바운디드 컨텍스트를 담당함으로써, 서비스의 언어, 도메인 모델, 문화를 관리하고, 서비스의 독립성 및 유연성을 확보할 수 있습니다. 따라서 이는 조직 획일성을 지원하는 다른 아키텍처 패턴들과 달리, 조직의 다양성을 보장하는 아키텍처 패턴입니다.