도메인 주도 설계 개념 및 라이프 사이클

1. 도메인 주도 설계(Domain-Driven Design) 개념

• 도메인 주도 설계(Domain-Driven Design, DDD)는 복잡한 도메인 문제를 해결하기 위한 소프트웨어 설계 방법론입니다. DDD는 소프트웨어를 도메인(domain)과 함께 설계하며, 도메인의 비즈니스 규칙과 개념에 초점을 둡니다. 이를 통해 도메인 전문가와 개발자가 협력하여 도메인 문제를 해결하는데 초점을 맞춥니다.
• DDD의 핵심 개념 중 하나는 도메인 모델링입니다. 도메인 모델링은 도메인의 개념, 규칙, 동작, 관계 등을 나타내는 모델을 만드는 과정입니다. 이 모델은 코드에 반영되어 도메인 전문가와 개발자가 도메인 문제를 해결하는데 사용됩니다.
• DDD는 또한 소프트웨어의 구성요소를 도메인 주도 설계에 기반하여 구성하는 것을 권장합니다. 이를 위해 도메인 모델을 기반으로 소프트웨어의 각 계층을 설계하고, 각 계층 간의 상호작용을 명확히 정의합니다. 이렇게 함으로써 도메인 전문가와 개발자가 더욱 쉽게 협력할 수 있고, 유지보수가 쉬운 소프트웨어를 만들 수 있습니다.
•  

2. 도메인 주도 설계 사이클 및 OOP와의 차이점

2.1 주문 관리 시스템 설계하기(by DDD)

• 예를 들어, 주문 관리 시스템 구축 프로젝트에 참여한다고 가정해보겠습니다. 이 시스템은 고객이 제품을 주문하고, 주문 상태를 추적하며, 결제를 처리하는 등의 기능을 제공합니다. 이러한 요구사항을 바탕으로 아래와 같은 DDD 라이프사이클을 적용하여 시스템을 설계할 수 있습니다.

비즈니스 도메인 이해	주문 시스템의 경우, 상품 주문, 결제, 배송 등의 비즈니스 도메인이 있습니다. 이를 충분히 이해하고, 도메인 전문가와 협력하여 비즈니스 로직을 파악합니다.
애그리게이트 식별	주문 시스템에서는 상품, 주문, 결제, 배송 등의 애그리게이트가 있습니다. 이 중에서 가장 핵심적인 주문 애그리게이트를 식별합니다.
애그리게이트 루트 설계	주문 애그리게이트에서 가장 핵심적인 역할을 담당하는 주문 애그리게이트 루트를 설계합니다. 주문 애그리게이트 루트는 주문에 대한 정보와 주문에 따른 결제, 배송 정보를 포함합니다.
애그리게이트 구성요소 식별	주문 애그리게이트 내에서 구성 요소로 사용될 엔티티, 값 객체, 도메인 서비스를 식별합니다. 예를 들어, 주문 애그리게이트에서는 주문 항목, 상품, 할인 등의 엔티티와, 배송지, 결제 수단 등의 값 객체를 사용할 수 있습니다.
엔티티와 값 객체 설계	각 엔티티와 값 객체를 설계합니다. 엔티티는 고유한 식별자와 상태를 가지며, 값 객체는 불변성을 유지하며 다른 객체와 함께 조합됩니다.
도메인 서비스 설계	주문 애그리게이트 내부에서 해결할 수 없는 로직이 있다면, 도메인 서비스를 활용합니다. 예를 들어, 배송지 변경이라는 기능은 도메인 서비스로 구현할 수 있습니다.
애그리게이트 라이프사이클 관리	애그리게이트 라이프사이클을 관리하기 위해 애그리게이트를 생성하고, 소멸시키는 라이프사이클 매니저를 설계합니다.
응용 서비스 설계	마지막으로, 응용 서비스를 설계합니다. 응용 서비스는 사용자 인터페이스, 외부 시스템과의 연동 등, 도메인 모델 외부의 로직을 처리합니다. 이를 통해 도메인 모델을 완전히 분리하고, 높은 응집도와 낮은 결합도를 유지합니다.

2.2 DDD와 OOP의 차이

• 위에서 제시한 주문 관리 시스템이 DDD 기반이 아니라면, 일반적으로 객체 지향 프로그래밍(OOP)을 기반으로 설계될 것입니다. 이 경우, 각 객체를 단순히 데이터의 컨테이너로 간주하고, 이들 객체간의 상호작용을 적절하게 조합하여 시스템을 구성하게 되므로, 발생할 수 있는 문제점은 아래와 같습니다.
  1. 비즈니스 로직과 데이터가 혼재된 클래스 OOP에서는 데이터와 동작을 함께 포함하는 객체를 생성합니다. 이로 인해 데이터와 동작이 섞이게 되면서, 주문 시스템에서는 주문 데이터와 주문 처리 로직이 하나의 클래스에 혼재될 수 있습니다. 예를 들어, 주문 데이터를 저장하는 Order 클래스가 주문을 처리하는 메서드를 가지고 있는 경우, 클래스의 책임이 모호해지고 유지보수성이 떨어집니다.
  2. 복잡한 상태 관리 OOP에서는 객체의 상태를 중요시합니다. 주문 시스템에서는 주문 데이터와 주문 상태, 결제 상태, 배송 상태 등의 상태를 관리해야 합니다. 이로 인해 상태 관리가 복잡해지고, 여러 클래스 간의 상태 공유 문제가 발생할 수 있습니다.
  3. 도메인 모델의 미비 OOP에서는 객체간의 상호작용을 중심으로 프로그램을 설계합니다. 이에 반해 DDD는 도메인 모델을 중심으로 프로그램을 설계합니다. 주문 시스템에서는 주문 데이터, 결제 데이터, 배송 데이터 등의 다양한 도메인 모델이 필요합니다. 이러한 도메인 모델링에 대한 지식과 경험이 부족한 경우, 비즈니스 요구사항을 충족시키는 도메인 모델을 만들어 내기 어려울 수 있습니다.