들어가기 전에

• 경우에 따라 DDD 기술 규칙과 패턴이 DDD 구현에 방해가 될 수 있음 → 중요한 것은 패턴이 아니라 비지니스 문제에 맞게 코드를 구성하고 동일한 비지니스 용어를 사용하는 것

기존 개발

• 기획서를 받으면 DB 스키마를 먼저 고민 → RDBS의 정규화에 대해서 고민
• 그리고 스키마가 정해지면 똑같은 클래스를 만들고 거기에 맞춰서 비지니스 로직을 구현
• DB 스키마는 개발자의 전유물이지만 기획자, 운영 업무자는 DB 스키마와는 동떨어진 업무를 진행 → 개발자는 DB 중심으로 생각하고 운영자는 기능 중심으로 생각
• 이런 불일치는 커뮤니케이션 비용을 낭비 혹은 잘못된 소프트웨어를 만드는 원인

도메인 주도 설계

• 위와 같은 불일치를 해결하기 위해서 나온 노력 중 하나가 DDD
• 감히 한 문장으로 설명하자면 도메인 모델의 적용 범위를 구현까지 확장하여 도메인 지식을 구현 코드에 반영하는 것
• 설계를 완벽하게 하고 구현을 하라는 것이 아님 → 설계와 구현을 반복적으로 해야함 → 약간 애자일스럽게...
• 도메인에 대해서 100% 이해하기 위해서 문서로는 부족 → 실제 몸으로 겪어봐야 하는데 이게 코드를 구현하는 일
• 그래서 이런 것들을 도와주기 위해서 다양한 원칙과 패턴이 존재
• 도메인 주도 설계를 이해하기 위해서 세가지 기둥이 있는데 아래와 같음
  • 전략적 설계
    • 도메인을 거시적 관점으로 보는 개념 → 나무가 아닌 숲을...
    • Bounded Context를 추출하는 개념이라고 생각
    • Event Storming
      • 전략적 설계를 위해서 사용되는 방법론으로, 비즈니스 규칙, 시스템내의 프로세스에 대한 Big picture를 구성하기에 좋은 방법론
      • Event Storming 과정을 거치고 나면 요구사항으로부터, Bounded Context와 주요 Aggregate 단위들, Domain Event들, 구현의 단위들을 추출
  • 전술적 설계
    • 전략적 설계를 도와줄 실제 구현 패턴을 의미
    • Bounded Context를 aggregate, entity, service, repository등의 요소들을 활용하여 구성하는 것이 목적
    • 전술적 설계를 모아두는 것을 DDD Lite라고 함
      • DDD Lite는 어찌보면 부정적인 의미
      • 전술적 설계만을 가지고 DDD를 하게되면 전략적 설계 즉 거시적인 관점을 놓치게 됨
  • 유비쿼터스 언어

도메인

• 내가 만들고 있는 서비스 혹은 소프트웨어가 영향력을 미치는 곳 → 즉 소프트웨어가 어떠한 문제를 해결하고자 하는 영역
• 쇼핑몰을 운영하고 있음 → E-Commerce가 나의 도메인 영역이 됨