비즈니스 복잡도를 해체하는 이벤트 스토밍부터 DDD 아키텍처까지 기술

소프트웨어는 결국 현실 세계의 문제를 해결하기 위한 도구입니다.
하지만 비즈니스는 복잡하고, 기획자와 개발자의 언어는 다릅니다.
이 간극을 메우고 유연한 시스템을 만드는 핵심 도구들이 바로 이벤트 스토밍과 DDD입니다.

---

1. 무엇을 쓸 것인가? 도메인 분석의 툴킷?

도메인을 분석하는 방법은 다양합니다. 상황에 맞는 도구를 선택하는 것이 첫걸음입니다.

도구	핵심 목적	특징
이벤트 스토밍	비즈니스 흐름 시각화	이벤트를 중심으로 유저 내러티브를 파악
유저 스토리 맵핑	사용자 경험과 MVP 식별	시간 순서와 우선순위에 따른 사용자 여정 나열
도메인 스토리텔링	협력 구조 탐색	픽토그램을 이용해 누가, 무엇을, 어떻게 하는지 기록
예제 맵핑	인수 조건 도출	구체적인 규칙과 예시를 통해 모호함 제거
C4 모델	아키텍처 시각화	분석 결과를 실제 소프트웨어 컨테이너/컴포넌트로 설계

---

2. 포스트잇으로 설계하는 비즈니스

이벤트 스토밍은 단순히 순서를 나열하는 것이 아니라, 시스템의 인과관계를 파악하는 과정입니다.

이벤트 스토밍의 핵심 구성 요소

• 도메인 이벤트 : 과거형으로 작성된 "사건" 예를 들어 주문됨, 결제 완료되는것이 있습니다.
• 명령 : 사용자가 시스템에 전달하는 "의도".
• 사용자/액터 : 명령을 내리는 주체.
• 집계/애그리게이트 : 명령을 받아 불변식을 검증하고 이벤트를 발행하는 처리기.
• 정책: 이벤트가 발생했을 때 연쇄적으로 일어나는 비즈니스 규칙이 있는데 예를 들어 결제 완료 시 , 배송 시작 명령이 있습니다.
• 읽기 모델/UI : 사용자가 다음 행동을 결정하기 위해 보는 화면이나 데이터 정보.

핵심 인사이트: 내러티브의 끝이 반드시 이벤트일 필요는 없습니다.
사용자가 정보를 확인하는 UI로 끝날 수도 있습니다.
이는 피드백 루프의 완성을 의미합니다.

---

3. 전략적 패턴과 전술적 패턴 의 두 얼굴

DDD는 크게 "어디에 집중할 것인가"와 "어떻게 구현할 것인가"로 나뉩니다.

전략적 패턴

• 컨텍스트 맵 & 바운디드 컨텍스트: 팀 간의 경계를 나누고 싸우지 않게 격리하는 것.
• 디스틸레이션: 무엇이 우리 서비스의 핵심이고 무엇이 지원인지 구분하는 것.

전술적 패턴

• 생명주기 관리: 애그리게이트, 리포지토리, 팩토리.
• 표현: 엔티티, VO, 도메인 서비스.

---

4. 트랜잭션 vs 이벤트 일관성의 전쟁

데이터 정합성을 맞추는 방법은 두 가지입니다.

1. 트랜잭션 일관성: 애그리게이트 내부에서 DB 트랜잭션을 통해 즉시 정합성을 맞춥니다.
2. 결과적 일관성: 애그리게이트 외부에서 도메인 이벤트를 통해 시차를 두고 맞춥니다.

사가패턴과 프로세스 관리자

• 사가 패턴: 각 단계가 실패했을 때 이를 되돌리는 '취소 이벤트'를 정의합니다.
  각 애그리게이트가 자신의 취소 처리에 책임을 집니다.

• 프로세스 관리자: 전체 흐름을 통제하는 별도의 '관리자'가 존재합니다.
  애그리게이트는 개별 취소 로직에 대해 덜 고민해도 됩니다.

---

5. 팀 간의 정치와 코드

바운디드 컨텍스트를 나누는 이유는 기술적 이유보다 커뮤니케이션 비용 때문인 경우가 많습니다.

• 충돌 방지 계층: 외부 시스템의 데이터 구조가 우리 도메인을 오염시키지 않도록 중간에서 변환합니다.
• 오픈 호스트 서비스: 우리 서비스를 외부에서 편하게 쓸 수 있게 표준 API를 제공합니다.
• 공유 커널: 양 팀이 공통으로 사용하는 모델. 하지만 오너십이 불분명하면 위험해질 수 있습니다.

---

6. 왜 함수형 프로그래밍인가?

결국 DDD의 끝은 함수형 프로그래밍과 맞닿아 있습니다.

• 불변성: 상태를 변경하지 않고 새로운 값을 반환하여 부수 효과를 격리합니다.
• 식별성 대신 값: 포인터나 ID 대신 대수적 타입을 통해 '값' 그 자체로 로직을 구성합니다.
• 지연 연산: 연산을 실행 시점까지 늦춰 함수 합성을 용이하게 합니다.

DDD는 기술적인 패턴이 아니라, 비즈니스의 복잡도를 어떻게 나누고, 가두고, 연결할 것인가에 대한 철학입니다.