프로젝트 디렉토리 구조에 대한 논의

[s0o0bn]

저희 프로젝트의 디렉토리 구조에 대해 정해보면 좋을 것 같습니다.

일반 레이어 아키텍처

가장 기본적인 아키텍처로 MVC에서 주로 활용했던 구조입니다.

|_ controller
|_ service
|_ repository
|_ global
...

위와 같이 레이어 별 디렉토리를 두고 도메인 별 클래스를 두는 구조가 될 것입니다.

각 도메인 별 레이어 아키텍처

위 레이어 아키텍처를 도메인 별로 분리하는 구조입니다.

|_ global
|_ user
    |_ controller
    |_ service
    ...
|_ study
|_ monster
...

각 도메인 별로 로직을 묶어둘 수 있어 도메인 내의 응집성(?)을 확보할 수 있을 것입니다.

---

저는 개인적으로 첫 번째 구조는 각 계층 디렉토리 내에 모든 도메인의 클래스가 존재하게 되어
개발이 점점 진행되고 클래스가 많아지면 이를 관리하고 코드를 보는 입장에서 불편해진다고 느껴졌습니다.
그래서 가능하다면 두 번째 구조가 이후 기능 확장을 고려했을 때도 적절하지 않을까 생각합니다.

번외) 멀티 모듈

이전에 데브코스에서 진행한 프로젝트를 어쩌다보니 전부 멀티모듈로 진행한 경험이 있는데요,
나쁘지 않았어서 그냥 이런 구조도 있다 봐주시면 좋을 거 같습니다.
저희 서비스 규모 상 처음부터 굳이 이정도로 분리할 필요까진 없을 것 같습니다.

간단하게 다음과 같은 구조로 개발을 진행했습니다. 각 모듈은 독립적으로 구분되어 별도의 build.gradle을 가졌습니다.

root project
|_ api // web 계층 모듈 (Controller)
|_ domain // 핵심 비즈니스 로직 계층 모듈 (Service, Repository)
|_ infra // 인프라 계층 모듈 (Redis, DB(JPA), Kafka, FeignClient 등 외부 인프라 기술)

[unikal1]

제가 사용했던 디렉토리 구조는 다음과 같았습니다.

|_ global
    |_ exceptions
    |_ config
|_ domain
    |_ member
    |_study
    |_ monster

도메인 별 레이어 아키텍쳐라고 볼 수 있겠네요. 다만, global 등에서 유틸리티 클래스나 config, 예외 등에 대해 포괄적으로 관리한다는 점이 조금 다른거 같습니다. 이건 어떤가요

[sjhlko]

우선 큰 방식은 2번이 낫다고 생각합니다~ dto 논의했던거에도 적용할 수 있는 구조구요~
그리고 상혁 씨방 식이 더 괜찮다고 생각합니다 저도 큰 줄기가 둘로 나뉜다고 생각해서요~
멀티모듈의 경우 우리 서비스에 과연 의미 있는 구조인가를 깊게 고민해보고 사용해야 할 영역인것 같네요~~

[dioo1461]

그리고 상혁 씨방 식이 더 괜찮다고 생각합니다

동의합니다 .

[s0o0bn]

아 그쵸 저 구조에서 직접적으로 나타내진 않았는데 저도 global이 동일한 역할을 합니다.
그러면 저희 프로젝트는 상혁님 방식으로 가는 걸로 하죠!