[TIL] 전략적 DDD와 전술적 DDD

 

앞서 DDD의 등장배경과 그 목적, 개념 등을 살펴보았다. 이번 포스팅에서는 DDD가 어떠한 축으로 나누어지는지에 대해 정리해보고자 한다.

 

DDD는 각 전략적, 전술적으로 나뉘게 되는데, DDD가 이 두 단계로 나뉘는 이유는 소프트웨어의 복잡성을 해결하는 층위가 다르기 때문이다. 

 

• 전략적 설계 (Strategic): 비즈니스 전체의 방향과 구조를 잡는 것 (무엇을 만들고, 어떻게 나눌 것인가?)
• 전술적 설계 (Tactical): 결정된 구조 내부의 구현 상세를 다루는 것 (어떤 코드로 구현할 것인가?)

---

 

전략적 DDD - 경계를 나누는 설계

• 시스템을 어떻게 나눌 것인가
• 우리 서비스는 어디까지가 하나의 모델인가?
• 서비스 경계는 어디인가?

즉, 큰 그림을 설계하는 단계이다.

 

전략적 DDD는 코드를 짜기 전, 기획자와 개발자가 같은 언어(유비쿼터스 언어)를 쓰며 비즈니스를 쪼개는 단계이다.

 

왜 필요한가?

커다란 시스템을 한 덩어리로 만들면 유지보수가 불가능해지기 때문이다. 예를 들어, 대규모 시스템에서는 이런 일이 있을 수 있다.

주문팀, 결제팀, 배송팀, 정산팀에서는 주문을 칭할 때 모두 "Order"라는 단어를 쓰지만 비즈니스에 따라 각자의 의미가 달라질 수 있다.

예) 주문팀의 Order: 고객이 장바구니에서 생성한 주문 객체
정산팀의 Order: 매출 집계 단위

이것을 하나의 모델로 묶게 된다면 
서로 다른 요구사항이 충돌하게 되고 유지보수 면에서 관리가 어려워진다.

 

그래서 등장하게 된 것이 Bounded Context이다. 이는 하나의 모델이 유효한 경계를 의미한다. 따라서 같은 단어라도 Context가 다르면 다른 모델로 취급한다.

 

핵심 개념

• Bounded Context
  • '사용자'라는 단어도 쇼핑몰에서는 '구매자'이고, 배송 시스템에서는 '수령인'이다. 같은 단어라도 의미가 달라지는 경계를 나누는 작업
• Context Map
  • 분리된 컨텍스트들이 서로 어떻게 데이터를 주고받는지 지도로 그린다
• Ubiquitous Language
  • 개발자, 기획자, 디자이너 모두가 공통으로 사용하는 용어를 정의

 

전략적 DDD의 목적

• 모델 충돌 방지
• 조직 단위와 시스템 경계 정렬 (비즈니스 전체를 조망하고, 시스템을 어떤 덩어리(서브도메인)로 나눌지 결정_
• 복잡성 분산
• 팀 간 독립성 확보

 

---

전술적 DDD - 모델을 구현하는 설계

 

전략적 설계를 통해 경계(Bounded Context)가 정해졌다면, 이제 그 안에서 어떻게 객체를 설계할지 정하는 단계이다.

• 그 안에서 모델을 어떻게 잘 만들 것인가?

왜 필요한가?

전략적으로 나눈 각 구역(Bounded Context) 내부를 실제로 어떻게 구현할지 결정하기 위해서이다. 이때, 데이터의 무결성을 지키고 비즈니스 로직을 코드에 녹여내기 위한 설계 도구(패턴)들을 사용한다.

핵심 개념

• Entity : 식별자(ID)를 통해 연속성과 정체성을 유지하며 상태가 변할 수 있는 객체
• Value Object : 식별자 없이 속성 값 자체로만 정의되며, 수정 불가능한(Immutable) 불변 객체
• Aggregate(애그리거트)
  • 데이터 변경의 단위로 묶인 객체들의 집합 (예: 주문과 주문 항목은 하나로 묶임)
• Repository : 애그리거트를 저장하고 조회하는 인터페이스
• Domain Service : 엔티티나 VO에 담기 애매한 비즈니스 로직을 처리
• Factory : 복잡한 애그리거트나 엔티티의 생성 로직을 캡슐화하여 생성 책임을 분리한 객체

 

전술적 DDD의 목적

• 비즈니스 규칙을 객체 안에 넣기
• 상태 변경을 명확하게 관리하기

---

왜 굳이 전략적, 전술적으로 나눴을까?

규모 문제(Scale)

아무리 뛰어난 코드 구현(전술적)을 해도, 애초에 비즈니스 영역을 잘못 나눴다면(전략적) 시스템은 무너지기 마련이다. 해결하고자 하는 문제의 유형이 다르기에 전략적, 전술적으로 나누어졌다.

소통의 문제

전략적 설계는 비개발자(도메인 전문가)와 소통하기 위함이고, 전술적 설계는 개발자끼리 구현을 견고히 하기 위함이라고 볼 수 있다.

 

 

전략적 DDD가 전술적 DDD보다 선행되어야 하는 이유?

전술적 설계는 코드 품질을 높여주지만, 전략적 설계는 비즈니스의 본질적인 복잡성을 해결하기 때문이다.
아무리 완벽한 엔티티와 애그리거트를 설계해도, 도메인 간의 경계(Bounded Context)가 잘못 설정되어 있다면 시스템 간의 의존성이 스파게티처럼 꼬이게 된다. 따라서 큰 그림을 먼저 그리는 전략적 설계가 선행되어야 한다.

 

 

전략적 DDD 없이 전술적 DDD만 쓰면?

Entity, VO는  잘 구성되었으나, 팀 간 모델 충돌 발생 확률이 높아진다.

 

전술적 DDD 없이 전략적 DDD만 쓰면?

서비스는 잘 나눴는데 각 서비스 내부가 CRUD 덩어리가 될 수 있다.

 

 

 

 

 

참고

https://curiousjinan.tistory.com/entry/ddd-strategic-design-guide

[DDD] 도메인 주도 설계: 전략적 설계 (Strategic Design)

https://share-factory.tistory.com/51

[DDD 첫걸음] 1. 전략적 설계

https://velog.io/@seculoper235/DDD-%EC%A0%84%EB%9E%B5%EC%A0%81-%EC%84%A4%EA%B3%84-%EB%8F%84%EB%A9%94%EC%9D%B8%EC%9D%80-%EB%AD%98%EA%B9%8C%EC%9E%91%EC%84%B1%EC%A4%91

[DDD] 전략적 설계 - 도메인은 뭘까?

https://ming412.tistory.com/323

#9. DDD 전략적 설계에 대해 알아보자