DDD - 에릭 에반스, (15장 디스틸레이션)

디스틸레이션(Distillation) 정의

• 디스틸레이션은 복잡한 도메인 모델에서 핵심적인 개념과 요소를 식별하고, 이를 정제하여 시스템의 중심으로 삼는 과정이다.
• 이는 중요한 도메인 개념을 명확히 하고, 불필요한 복잡성을 제거하는 데 중점을 둔다

---

핵심 도메인(Core Domain)

핵심 도메인(Core Domain) 선택

• 핵심 도메인 선택의 중요성:
  • 비즈니스 가치: 핵심 도메인은 비즈니스 가치를 극대화하는 데 중요한 역할을 한다. 올바른 선택은 비즈니스 성공에 큰 영향을 미친다.
  • 경쟁 우위: 핵심 도메인은 경쟁 우위를 제공하는 기능을 포함한다. 이를 통해 시장에서의 위치를 강화할 수 있다.
• 핵심 도메인 선택 기준:
  • 비즈니스 전략적 중요성: 해당 도메인이 비즈니스 전략에서 얼마나 중요한지를 평가한다. 전략적 중요성이 높은 도메인을 핵심 도메인으로 선택한다.
  • 고객 가치: 고객에게 직접적인 가치를 제공하는 도메인을 식별한다. 고객 만족도와 충성도를 높이는 기능이 포함된 도메인이 핵심 도메인이다.
• 경쟁력: 시장에서 경쟁 우위를 제공하는 도메인을 선택한다. 다른 경쟁사와 차별화되는 기능이 포함된 도메인을 고려한다.
• 수익 기여도: 비즈니스 수익에 큰 기여를 하는 도메인을 선택한다. 수익 창출과 직접적으로 연결된 도메인이 핵심 도메인이 될 가능성이 크다

누가 핵심 도메인 선택을 할 것인가?

• 역할과 책임:
  • 도메인 전문가(Domain Experts): 도메인 지식과 비즈니스 프로세스를 깊이 이해하고 있는 도메인 전문가가 핵심 도메인 선택 과정에 참여한다.
  • 제품 관리자(Product Managers): 제품 관리자는 시장 요구와 고객의 니즈를 잘 이해하고 있기 때문에 비즈니스 목표와 고객 가치에 기반하여 핵심 도메인을 식별하는 데 중요한 역할을 한다.
  • 아키텍트(Architects): 시스템 아키텍트는 기술적인 관점에서 도메인의 중요성을 평가하기 때문에 도메인의 기술적 복잡성과 구현 가능성을 고려하여 핵심 도메인을 선택하는 역할을 한다
  • 경영진(Executives): 비즈니스 전략을 결정하는 경영진은 최종적으로 핵심 도메인을 선택하는 데 중요한 역할을 한다. 이들은 전체적인 비즈니스 목표와 일치하는 핵심 도메인을 최종 승인한다.

디스틸레이션의 단계적 확대

• 단계적 확대의 중요성:
  • 점진적 도입: 모든 도메인을 한 번에 정제하는 것은 현실적으로 어렵다. 단계적으로 접근하여 각 단계에서 얻은 교훈을 다음 단계에 반영할 수 있다.
  • 위험 관리: 단계적으로 접근함으로써 리스크를 관리하고, 변경의 영향을 최소화할 수 있다.
• 단계적 확대 과정:
  • 초기 식별 및 분석: 도메인 모델의 초기 분석을 통해 주요 도메인 개념과 관계를 식별한다.
  • 핵심 도메인 정제: 불필요한 요소를 제거하고, 중요한 개념을 명확히 하면서 도메인 전문가와 긴밀히 협력한다.
  • 보조 및 일반 서브도메인 식별: 핵심 도메인을 지원하는 보조 서브도메인과 여러 도메인에서 공통으로 사용할 수 있는 일반 서브도메인을 식별한다.
  • 우선순위 설정: 각 도메인과 서브도메인의 우선순위를 설정한다. 비즈니스 가치와 전략적 중요성을 기준으로 우선순위를 결정한다.
  • 단계적 구현: 우선순위가 높은 도메인부터 단계적으로 구현을 시작한다. 각 단계에서 도메인 모델을 구현하고, 이를 통해 얻은 교훈을 다음 단계에 반영한다.
  • 지속적 평가 및 개선: 각 단계가 완료될 때마다 도메인 모델을 평가하고, 필요한 개선을 수행한다. 이를 통해 도메인 모델의 일관성과 무결성을 유지한다.

예제: 온라인 쇼핑몰의 디스틸레이션

• 단계 1: 초기 식별 및 분석:
  • 주문 처리(Order Processing), 고객 관리(Customer Management), 재고 관리(Inventory Management) 등을 식별한다.
• 단계 2: 핵심 도메인 정제:
  • 주문 처리(Order Processing)를 핵심 도메인으로 식별한다.
  • 이는 비즈니스의 전략적 목표와 직접적으로 연관되며, 고객 가치 창출의 핵심 요소이다.
• 단계 3: 보조 및 일반 서브도메인 식별:
  • 고객 관리(Customer Management)를 보조 서브도메인으로, 결제 처리(Payment Processing)를 일반 서브도메인으로 식별한다.
• 단계 4: 우선순위 설정:
  • 문 처리(Order Processing)를 최우선으로, 그 다음으로 고객 관리(Customer Management)와 결제 처리(Payment Processing)를 설정한다.
• 단계 5: 단계적 구현:
  • 먼저 주문 처리 시스템을 구현하고, 이를 통해 얻은 교훈을 기반으로 고객 관리와 결제 처리 시스템을 구현한다.
• 단계 6: 지속적 평가 및 개선:
  • 각 도메인 구현 후 평가를 통해 개선점을 도출하고, 이를 다음 단계에 반영하여 지속적으로 도메인 모델을 개선한다.

---

일반 하위 도메인(Generic Subdomain)

일반 하위 도메인(Generic Subdomain)

• 일반 하위 도메인(Generic Subdomain)은 특정 비즈니스에 특화되지 않은, 여러 도메인에서 공통적으로 사용될 수 있는 기능이나 서비스를 제공하는 도메인을 의미한다.
• 보통 핵심 도메인(Core Domain)이나 보조 서브도메인(Supporting Subdomain)을 지원하는 역할을 한다.
• 특징:
  • 범용적 기능: 여러 비즈니스 도메인에서 공통적으로 필요로 하는 기능을 제공
  • 재사용성: 다양한 도메인에서 재사용될 수 있도록 설계됨
  • 핵심이 아님: 특정 비즈니스의 경쟁 우위를 결정하는 핵심 기능이 아니며, 비즈니스의 차별화 요소와는 거리가 있다.
• 예제:
  • 인증 및 권한 관리(Authentication and Authorization): 여러 애플리케이션에서 공통으로 사용하는 사용자 인증 및 권한 부여 기능.
  • 결제 처리(Payment Processing): 다양한 전자 상거래 시스템에서 사용하는 결제 처리 기능.
  • 알림 시스템(Notification System): 다양한 시스템에서 사용하는 이메일, SMS, 푸시 알림 등의 알림 기능.

일반화가 재사용 가능하다는 의미는 아니다

• **일반화(Generalization)**란 여러 도메인에서 공통된 개념을 추출하여 하나의 공통된 모델이나 서비스로 만드는 것을 의미한다.
• 그러나 일반화된 모델이나 서비스가 항상 재사용 가능하다는 의미는 아니다.
• 이유:
  • 구체적 요구사항: 각 도메인은 고유한 비즈니스 요구사항과 제약 조건을 가지고 있기 때문에, 일반화된 모델이 이러한 고유한 요구사항을 모두 충족시키기 어렵다.
  • 복잡성 증가: 일반화된 모델은 모든 가능성을 포괄하려다 보니 복잡해질 수 있기 때문에, 구현과 유지보수가 어려워질 수 있다.
  • 유연성 제한: 일반화된 모델은 특정 사용 사례에 최적화되어 있지 않기 때문에, 특정 도메인에서는 유연성이 제한될 수 있다.

프로젝트 위험 관리

• 프로젝트 위험 관리란 프로젝트가 목표를 달성하는 데 방해가 될 수 있는 위험 요소를 식별, 분석, 대응하는 과정을 의미한다.
• 단계:
  • 위험 식별: 프로젝트에서 발생할 수 있는 모든 잠재적 위험을 식별한다. 이는 기술적 문제, 일정 지연, 인력 부족, 요구사항 변경 등을 포함할 수 있다.
    • 도구: 브레인스토밍, 체크리스트, 인터뷰, 과거 프로젝트 분석 등.
  • 위험 분석: 식별된 위험의 영향을 평가하고, 각 위험의 발생 가능성과 그로 인한 영향을 분석한다.
    • 정성적 분석: 위험의 심각성, 발생 가능성을 주관적으로 평가.
    • 정량적 분석: 수치화된 데이터를 사용해 위험의 영향을 계량적으로 평가.
  • 위험 대응 계획: 각 위험에 대한 대응 전략을 수립한다. 대응 전략에는 회피, 전가, 경감, 수용이 포함된다.
    • 회피: 위험 발생 가능성을 완전히 제거.
    • 전가: 위험의 영향을 제3자에게 이전(예: 보험, 아웃소싱).
    • 경감: 위험 발생 가능성이나 영향을 줄이는 조치.
    • 수용: 위험을 받아들이고, 발생 시 대응 계획을 준비.
  • 위험 모니터링 및 통제: 프로젝트 진행 중에 위험 요소를 지속적으로 모니터링하고, 새로운 위험이 발생하면 이를 관리한다.
• 예제:
  • 기술적 위험: 새로운 기술을 도입하는 경우, 기술적 문제로 인해 프로젝트가 지연될 위험이 있다.
    • 대응 전략: 초기 단계에서 파일럿 프로젝트를 실행하여 기술적 문제를 사전에 발견하고 해결.
  • 일정 지연 위험: 프로젝트 일정이 촉박하여 지연될 위험이 있다.
    • 대응 전략: 중요한 마일스톤을 설정하고, 주기적으로 진척 상황을 검토하여 일정 지연을 조기 발견.

---

도메인 비전 선언문

도메인 비전 선언문의 목적

• 목표 명확화: 도메인의 목표를 명확하게 정의하여, 모든 이해관계자들이 이를 공통적으로 이해할 수 있도록 한다.
• 일관된 방향 제공: 도메인 모델링 및 개발 과정에서 일관된 방향을 제시하여, 팀이 동일한 목표를 향해 나아갈 수 있도록 한다.
• 의사소통 촉진: 도메인 전문가, 개발자, 경영진 등 다양한 이해관계자 간의 의사소통을 촉진한다. 선언문을 통해 도메인의 비전과 가치를 공유한다.
• 우선순위 설정: 도메인 비전 선언문은 개발 과정에서 무엇이 중요한지를 명확히 하여, 우선순위를 설정하는 데 도움을 준다.

도메인 비전 선언문의 구성 요소

• 도메인의 목표: 도메인이 해결하려는 문제나 달성하려는 목표를 명확하게 정의한다.
• 도메인의 가치: 도메인이 제공하는 주요 가치나 이점을 설명한다. 이는 고객, 사용자, 비즈니스에 대한 가치를 포함할 수 있다.
• 도메인의 범위: 도메인의 범위를 정의하여, 어떤 부분을 다루고, 어떤 부분을 다루지 않을지를 명확히 한다.

예제 1: 온라인 쇼핑몰의 주문 처리 도메인

• 도메인 비전 선언문:
  • "우리의 주문 처리 도메인은 고객이 쉽고 빠르게 주문할 수 있도록 하여, 고객 만족도를 높이고, 매출을 극대화하는 것을 목표로 합니다. 우리는 정확하고 신속한 주문 처리, 실시간 재고 업데이트, 다양한 결제 옵션을 통해 고객에게 최고의 쇼핑 경험을 제공합니다.”
• 구성 요소:
  • 목표: 고객 만족도 향상 및 매출 극대화.
  • 가치: 정확하고 신속한 주문 처리, 실시간 재고 업데이트, 다양한 결제 옵션.
  • 범위: 주문 생성, 주문 상태 관리, 재고 업데이트, 결제 처리.

예제 2: 금융 서비스의 대출 관리 도메인

• 도메인 비전 선언문:
  • "우리의 대출 관리 도메인은 고객이 적시에 대출을 받을 수 있도록 하여, 고객의 금융 요구를 충족시키고, 회사의 대출 포트폴리오를 효율적으로 관리하는 것을 목표로 합니다. 우리는 빠르고 투명한 대출 승인 절차, 맞춤형 대출 상품, 리스크 관리 기능을 통해 최고의 금융 서비스를 제공합니다.”
• 구성 요소:
  • 목표: 고객의 금융 요구 충족 및 대출 포트폴리오 효율적 관리.
  • 가치: 빠르고 투명한 대출 승인 절차, 맞춤형 대출 상품, 리스크 관리 기능.
  • 범위: 대출 신청, 승인 절차, 대출 상품 관리, 리스크 평가.

---

응집력 있는 메커니즘 (Cohesive Mechanism)

응집력 있는 메커니즘 (Cohesive Mechanism)

• 응집력 있는 메커니즘은 관련된 기능과 데이터를 한 곳에 모아둔 구성 요소
• 이는 관련된 기능들이 서로 밀접하게 연관되어 있어, 응집도가 높은 것을 의미한다.
• 목적:
  • 응집도 높은 구성 요소를 통해 기능과 데이터 간의 관계를 명확히 하고, 유지보수성을 향상
  • 관련 기능을 한 곳에 모아두어, 변경이 발생할 때 영향을 최소화하고, 코드의 가독성을 높임
• 특징:
  • 기능 그룹화: 관련된 기능들을 하나의 모듈이나 클래스에 그룹화하여 응집도를 높일 수 있다
  • 단일 책임 원칙: 각 메커니즘은 단일 책임 원칙(Single Responsibility Principle)을 준수하여, 하나의 주요 기능만을 담당한다.
  • 재사용성: 응집력 있는 메커니즘은 재사용 가능성이 높다.
• 예제:
  • 결제 처리 메커니즘: 결제 승인, 결제 완료, 결제 취소 등의 관련 기능들을 하나의 결제 서비스로 그룹화

public class PaymentService {
    public PaymentResponse authorizePayment(PaymentRequest request) {
        // 결제 승인 로직
    }

    public PaymentResponse capturePayment(String transactionId) {
        // 결제 완료 로직
    }

    public void cancelPayment(String transactionId) {
        // 결제 취소 로직
    }
}

---

분리된 핵심 (Separated Core)

분리된 핵심 (Separated Core)

• 시스템의 핵심 비즈니스 로직을 지원 도메인이나 인프라스트럭처 코드로부터 분리하는 패턴
• 핵심 도메인을 다른 코드와 독립적으로 유지함으로써, 핵심 비즈니스 로직의 가독성과 유지보수성을 높일 수 있다
• 특징:
  • 독립성: 핵심 비즈니스 로직이 다른 코드로부터 독립적으로 유지된다
  • 유지보수성: 핵심 로직이 명확히 분리되어 있어, 유지보수가 용이하다
  • 명확한 경계: 핵심 도메인과 지원 도메인 간의 경계를 명확히 정의한다
• 예제: 주문 처리 핵심 로직:
  • 주문 생성, 주문 취소 등의 핵심 비즈니스 로직을 지원 코드(예: 데이터베이스 접근 코드)로부터 분리.
  •  

// 핵심 도메인
public class OrderService {
    public Order createOrder(Customer customer, List<OrderItem> items) {
        // 주문 생성 로직
    }

    public void cancelOrder(Order order) {
        // 주문 취소 로직
    }
}

// 지원 도메인
public class OrderRepository {
    public void save(Order order) {
        // 데이터베이스 저장 로직
    }

    public Order findById(String orderId) {
        // 데이터베이스 조회 로직
    }
}

---

추상화된 핵심 (Abstracted Core)

추상화된 핵심 (Abstracted Core)

• 도메인의 복잡성을 줄이고, 핵심 비즈니스 로직을 더 이해하기 쉽게 만들기 위해 추상화하는 패턴
• 구체적인 구현 세부 사항을 감추고, 도메인 모델의 본질적인 부분에 집중하게 한다
• 특징:
  • 추상화: 구체적인 구현 세부 사항을 감추고, 본질적인 개념에 집중한다
  • 명확한 인터페이스: 핵심 비즈니스 로직을 나타내는 명확한 인터페이스를 정의한다
  • 유연성: 추상화된 인터페이스를 통해 다양한 구현을 지원할 수 있어, 시스템의 유연성이 높아진다
• 예제: 결제 서비스 인터페이스:
  • 결제 처리의 구체적인 구현을 추상화하여 인터페이스로 정의

// 추상화된 핵심
public interface PaymentService {
    PaymentResponse authorizePayment(PaymentRequest request);
    PaymentResponse capturePayment(String transactionId);
}

// 구체적인 구현
public class StripePaymentService implements PaymentService {
    @Override
    public PaymentResponse authorizePayment(PaymentRequest request) {
        // Stripe 결제 승인 로직
    }

    @Override
    public PaymentResponse capturePayment(String transactionId) {
        // Stripe 결제 완료 로직
    }
}

public class PaypalPaymentService implements PaymentService {
    @Override
    public PaymentResponse authorizePayment(PaymentRequest request) {
        // PayPal 결제 승인 로직
    }

    @Override
    public PaymentResponse capturePayment(String transactionId) {
        // PayPal 결제 완료 로직
    }
}