수정된 설계도는 이러하다. Product 안에 Post 와 Reply 를 같은 어그리거트로 두었지만, 분리를 하였고,
Order 어그리거트 내에도 OrderProduct 를 두었지만, 이를 삭제하였다.
아직 완벽하게 설계를 끝마친 것은 아니지만, 설계를 하면서 마주쳤던 몇가지 어려움과 궁금증에 대해 적어놓을까 한다.
1. 어디까지가 어그리거트의 경계일까 ?
매우 어려웠다. 도메인 주도 개발 시작하기 - DDD 핵심 개념 정리부터 구현까지, 최범균님 지음 이라는 책을 참고하면서 설계를 해보고있는데, Order 의 어그리거트 안에 payment 와 Delivery 가 들어가야 할지 말지에 대한 고민이 많았고, 사실 아직도 현재 진행중인 고민이다. 우린 Order의 status 라는 필드를 통해 결제 대기, 결제 완료, 배송 대기, 배송 완료, 주문 완료와 같은 상태를 제공하고, 이를 통해 서비스를 제공하려고 요구사항을 설정을 했는데, Payment 와 Delivery 어그리거트를 진행할때 Order 의 필드를 수정하게 되는, 다른 어그리거트의 Root entity를 수정하게 되는 상황이 발생하게 되었다. 여기서 우린 같은 어그리거트로 봐야할지, 다른 어그리거트로 분류해서 진행해야할 지에 대한 의문점이 생겼었다. 우선적으로 내린 결론은, 결제 와 배송 모두 다른 api를 호출하여 서비스를 제공한다라는 요구사항을 설정하였기에, 분리하는 것으로 적용하였다.
또한 Product,Post,Reply 를 구분짓는데에 있어서도 어려움이 있었다.
난 초기에 3가지 엔티티를 모두 묶어서 같은 어그리거트라고 생각을 했다. Product가 reply와 post를 가진다고 생각하였기 때문이다. 하지만 변경에 있어서 둘은 상관이 없었고, 사용하는 주체 역시 product는 seller, post는 customer 가 될 것이었기 때문에 분리하였다.
2. Entity 뽑아내기 ??
방금 말한 `post`는 `customer` 가 될 것이었기 때문에 라는 말을 좀 더 설명하자면, 처음에 Post 내에 enum PostCategory등을 필드로 두어서 1일 경우 해당 포스트는 리뷰, 2일 경우엔 QnA와 같은 역할을 하게 하려고 했다.
그래서 처음 엔티티를 뽑았을 때 Post 라는 공통으로 뽑아냈었다. 그래서 처음 기능 설계를 할 때에도 review와 QnA를 같이 묶어놓고 설계를 하였다.
하지만 생각해보니 가장 먼저, 쿠팡과 네이버 쇼핑몰 등을 참고하여 보니 review와 QnA의 필드 자체가 달랐고, 그 둘을 묶어서 Post라고 칭할 이유가 없었다.
그래서 이와 같이 분리하게 되었다.
이후 일정
약 40일의 프로젝트 기간을 정해서 시작하게 되었다. 처음부터 배포를 진행하고, Travis CI 를 적용시켜서 해볼 생각이다.
기존 프로젝트를 진행하면서, 만일 2일이 걸릴거같으면 3일정도로 일정을 잡았는데, 뭔가 시간이 많다는 안일함이 생겨서 느슨해졌던 경험이 있다. 그래서 이번엔 일정을 좀 더 타이트하게 진행해볼 생각이다.
또한 스트레스 테스트, 일부 도메인에 한해서 TDD도 적용시켜볼 생각이고, 틈틈이 내가 겪었던 문제들이나 이슈에 대해서도 문서화를 하고, swagger 도 사용해볼 생각이다.
나의 재밌고 알찬 세번째 프로젝트가 될 것 같다 !
