Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
개요
안녕하세요 리뷰어님, 이번 3단계 미션 리뷰 요청드립니다.
고민 포인트
패키지(모듈)과 바운디드 컨텍스트에 대한 생각
바운디드 컨텍스트는 자연스럽게 식별되는 하위 도메인에 우리가 인위적인 경계를한다고 느껴짐
흔히들 바운디드 컨텍스트를 회사내 조직(팀)의 관점으로 이야기를 하시는데(조직 개편 == 조직의 경계 구분)
따라서 이번 미션에서 페어와 동의하에 식별한 개념이 곧 우리 서비스의 바운디드 컨텍스트라 판단
따라서 패키지를 구성할 때도 (메뉴/상품/배달주문/포장주문/매장주문) 단위로 패키지 정의
Order 를 어떻게 활용할 것인가?(공통 코드로 관리 or 각 요구사항별 분리)
Order 의 경우 각 주문타입마다 정책이 다르고 프로세스도 많이 다름 => 블랙박스 구조인가? X => 같은 추상화 레벨이 아님
정책이 다른데 중복을 없애기 위해 공통을 만드는 것이 맞는가? -> 정책 기준 SRP 를 위반한다 생각
따라서 중복을 제거하고자 공통으로 관리하는 것보다 서로 분리하는게 맞다고 생각함
패키지 설명
개인적으로도 Layered Architecture 를 좋아합니다.
제가 추구하는 방식은 각 바운디드 컨텍스트를 루트(모듈)로 설정하고
하위 레이어들을
api
/application
/domain
/infrastructure
로 설정하고 있습니다.여기서 infrastructure 는 domain 패키지의 인터페이스를 참조하여 DIP 형태를 지향하고자 합니다.
패키지 구조
논의 했던 내용