💡 프로젝트 패키지 구조는 어떻게 구성하는 편이 좋을까요?

[maketheworldwise]

제가 참고한 사이트에서는 도메인형 구조로 기술되어있는데, 도메인간 경계를 나누기 애매한 부분들이 있다보니 계층형 구조를 가져가는게 어떨까요?

제가 생각한 계층형 구조는 3가지로 나누었습니다.

🗂 . applications
     📄 . UserService.java
     📄 . UserServiceImpl.java
🗂 . domains
     📄 . User.java
     📄 . UserRepository.java
🗂 . interfaces
     🗂 . dtos
          📄 . LoginRequestDto.java
     📄 . UserController.java

[NamKey]

어떤 부분이 도메인 간 경계가 애매하다고 생각하시나요? @maketheworldwise

[maketheworldwise]

생각했던 부분은 products와 stores / products와 buyer 의 관계에서 애매함이었습니다. 엄청 깊게 생각해보지는 않았습니다.

[NamKey]

products/stores와 products/buyer의 관계에서 어떤 부분이 애매하다고 느끼시나요?

예를 들면

• Stores는 Products를 갖고 있고 Stores API를 호출하면 Store에 대한 정보와 Product에 대한 정보를 다 가지고 오는 경우
• Buyer가 Product 구매목록을 갖고 오는 경우

이런 상황에서 어떤 애매함이 있을까요?

도메인 구조로 패키지를 분리하여도 계층형 구조는 사용해야됩니다.(도메인형 내에서 계층형)

[maketheworldwise]

예를 들어 Product DTO 클래스를 Store 도메인에서 사용한다던지 혹은 Product Repository를 사용한다던지 등등 그런 부분에서 도메인별로 나뉘어지는 것이 맞는가에 대한 의문에서 시작했습니다. 말씀드렸듯이 깊게 생각한 부분이 아니라서 큰 문제라고 생각하지는 않지만 어떤 구조를 가져갈지에 대한 논의도 필요해보여서 Discussion으로 작성했습니다. 굳이 제가 언급한 구조에 대한 내용이 아니더라도 생각하고 계시는 구조를 말씀해주시면 좋을것 같아요.

[NamKey]

Product DTO를 Store Domain에서 사용해도 괜찮다고 생각합니다.

왜냐하면 Store과 Product는 테이블로도 연결되어 있고 Store가 Product를 갖고 있는 부분은 저희가 논의한 기획이기 때문입니다.
따라서 도메인별로 나뉘더라도 결합도는 있어도 된다고 생각합니다. 만약 결합도가 없다고 하면 실제 둘의 관계가 독립적인 관계여야 가능할텐데 그렇지 않기 때문에 결합도가 생기는 것이라 생각됩니다.

저는 도메인을 기반으로 나눈 구조가 좋다고 생각합니다.
도메인의 범위에 대한 부분�은 Common, User, Store, Product 의 구조로 생각하고 있습니다.

[maketheworldwise]

그럼 저희는 하단의 구조처럼 가져가는걸로 할까요?!

🗂 . Common
     🗂 . applications
     🗂 . domains
     🗂 . interfaces
          🗂 . dtos
🗂 . Product
     🗂 . applications
     🗂 . domains
     🗂 . interfaces
          🗂 . dtos
🗂 . Store
     🗂 . applications
     🗂 . domains
     🗂 . interfaces
          🗂 . dtos
🗂 . User
     🗂 . applications
          📄 . UserService.java
          📄 . UserServiceImpl.java
     🗂 . domains
          📄 . User.java
          📄 . UserRepository.java
     🗂 . interfaces
          🗂 . dtos
               📄 . LoginRequestDto.java
               📄 . UserController.java

[NamKey]

이런 방향은 어떻게 생각하시나요?

• controller의 경우 modelandview도 사용할 수 있기때문에 api/view package를 구분하고 dto의 경우 반환하는 곳이 controller이므로 하위에 배치했습니다.

• service의 경우 converter package를 놓아서 service layer에서만 사용함을 나타내는 것도 좋을 것 같습니다.

• domain의 경우 repository와 entity package를 두고 작업하면 좋을 것 같습니다.

• 추가적으로 service와 repository의 경우 Interface를 선언하는 부분을 contract, 구현하는 패키지를 impl로 따로 분리하는 것도 좋을 것이라 생각됩니다.
  (repository의 경우 Interface와 Impl 분리할 경우 경로 지정해줘야 함)

🗂 . User
     🗂 . controller
          🗂 . api
              📄 . UserSignInRestController.java
              📄 . UserSignUpRestController.java
          🗂 . view
              📄 . UserSignInViewController.java # 만약 화면을 반환하는 부분이 필요하다면
          🗂 . dtos
              📄 . LoginRequestDto.java
     🗂 . service
          📄 . UserSignUpService.java
          📄 . UserSignUpServiceImpl.java
          🗂 . converter
              📄 . LoginRequestConverter.java
     🗂 . domain
          🗂 . repository
               📄 . UserRepository.java
               📄 . UserRepositoryImpl.java
          🗂 . entity
               📄 . UserEntity.java

[maketheworldwise]

좋아보이긴 하지만 개인적으로는 불필요하게 패키지를 늘리는 것 같아 번잡하다(?)는 느낌이 들어서 오히려 가독성이 떨어지는 것 같다는 생각이 드네요 🤔 이 부분에 대해서는 조금 더 고민해볼게요!

[NamKey]

어떤 부분에서 패키지를 불필요하게 나눈다고 생각되시나요?

[maketheworldwise]

말씀해주신 구조에 대해서는 좋은 구조라고 생각합니다. 다만 IntelliJ와 같은 툴처럼 자동으로 클래스명을 기준으로 정렬해줘서 보여주고, 도메인 구조로 가져갔다는 의미는 관련되어있는 것끼리 이미 묶었다는 건데, 여기서 더 세부적으로 나눌 필요가 있을까? 라는 점에서 조금 더 고민해보고 싶다는 의미였습니다.