3단계 - 기능 우선 패키지 구성하기 #340
3단계 - 기능 우선 패키지 구성하기 #340
Conversation
- 패키지 변경 - 컨텍스트 분리 - 주문 컨텍스트는 3개로 분리
| @@ -0,0 +1,153 @@ | |||
| package kitchenpos.deliveryorders.application; | |||
There was a problem hiding this comment.
주문 컨텍스트를 아래와 같이 분리하여 정의해주셨네요 👍
- deliveryorders
- eatinorders
- takeoutorders
이와 같이 분리한 경우 공통적으로 사용하는 도메인 OrderLineItem 이 중복됩니다.
중복을 피하기 위해 분리하는것도 좋은 방법이라고 생각해요 😄
다른 방법으론 주문이라는 컨텍스트 하위에 배달 주문, 매장 식사, 포장 주문을 포함시킬수도 있을것 같습니다.
- orders
- deliveryorders
- takeoutorders
- eatinorders
- shared
주문 이란 컨텍스트에서 공유하는 도메인, VO를 shared 또는 common 이라는 패키지에 정의하고 명시적으로 주문의 유형들을 나타낼수 있는 방법이라고 생각하는데 봉운님은 이와 같은 구조를 어떻게 생각하시나요 >?
There was a problem hiding this comment.
DDD 진행을 통해 서비스가 나뉠수도 있다는 생각에 결합도를 줄이기 위해 shared 패키지명 작성을 자제하고 있었는데,
shared 라는 패키지가 생긴다면 보다 많은 일이 가능할 것 같습니다. :)
There was a problem hiding this comment.
이와 같이 분리한 경우 공통적으로 사용하는 도메인 OrderLineItem 이 중복됩니다.
orders에 따라 OrderLineItem도 분리하여 작성하였습니다.
There was a problem hiding this comment.
궁금한게 있습니다. 주문의 경우 3가지 케이스로 나누다보니 findAll 의 기능을 만들기가 애매해졌습니다.
findAll() 대신 findAllByType() 사용이 가능할까요?
| @@ -1,7 +1,7 @@ | |||
| package kitchenpos.application; | |||
| package kitchenpos.menugroups.application; | |||
There was a problem hiding this comment.
menugroup Aggregate 를 기준으로 패키지를 분리해주셨네요 👍
Menu Context에 MenuGroup을 포함시키는건 어떨까요 ?
There was a problem hiding this comment.
Menu Context에서만 사용하고 있으니 그게 좋겠네요
| import kitchenpos.menus.domain.MenuRepository; | ||
| import kitchenpos.products.domain.Product; | ||
| import kitchenpos.products.domain.ProductRepository; | ||
| import kitchenpos.products.infra.ProfanityClient; |
There was a problem hiding this comment.
products 의 Infra 를 사용한다면 어떤 문제점이 있을까요 ?
There was a problem hiding this comment.
코드의 결합이 강해질 것 같아요.
느슨한 결합을 위해 Adapter 클래스와 같은 도메인 서비스를 만들어 사용하는게 좋을 것 같습니다.
코드 리뷰 요청 드립니다.
잘 부탁 드립니다 ^^