DDD & 멀티모듈 세션 개념 정리하기

1. Domain Driven Design (DDD)

DDD는 소프트웨어 개발 방법론 중 하나, 도메인 주도 설계

해결하고자 하는 문제 영역인 도메인을 중심으로 설계를 진행한다 !

소프트웨어 개발 시 도메인(문제 영역)에 대한 깊은 이해를 바탕으로 설계와 구현을 진행하는 접근 방식이다.

 

 

 

도메인과 모델

• 도메인: 지식 활동의 영역이자 소프트웨어로 해결하고자 하는 문제 영역. 프로그래머에게는 애플리케이션 내 로직들이 관여하는 정보와 활동의 영역. (예: 온라인 쇼핑, 회원 도메인 영역).
• 도메인 모델: 특정 도메인을 개념적으로 표현한 것. 소프트웨어 기능과 데이터 구조를 비즈니스 운영과 일치시키기 위해 사용됨. (표현 방식: 객체, 다이어그램, 공식 등).

 

 

---

 

 

DDD의 주요 요소 - 전략적 설계 vs. 전술적 설계

구분	전략적 설계 (Strategic Design)	전술적 설계 (Tactical Design)
목표	복잡한 도메인의 경계를 상황에 맞게 명확히 정의함. 문제 도메인을 해결 영역으로 가져옴.	식별된 내부를 상세하게 설계함. 풍부한 도메인 모델을 적용함.
주요 패턴	Bounded Context, Ubiquitous Language, Context Map.	Aggregate, Domain-Event, Entity, Value Object, Repository 등.

• 유비쿼터스 언어: 개발자도 도메인 전문가도 아는 보편적 공통 언어. 비즈니스 용어를 하나로 통일하여 의사소통 문제를 해결함. Bounded Context 범위 내에서 정의됨.

 

🔑 도메인 모델 패턴 (전술적 설계)

• Entity: 고유 식별자를 가지며, 자신의 상태와 라이프 사이클을 가짐. (예: 주문, 회원, 상품).
• Value Object: 고유 식별자가 없는 불변 객체. 식별성이 아닌 속성을 이용해 정의되며, 불변성을 위해 setter 구현을 지양함. (예: 주소, 금액).
• Aggregate: 연관된 Entity와 Value Object를 하나로 묶은 군집. 일관성을 보장하며 트랜잭션과 분산 처리의 단위가 됨.
  • Aggregate Root: 애그리거트의 대표로, 종속 객체들(엔티티)과 동일한 라이프사이클(하나의 트랜잭션)을 가짐.
• Repository: 도메인 영역과 데이터 인프라 계층 사이의 분리를 가능하게 하는 패턴. Aggregate의 영속성(저장, 조회, 수정, 삭제)을 관리함.

 

🏛️ 도메인 주도 설계 아키텍처

• 계층형 아키텍처: 상위 계층이 하위 계층에 의존하는 구조. (User Interface -> Application ->  Domain -> Infrastructure).
• DIP (의존 역전 원칙) 적용: 저수준 모듈의 변경이 고수준 모듈 변경으로 이어지는 문제 해결함. 고수준 모듈이 추상화한 인터페이스에 의존함. 이 인터페이스는 고수준 모듈 관점에서 도출되어 Domain 계층에 위치해야 함.

 

🌐 Bounded Context 

• 정의: 구분되는 경계를 갖는 컨텍스트이며 모델의 경계를 결정함. 하나의 모델로 여러 하위 도메인 표현 시 발생하는 문제들을 해결하기 위함.
• 구조: 도메인 기능 제공에 필요한 표현, 응용 서비스, 도메인, 인프라스트럭처 영역 및 DBMS(테이블)까지 모두 포함함.
• 통합: 컨텍스트 간 협력 시, 간접 통합(메시지 큐) 방식 권장함. 하류(데이터 호출)는 상류(데이터 제공)의 데이터를 받아 사용할 때 Anti-Corruption Layer (ACL)을 만들어서 보호함.

 

---

 

2. 멀티모듈 (Multi-Module)

 

흩어져 있던 ‘같은 도메인’을 한 프로젝트 안으로 묶어 일관된 규칙을 공유하게 하는 방법!

 

 하나의 프로젝트를 여러 독립적인 모듈로 나누어 관리하는 구조

• 공통으로 사용하는 코드는 공통으로 관리
• 각 모듈을 독립적으로 배포 가능
• 모듈 간 서로 의존성을 가지며 연결

 

 각 모듈은 특정 기능이나 도메인을 맡아 독립적으로 개발과 배포가 가능하도록 하여, 대규모 프로젝트에서 복잡성을 줄이고 빌드 및 유지보수를 효율화한다!

 

 

필요성과 장점

• 필요성: 단일 모듈의 코드 복잡성, 빌드/배포 시간 증가, 팀 협업 비효율성 등의 한계 때문에 필요함.
  • 흩어져 있던 '같은 도메인'을 한 프로젝트 안으로 묶어 일관된 규칙을 공유하게 함.
• 구조: 하나의 루트 프로젝트와 여러 서브모듈 (api, domain, common 등)로 구성됨.
• 장점: 코드 재사용성 증가, 유지보수성 향상, 빌드 시간 단축 (변경 모듈만 재빌드), 책임/기능의 명확한 분리.

 

모듈 경계 나누기 기준

• 가장 중요한 기준: 경계 안에서 의미를 가질 수 있는 그룹을 정의하는 것, 즉 Bounded Context를 기준으로 나누어야 함.
• 도메인 관점: 유저, 주문 등 비즈니스 도메인 단위로 분리함.
• 백엔드 개발 관점:
  1. 아키텍처 기준: 계층형 아키텍처 (Controller, Service, Repository 등) 기준으로 분리함.
  2. 관련 서버 기준: 관련된 서버 기능 기준으로 분리 (Module-api, Module-domain, Module-batch 등).

 

⚠️ 설계 및 운영 시 주의사항

• 공통 (Common) 모듈의 저주: 공통 모듈은 모든 모듈이 의존하므로, 변경 시 전체에 영향을 끼칠 수 있어 가장 엄격하게 관리되어야 함.
• 의존성 관리: 의존성이 많아져 모듈 간 관계가 복잡해지는 것 (스파게티 코드) 지양해야 함.
• 지나친 세분화: 지나치게 세세한 기준으로 모듈을 나누는 것은 피해야 함.

 

MSA와 관계

• 멀티모듈 역할: 멀티모듈 프로젝트의 각 모듈을 독립적인 마이크로 서비스로 점진적으로 변화(전환)시키는 것이 가능함. 모놀리틱 <-> MSA 전환에 활용할 수 있음.