DDD를 공부하며 설계의 기준을 고민하다

이번 주에는 DDD에 대해 공부를 해보면서 정리하고, 시나리오 문서를 기반으로 상품, 브랜드, 좋아요, 주문 도메인의 요구사항과 설계 범위를 문서화하는 작업을 진행했다. 사용자와 관리자 관점의 기능 요구사항을 정리하고, 시퀀스 다이어그램, 클래스 다이어그램, ERD를 통해 각 도메인의 책임과 관계가 드러나도록 설계 산출물을 작성했다.

이번 작업에서 가장 많이 고민했던 부분은 상품과 재고를 하나의 도메인으로 볼 것인지, 재고를 별도의 도메인으로 분리할 것인지였다. 현재 요구사항에서는 주문 생성 시 상품 재고를 확인하고, 충분하면 주문이 성공하며 재고가 즉시 차감된다. 반대로 재고가 부족하면 주문은 실패한다. 예약 주문이나 창고별 재고 같은 추가 정책은 아직 정해져 있지 않았다.

그래서 이번에는 현재 정해진 정책에 집중하기 위해 상품이 재고 수량을 직접 가지는 방식으로 설계했다. 이 방식은 현재 요구사항을 가장 단순하게 설명할 수 있고, 주문 생성 흐름도 자연스럽게 이어진다. 다만 재고 정책이 복잡해지는 시점이 오면 Product의 책임이 커질 수 있고, 그때는 재고를 별도 도메인으로 분리하는 것을 검토해야 한다고 판단했다.

멘토님 리뷰를 통해 이 결정에 대해 조금 더 확신을 얻을 수 있었다. 도메인을 나중에 다시 분리해야 하는 설계는 실패한 설계가 아니라, 비즈니스가 성장하면서 자연스럽게 발생하는 일이다. 중요한 것은 처음부터 모든 미래 가능성을 반영하는 것이 아니라 현재 책임을 한 곳에 명확히 모아두는 것이라는 점이었다. 책임이 흩어져 있으면 나중에 분리하기 어렵지만 한 곳에 잘 모여 있다면 필요한 시점에 비교적 자연스럽게 분리할 수 있다.

이번 주 DDD를 공부 하고 직접 도메인 설계를 고민해보며 느낀점은 “현재 요구사항 안에서 어떤 결정을 내리고 왜 그렇게 판단했는가”를 설명하는 일이 더 중요하다는 것이였다. 왜 A 는 되고 B는 안되는가 보단 A 를 했을 때와 B를 했을 때 각각의 차이점과 어떤 트레이드 오프가 있는지를 생각해보는 것이 더 좋은 설계를 만들 수 있다고 느꼈다.