4주차: 프로젝트 세팅 & 아키텍처 구조 이해하기
3주차에서는 HTTP 통신과 스프링의 기본 동작 원리에 대해 학습했다면,
이번 4주차에서는 드디어 실제 Spring Boot 프로젝트를 생성하고 구조를 설계하는 단계로 넘어갔다.
단순히 코드를 작성하는 것이 아니라,
어떻게 구조를 설계할 것인지를 고민하는 단계였다는 점이 가장 중요했다.
📌 아키텍처 구조란?
아키텍처 구조는 쉽게 말하면
프로젝트의 뼈대를 설계하는 것이다.
단순히 코드를 작성하는 것이 아니라,
어떤 기준으로 파일을 나눌지
어떤 역할을 어디에 둘지
어떻게 확장할 수 있게 만들지
를 미리 고민하는 과정이다.
✔ 왜 필요한가?
- 유지보수가 쉬워짐
- 기능 추가 시 영향 범위 최소화
- 협업 시 구조 이해가 쉬움
📌 아키텍처 구조의 종류
1️⃣ 계층형 아키텍처
Controller
Service
Repository이렇게 역할 기준으로 나누는 방식으로 대부분의 기본적인 Spring 구조
2️⃣ 도메인형 아키텍처
기능(도메인) 기준으로 구조 분리
예:
user
mission
review각 도메인 안에 controller / service / repository 포함
📌 이번 과제에서 사용한 구조
이번 미션에서는
도메인형 아키텍처를 기반으로 프로젝트를 구성했다.
워크북 기준 도메인을 보면
사용자 미션 리뷰
로 나눌 수 있었고,
내 ERD를 기준으로 다음과 같이 구성했다.
< 도메인 분리 >
사용자
user, preference, food_category
user_term_agreement, term, notification
미션
mission, participate, market, region
리뷰
review
📌 프로젝트 세팅
1️⃣ Spring Boot 프로젝트 생성
- Gradle (Groovy)
- Spring Web
- Spring Data JPA
- MySQL Driver
- Lombok
2️⃣ 환경 설정 (application.yml)
spring:
application:
name: "umc10th"
datasource:
driver-class-name: com.mysql.cj.jdbc.Driver
url: ${DB_URL}
username: ${DB_USER}
password: ${DB_PW}
jpa:
database: mysql
database-platform: org.hibernate.dialect.MySQLDialect
show-sql: true
hibernate:
ddl-auto: update
👉 민감 정보는 .env로 분리해서 관리
📌 도메인형 패키지 구조
domain
├── user
├── mission
├── review
├── notification
├── term
├── region
└── preference
global
├── config
├── exception각 도메인 내부 구조:
controller
service
repository
entity
dto
converter📌 Swagger 설정
Swagger는
API 문서를 자동으로 생성하고 테스트할 수 있는 도구이다.
❶ 의존성 추가
implementation 'org.springdoc:springdoc-openapi-starter-webmvc-ui:3.0.1'❷ SwaggerConfig
@Configuration
public class SwaggerConfig {
@Bean
public OpenAPI swagger() {
Info info = new Info()
.title("UMC10th")
.description("10기 Swagger")
.version("0.0.1");
return new OpenAPI()
.info(info)
.addServersItem(new Server().url("/"));
}
}❸ 결과 확인
http://localhost:8080/swagger-ui/index.html
로 접속하면 API 문서를 UI로 확인 가능
📌 핵심 개념 정리
1. DTO
- 계층 간 데이터 전달 객체
- Entity 직접 노출 방지
2. Converter
- DTO ↔ Entity 변환 담당
- 역할 분리 & 유지보수성 증가
3. DDD vs 도메인형 아키텍처
- DDD → 설계 철학
- 도메인형 아키텍처 → 코드 구조 방식
📌 느낀 점
이번 4주차를 하면서 가장 크게 느낀 점은
“코드를 잘 짜는 것보다 구조를 잘 짜는 게 더 중요하다”는 것이었다.
처음에는 단순히 프로젝트를 생성하는 단계라고 생각했는데,
실제로는
ERD를 기반으로 도메인을 나누고
구조를 설계하고
확장성을 고려하는
설계 중심의 단계였다.
📌 마무리
이번 주차에서는
단순한 코드 작성이 아닌 구조 설계의 중요성을 배울 수 있었다.
다음 주차에서는
이 구조 위에 실제 API를 구현해보면서 더 깊이 이해해보고 싶다.
