3단계 - 기능 우선 패키지 구성하기

[devFancy]

안녕하세요 리뷰어님!
이번 3단계도 잘부탁드립니다.

이전 2단계 모델링을 기반으로 기능별 패키지로 분리했습니다.
잘부탁드립니다 !

└── kitchenpos
    ├── Application.java
    ├── deliveryorders
    │   └── infra - 배달 대행사
    ├── eatinorders
    │   ├── application
    │   ├── domain
    │   └── ui
    ├── menus
    │   ├── application
    │   ├── domain
    │   └── ui
    ├── products
    │   ├── application
    │   ├── domain
    │   ├── infra - 비속어
    │   └── ui
    └── takeoutorders
        └── empty.txt

• application: 비즈니스 로직
• domain: 도메인 및 JpaRepository
• infra: 외부 Client
• ui - Api 통신

추가 설명

• 만약 Jpa가 아닌 다른 기술을 사용한다면 infra 하위에 persistence로 넣으려고 했지만, 현재 기준에서는 Jpa만 사용하기 때문에, domain 부분에 넣었습니다.
• 그리고 1주차 3단계인 테스트를 통한 코드 보호에 있는 코드도 가져왔습니다.

[sihoony]

안녕하세요~! 준용님,
이번 미션 잘 진행해주셨네요!! 💯
간단한 코멘트 남겼는데, 확인해주세요! 😄
즐거운 하루 되세요~!

[sihoony]

비속어 검사는 상품에 한정되어 사용되는 것인지 고민해보면 좋을 것 같아요.
특정 도메인에만 사용되는 것인지, 전역에 사용되는 것인지 확인해볼까요~!?

[devFancy]

용어 사전과 모델링을 확인해보니, 상품 뿐만 아니라 메뉴 에도 사용되네요!
그래서 kitchenpos 패키지 하위에 common 안의 infra 모듈으로 옮겼습니다!

[sihoony]

👍 👍

[sihoony]

기술적인 관점에서 Interface로 제공되는 JPARepository는 어디에 위치하면 좋을까요?
저는 JPARepository가 편의상 interface로 제공될뿐 구현체로 보여집니다.
DIP 원칙의 관점에서 어디에 위치하면 좋을지, 실제 Domain Package에서 테스트 대상이 되는것이 좋을지 고민해봐주세요~! 😄

[devFancy]

JPARepository 는 도메인 로직이 아닌 데이터 접근 기술에 관련된 것이고, Jpa가 아닌 Jdbc 같은 기술로 대체된다고 가정한다면 infra모듈에 두는 것이 좋다고 생각합니다.

DIP 관점에서도 보면 Domain 레이어는 Infra 레이어에 의존하지 않도록 구성해야 한다고 봅니다.
그래서 infra 모듈로 옮겼습니다 !~

[devFancy]

제가 이해한게 맞으실까요?