🏗 도메인 주도 설계(DDD) - 파트2 모델 주도 설계의 빌딩 블록

🚀 객체지향 설계에서 도메인 주도 설계로

📌 객체지향 커뮤니티에서 DDD 철학이 등장

• 객체 모델링을 실무 소프트웨어 프로젝트에 어떻게 적용할 것인지에 대한 논의
• 객체지향 프로그래밍과 DDD가 함께 발전

🕰 1990~2000년대: OOP와 DDD의 등장 배경

🔹 1) 객체 지향이 유행하기 시작한 이유?

• GUI(Graphical User Interface)의 등장
  • 객체지향은 UI와 잘 맞는 패러다임
  • 이벤트(메시지) → 특정 UI(객체) 변경
• 즉, OOP는 클라이언트 개발에 적합한 패러다임

🔹 2) CS(Computer Science) 분야의 변화

• 웹(Web) 개발의 대두
  • 이전까지는 로컬 컴퓨터 내에서 리소스를 사용
  • 웹이 등장하면서 네트워크, 분산 시스템 관련 기술이 필수 요소로 변화
• 분산 객체 기술의 유행
  • 네트워크를 통해 다른 시스템의 객체도 같은 메모리에 있는 것처럼 동작
  • 하지만 기술과 도메인이 혼재되는 문제 발생
  • 기술이 도메인을 침투(Pervasive)하는 구조
    • 서버가 꺼져 있으면 코드 실행이 불가능
    • 비즈니스 로직과 인프라 코드가 결합됨
    • 영속성 객체(Persistence Object) 구현 필요
    • 결론: 객체 단위로 분산할 필요 없이, 서비스 단위로만 분산하면 충분!
• Spring 등장과 POJO(Plain Old Java Object) 개념 확산
  • 기술 종속적인 코드 작성 방식에서 벗어나려는 시도
  • "도메인이 기술을 주도해야 한다"라는 철학이 등장
  • DDD(도메인 주도 설계)가 탄생 → 모델을 중심으로 코드 작성

🔹 3) 현재: 도메인 중심 개발이 당연한 시대

• 도메인 주도 설계 개념이 널리 받아들여짐
• 마이크로서비스, 클린 아키텍처 등과 결합되면서 더욱 발전

---

🏗 도메인 로직의 격리

💡 기술적인 요소를 도메인 로직에서 분리하고 싶다!

이를 해결하기 위한 대표적인 방법: 레이어 아키텍처
(하지만 DDD를 한다고 반드시 레이어 아키텍처를 써야 하는 것은 아님)

🔹 레이어 아키텍처 (Layered Architecture)

1️⃣ User Interface (UI)

• 사용자가 시스템과 상호작용하는 계층
  2️⃣ Application
• 비즈니스 로직을 실행하는 애플리케이션 서비스 계층
  3️⃣ Domain
• 핵심 비즈니스 로직이 포함된 계층 (DDD의 중심)
  4️⃣ Infrastructure
• 데이터베이스, 외부 API, 메시지 큐 등과 연결

✅ 이 구조를 통해 기술적인 요소와 도메인 로직을 분리할 수 있음!

---

🔨 모델 주도 설계의 빌딩 블록 (Building Blocks)

DDD는 코드 복잡성을 줄이기 위해 도메인을 특정 역할별로 분류합니다.
이를 위해 여러 가지 빌딩 블록을 정의할 수 있습니다.

🎯 1) 도메인을 표현하는 빌딩 블록

이들은 비즈니스 로직을 코드로 표현하는 핵심 요소입니다.

빌딩 블록설명

Association (연관 관계)	객체 간의 관계 표현
Value Object (값 객체)	불변이며 동일성보다 값이 중요한 객체
Entity (엔티티)	고유한 식별자를 가지는 객체
Service (서비스)	특정 엔티티에 속하지 않는 도메인 로직 처리
Module (모듈)	관련된 도메인 개념을 논리적으로 묶음

---

🎯 2) 생명주기를 관리하는 빌딩 블록

이들은 객체의 생성과 저장을 다루는 요소입니다.

빌딩 블록설명

Aggregate (애그리게이트)	불변식을 유지하기 위한 객체 그룹
Repository (리포지토리)	애그리게이트를 저장하고 조회하는 역할
Factory (팩토리)	복잡한 객체 생성을 처리하는 역할

✅ 이러한 빌딩 블록을 활용하면 코드의 응집도를 높이고 결합도를 낮출 수 있음!

---

📌 도메인 모델 예제 - 불변식(Invariant) 관리

도메인 로직을 설계할 때 **불변식(Invariant)**을 유지하는 것이 중요합니다.

💡 불변식이란?

• 시스템에서 반드시 유지되어야 하는 규칙
• 예제:
  • Order(주문)의 총 금액은 LimitPrice(최대 가격)보다 작아야 한다.

❌ 불변식을 깨뜨리는 문제 (동시성 이슈)

• User1이 Order 객체를 수정
• User2도 같은 Order 객체를 수정
• DB 업데이트 시 변경된 것만 저장한다면?
  • → 불변식 위반 가능성 발생

✅ 해결책: Aggregate(애그리게이트) 사용

• 불변식을 만족하는 객체 그룹 단위로 처리
• Aggregate 내부에서 변경, DB 업데이트 등 모든 작업을 트랜잭션 단위로 처리
• 즉, 도메인 룰(비즈니스 룰)에 따라 한꺼번에 업데이트

✅ 결과적으로, 애그리게이트는 데이터 정합성을 보장하는 역할을 수행

---

🔄 결과적 일관성 (Eventual Consistency)

• 예제: 주문 수(Order Count) 업데이트
  • 주문을 생성할 때, 주문 개수를 별도의 트랜잭션에서 관리하는 경우
  • 즉, 주문 개수 업데이트가 주문 생성 트랜잭션과 별도로 실행됨
• 모든 트랜잭션이 즉시 반영되지 않아도 괜찮음 → 결과적으로 일관성이 유지되면 됨
• 이런 방식은 마이크로서비스 아키텍처에서 많이 사용됨

---

🏆 마무리: DDD를 적용하면?

✅ 기술이 도메인을 지배하지 않고, 도메인이 기술을 주도하는 설계
✅ 비즈니스 로직을 코드와 동일하게 유지 (모델 = 코드)
✅ 레이어 아키텍처와 빌딩 블록을 활용하여 유지보수성을 높임
✅ 불변식을 지키며 데이터 정합성을 보장

DDD는 단순한 개발 방법론이 아니라 비즈니스 문제를 해결하는 철학입니다.
기술이 아닌 도메인 중심의 사고방식으로 접근하는 것이 핵심! 🚀