로또 미션 - 도메인 주도 개발(DDD) 시도!

이벤트 스토밍

포스트잇 색깔 분류

도메인 이벤트 식별

이벤트 그루핑

Trigger 정의 - Actor, Policy 매핑

VO, Aggregate 정의

이 부분이 너무 아쉽다. 대부분을 VO로 식별하고 구현했는데, 미션 요구사항을 확대하여 엔티티와 Aggregate 개념까지 도입했다면 정말로 도메인 주도 개발의 정석에 가깝게 개발할 수 있었을 것 같다.

• ex) Purchase Aggregate Root

Bounded Context & Context Map 도출

Tactical Design

Application Service

• 유즈케이스를 담당하고, 비즈니스 로직 오케스트레이션 및 트랜잭션 경계를 담당합니다.

Domain Service

• 도메인 객체 생성 및 도메인 로직 수행을 담당합니다.

별도의 Controller로 분리한 이유

로또를 구매하는 것, 로또의 당첨 여부를 확인하는 것, 로또의 수익률을 계산하는 건 별도의 문제 영역이라고 판단하였습니다.

• ex) 로또를 구매하고 바로 로또의 당첨여부를 바로 확인하지 않는다. 별도의 문제 영역이다.
• ex) 수익률이라는 것 또한, 방금 구매한 로또 뿐만 아니라 지금까지 구매한 모든 로또의 수익률을 보는 것과 같이 별도의 문제 영역이다.

Controller에는 Domain을 노출시키지 않은 이유

도메인 주도 개발을 시도하면서, 최대한 큰 범주에서 문제 영역을 바라보고 확장성 있는 설계를 하려고 하였습니다.

확장성 있는 설게에서 도메인을 Presentation Layer까지 노출시킬 경우 변화에 큰 영향을 줄 수 있다고 판단했습니다.

후기

우테코 프리코스를 하면서 도메인 주도 개발(DDD)가 종종 언급되었고, 정말로 프리코스 미션에서 도메인 주도 개발을 선택하는게 좋은 결과를 이끌어낼 수 있는지 궁금했다.

조금은 무모할 수 있지만 직접 로또 미션에 도메인 주도 개발을 적용해보면서 조그만한 규모의 프로젝트에 도메인 주도 개발을 적용하면 어떠한 영향이 있을 지 경험해보려고 했다.

느낀점

장단점 정리해보자면 다음과 같다.

단점

• 주어진 기능적 요구사항에 비해 꽤 복잡한 구조로 구성되었다.
• 이에 따른 엄청난 시간과 노력이 필요하다.

장점

• 객체들 간의 협력관계, Value Object의 책임, 각 Layer 간의 역할 분배는 꽤 깔끔하게 정리되었다고 생각한다.
  • Controller에는 도메인 객체 노출 X, 비즈니스 로직 수행 X
  • Application Service는 유즈케이스 및 트랜잭션 경계
  • Domain Service는 도메인 객체 생성 및 도메인 로직 수행
• 추후 기능이 많이 확장된다면, 리팩토링할 부분이 거의 없을 것 같다. 코드를 추가만 해도 될 것 같다.

사실 도메인 주도 개발의 큰 맥락은 따랐지만, 정말 정석적인 도메인 주도 개발을 했다 보기엔 어렵다. 조금이라도 요구사항이 많아지고 도메인이 복잡해진다면 아마 완성을 못했을지도 모른다.

하지만 조그만한 미션에서부터 시작하여 도전해본 경험은 밑거름이 되어 뿌리를 자라게 하는데 큰 도움을 줄 것이라고 생각한다.

결론

우아한테크코스 프리코스 미션의 요구사항을 충족하는 데에는 도메인 주도 개발(DDD) 접근이 다소 오버엔지니어링이었다고 생각한다.
단순한 입출력 중심의 로직과 제한된 비즈니스 규칙을 구현하는 수준에서는, 복잡한 도메인 모델을 설계하고 계층을 분리하는 과정이 오히려 개발 효율을 떨어뜨릴 수 있다.

그러나 앞으로 진행할 프로젝트에서 다루는 도메인 규칙이 복잡하고, 데이터의 성격이 컨텍스트에 따라 달라지거나, 라이프사이클이 명확히 구분되는 경우 도메인 주도 개발은 강력한 구조적 이점을 제공할 것이라 생각한다.

컨텍스트에 따른 복잡한 도메인 규칙을 명확히 표현하고, 변경에 유연하게 대응할 수 있는 구조를 설계할 때 DDD의 가치가 발휘될 수 있다고 생각한다.