TL;DR 애그리게이트를 객체 관계가 아니라 불변식의 경계로 봤다.`Product` 애그리게이트 내부에서 `StockQuantity`로 재고 규칙을 지키고, `Point` 애그리게이트 내부에서 `PointBalance`로 잔액 규칙을 지키게 했다. 그리고 주문 확정 과정에서 `Order`, `Product`, `Point`의 협력은 `OrderFacade`가 조율하도록 했다.DDD를 적용하면서 가장 크게 달라진 생각은 "어떤 객체가 누구를 참조하는가"보다"어떤 상태를 함께 변경해야 불변식을 지킬 수 있는가?"가 더 중요하다는 점이었다. 재고와 포인트는 모두 숫자로 표현할 수 있다. 하지만 숫자를 Application에서 직접 바꾸면 0 미만 재고, 잔액 부족, 충전 한도 같은 규칙이 호출 지점마다 반복된..

이번 주에 새롭게 알게 된 것이번 주에는 쿠폰 적용 기능을 구현하지 않았다. 대신 구현하기 전에 무엇이 정해져 있어야 하는지를 계속 정리했다.처음에는 조금 이상했다. 요구사항도 있는데, 쿠폰 도메인을 만들고 할인 계산부터 하면 되는 것 아닌가 싶었다. 그런데 요구사항을 읽을수록 어떻게 구현할지가 아니라, 무엇을 구현해야 하는지가 더 애매했다.구매자는 확정 전에 쿠폰을 적용할 수 있다. 확정된 할인 금액은 유지된다. 문장은 두 개뿐이었는데, 할인 금액이 주문 금액보다 크면 어떻게 되는지, 이미 쿠폰이 있는 주문에 다른 쿠폰을 요청하면 어떻게 되는지, 운영자도 적용할 수 있는지처럼 질문은 계속 나왔다. 이번 주에는 요구사항을 바로 코드로 옮기기 전에, 확인된 사실과 아직 답이 없는 질문을 나누는 일이 먼저라..

모호한 요구사항, 어디까지 개발자가 정해도 될까요?TL;DR모호한 요구사항을 개발자의 추측으로 채우지 않아야 한다.확인된 사실, 실습 장면의 조건, 실제 제품 담당자에게 물을 질문으로 분리한다.불변식은 확정된 사실을 지키는 규칙이지, 아직 답을 받지 못한 제품 정책을 대신 결정하는 수단이 아니다.그 뒤에야 API 계약과 도메인 책임 경계를 선택할 수 있다.들어가며쿠폰 적용 요구사항에 대해 들었을 때, 구현 방법보다 무엇을 구현해야 하는지가 먼저 모호했다."쿠폰을 적용한다"는 문장은 익숙했다. 하지만 막상 설계를 시작하니, 할인 금액은 어디까지 허용해야 하는 거지? 구매자 말고도 쿠폰을 적용할 수 있으려나? 이미 쿠폰이 적용된 주문에 다른 쿠폰을 요청하면 어떻게 해야 하는 거지? 이런 결정되지 않은 부분이..