DDD(Domain-Driven Design)와 이벤트 스토밍 정리
소프트웨어를 설계할 때, 전통적으로 데이터 중심 설계(Data-Driven Design) 방식을 많이 사용했다 하지만 복잡한 비즈니스 로직을 다룰 때는 도메인 중심 설계(DDD)가 더 적합하다. 이번 글에서는 DDD와 이벤트 스토밍에 대해서 정리해보았다.
데이터 중심 설계 vs 도메인 중심 설계
데이터 중심 설계란?
데이터 중심 설계는 데이터의 구조를 우선적으로 고려하는 설계 방식이다. ERD(Entity-Relationship Diagram)를 먼저 그리고, 데이터베이스 스키마를 정의한 후에 애플리케이션 로직을 작성하는 방식이다.
데이터 중심 설계의 특징
- 데이터베이스 테이블을 중심으로 애플리케이션을 구성
- 정규화를 통해 데이터 무결성을 보장
- CRUD(Create, Read, Update, Delete) 작업이 주된 로직
- 복잡한 비즈니스 로직을 처리하기 어려움
도메인 중심 설계(DDD)란?
도메인 중심 설계(DDD, Domain-Driven Design)는 비즈니스 로직을 중심으로 소프트웨어를 설계하는 방식이다. 데이터가 아니라 도메인(비즈니스 요구 사항과 개념)을 먼저 정의하고, 이를 코드에 반영하는 방식이다.
DDD의 핵심 개념
- 엔티티(Entity) : 고유한 식별자를 가지는 객체
- 밸류 오브젝트(Value Object) : 값 자체로 의미를 가지며 불변성을 보장
- 애그리게잇(Aggregate) : 여러 객체를 하나로 묶어 일관성을 유지하는 단위
- 도메인 서비스(Domain Service) : 비즈니스 로직을 처리하는 서비스
- 레포지토리(Repository) : 엔티티를 저장하고 조회하는 역할
- 팩토리(Factory) : 객체 생성을 캡슐화하여 복잡한 생성 로직을 관리
- 도메인 이벤트(Domain Event) : 도메인에서 발생하는 중요한 사건을 표현
DDD의 주요 장점
- 비즈니스 로직 중심 : 도메인 개념을 반영하여 직관적이고 유지보수하기 쉬운 코드 작성 가능
- 확장성과 유연성 : 도메인 변경이 생겨도 최소한의 수정으로 시스템을 확장 가능
- 언어 통일(Ubiquitous Language) : 개발자와 비즈니스 관계자가 동일한 언어로 소통 가능
- 복잡한 비즈니스 로직 처리 용이 : 도메인 서비스를 통해 복잡한 로직을 깔끔하게 정리 가능
데이터 중심 설계 vs 도메인 중심 설계 차이점
구분데이터 중심 설계도메인 중심 설계(DDD)
| 초점 | 데이터 구조(ERD) | 비즈니스 로직 |
| 설계 우선순위 | 데이터 스키마 → 애플리케이션 로직 | 비즈니스 로직 → 데이터 모델 |
| 코드 구조 | 테이블 중심 (DAO, Service) | 도메인 객체 중심 (Entity, VO, Aggregate) |
| 유지보수성 | 데이터 변경이 적을 때 유리 | 복잡한 로직을 다룰 때 유리 |
| 확장성 | 기능 추가 시 복잡성 증가 | 유연한 확장 가능 |
이벤트 스토밍(Event Storming)이란?
이벤트 스토밍은 비즈니스 프로세스를 시각화하고 이해하기 위한 기법이다. 주요 이벤트를 식별하고, 이를 기반으로 도메인 모델을 설계하는 데 사용된다.
이벤트 스토밍의 과정
- 도메인 이벤트 식별 : 시스템에서 발생하는 중요한 이벤트 나열
- 액터(Actor) 정의 : 이벤트를 유발하는 주체 식별
- 커맨드(Command) 연결 : 이벤트를 발생시키는 명령 정의
- 애그리게잇 도출 : 관련 이벤트를 묶어 애그리게잇으로 정의
- 정제 및 보완 : 전체 흐름을 검토하고 조정
이벤트 스토밍의 장점
- 비즈니스 프로세스를 쉽게 시각화할 수 있음
- 이해관계자(개발자, 기획자, 도메인 전문가) 간의 소통이 원활해짐
- 숨겨진 비즈니스 규칙을 발견할 수 있음
- 도메인 모델을 보다 명확하게 정의할 수 있음
- 개발 초기 단계에서 문제를 사전에 파악 가능
DDD와 이벤트 스토밍을 활용한 설계
DDD와 이벤트 스토밍을 활용하면 복잡한 비즈니스 로직을 효율적으로 관리할 수 있고 데이터 중심이 아닌 비즈니스 중심으로 사고하면서 유지보수성과 확장성이 뛰어난 시스템을 만들 수 있다는 큰 장점이 있다. 이벤트 스토밍을 통해 도메인을 시각적으로 정리하면서 개발자와 비즈니스 관계자 간의 커뮤니케이션도 원활하게 할 수 있다.
정리
데이터 중심 설계는 단순한 CRUD 시스템에 적합하지만, 비즈니스 로직이 복잡해질수록 유지보수가 어려워질 수 있다. 반면 DDD는 비즈니스 로직을 중심으로 시스템을 설계하기 때문에 확장성과 유지보수성이 뛰어나고 이벤트 스토밍을 함께 활용하면 더 명확한 도메인 모델을 만들 수 있다.