Notice
Recent Posts
Recent Comments
Link
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | 31 |
Tags
- springController
- jpa양방향연관관계
- jpa김영한
- MultipartFile
- jpa주요기술소개
- 인텔리제이
- 인메모리
- SpringTest
- OAuth2.0
- jpa에대해서어떤걸공부할지
- Github
- 실전! 스프링 부트와 jpa 활용1
- 단축키
- issue
- spring security
- jpa사용이유
- JPA
- 도메인 사용하기
- S3
- json 받기
- 김영한
- 도메인
- java
- 인증과인가
- SpringSecurity
- 구글 소셜로그인
Archives
- Today
- Total
whdudev
스프링 프로젝트 패키지 구조 본문
프로젝트할 때 마다 패키지 구조를 관성적으로 이전 구조랑 똑같이 진행했는데 이참에 패키지 구조 유형에 대해 정리하고자 한다.
✅ 패키지 구조
크게 2가지가 있다. 도메인형, 계층형
도메인형
└── src
├── main
│ ├── java
│ │ └── com
│ │ └── example
│ │ └── demo
│ │ ├── DemoApplication.java
│ │ ├── coupon
│ │ │ ├── controller
│ │ │ ├── domain
│ │ │ ├── exception
│ │ │ ├── repository
│ │ │ └── service
│ │ ├── member
│ │ │ ├── controller
│ │ │ ├── domain
│ │ │ ├── exception
│ │ │ ├── repository
│ │ │ └── service
│ │ └── order
│ │ ├── controller
│ │ ├── domain
│ │ ├── exception
│ │ ├── repository
│ │ └── service
│ └── resources
│ └── application.properties
도메인 디렉터리 기준으로 코드를 구성한다. 도메인형의 장점은 관련된 코드들이 응집해 있는 장점이 있다. 단점은 프로젝트에 이해도가 낮을 경우 전체적인 구조를 파악하기 어려운 점이 있다.
계층형
└── src
├── main
│ ├── java
│ │ └── com
│ │ └── example
│ │ └── demo
│ │ ├── DemoApplication.java
│ │ ├── config
│ │ ├── controller
│ │ ├── dao
│ │ ├── domain
│ │ ├── exception
│ │ └── service
│ └── resources
│ └── application.properties
계층형 구조는 각 계층을 대표하는 디렉터리를 기준으로 코드들이 구성됩니다. 프로젝트에 대한 이해도가 낮아도 프로젝트를 빠르게 파악할 수 있지만, 디렉터리에 클래스들이 너무 많이 모이는 단점 존재
✅ 어떤걸 선택할까?
간단한 프로젝트는 계층형에서 진행하는게 좋을 것 같지만, 마이크로서비스 아키텍처로의 확장을 염두하거나 많은 양의 클래스를 작성해야할 프로젝트라면 오히려 도메인형으로 프로젝트 패키지 구조를 작성하는걸 추천할 것 같다.
도메인형을 사용하는 것이 OOP관점과 ORM 기술을 사용함에 있어서 핵심이 되는 Entity의 특성을 기반으로 패키징하는 것이 해당 기술들의 관점과 지향점과도 맞다. 라는 의견도 있다.
OOP을 지향하고 JPA를 활용하고 있다면 도메인형을 도입하는걸 적극 검토하는게 어떨까.
✅ 도메인형의 전체 구조
└── src
├── main
│ ├── java
│ │ └── com
│ │ └── spring
│ │ └── guide
│ │ ├── ApiApp.java
│ │ ├── SampleApi.java
│ │ ├── domain
│ │ │ ├── coupon
│ │ │ │ ├── api
│ │ │ │ ├── application
│ │ │ │ ├── dao
│ │ │ │ ├── domain
│ │ │ │ ├── dto
│ │ │ │ └── exception
│ │ │ ├── member
│ │ │ │ ├── api
│ │ │ │ ├── application
│ │ │ │ ├── dao
│ │ │ │ ├── domain
│ │ │ │ ├── dto
│ │ │ │ └── exception
│ │ │ └── model
│ │ │ ├── Address.java
│ │ │ ├── Email.java
│ │ │ └── Name.java
│ │ ├── global
│ │ │ ├── common
│ │ │ │ ├── request
│ │ │ │ └── response
│ │ │ ├── config
│ │ │ │ ├── SwaggerConfig.java
│ │ │ │ ├── properties
│ │ │ │ ├── resttemplate
│ │ │ │ └── security
│ │ │ ├── error
│ │ │ │ ├── ErrorResponse.java
│ │ │ │ ├── GlobalExceptionHandler.java
│ │ │ │ └── exception
│ │ │ └── util
│ │ └── infra
│ │ ├── email
│ │ └── sms
│ │ ├── AmazonSmsClient.java
│ │ ├── SmsClient.java
│ │ └── dto
│ └── resources
│ ├── application-dev.yml
│ ├── application-local.yml
│ ├── application-prod.yml
│ └── application.yml
도메인 디렉토리 = 비즈니스 단위 디렉토리
- api : REST API 컨트롤러
- application : 서비스 로직, 트랜잭션 등 도메인 로직 조합 (service 계층과 유사)
- dao : QueryDSL 등을 활용한 데이터 조회 관련 DAO들
- domain : 핵심 도메인 엔티티, 관련 Enum 및 Embeddable 객체
- dto : 요청/응답용 DTO
- exception : 도메인 관련 예외
global 디렉토리
- common : 공통 request/response 형식
- config : Swagger, Security 등 설정
- error : 글로벌 예외 처리 및 공통 에러 코드
- util : 유틸성 클래스
Infra 디렉토리
- 예: email, sms 전송 클라이언트
- 클라이언트는 인터페이스 + 구현체 구조로 구성 (유지보수성과 대체 가능성 고려)
게시글과 댓글의 경우 같은 도메인으로 볼 것이냐?
작성자의 경우 주관적으로 독립적으로 재사용되거나 복잡한 기능을 가지지 않는 다고 판단 된다면 같은 도메인으로 보려고 한다.
✅ 참고
'PROJECT' 카테고리의 다른 글
| [auctify] Mixed Content 경고 (1) | 2025.06.08 |
|---|---|
| [auctify] Nginx 리버스 프록시일 경우 SSE연결 오류 해결 (0) | 2025.04.30 |
| [이론] 결제 시스템 (0) | 2025.03.20 |
| [auctify]POSTMAN 쿠키로 넣어서 요청 보내기 (0) | 2025.03.11 |
| [Error] [OAuth2.0구현 과정에 발생한 문제] 쿠키가 공유가 안 되요! CORS, Domain문제 (0) | 2025.03.07 |