93 lines
4.0 KiB
Markdown
93 lines
4.0 KiB
Markdown
Node.js의 일반적인 패키지 구조 설계
|
|
|
|
MVC패턴
|
|
✔ `controllers/` ➝ **HTTP 요청 처리** (Express 라우트에서 직접 연결)
|
|
✔ `models/` ➝ **데이터베이스 모델** (Mongoose, Sequelize 등 ORM 사용)
|
|
✔ `services/` ➝ **비즈니스 로직** (컨트롤러에서 서비스 호출)
|
|
✔ `routes/` ➝ **라우팅 관리** (각 엔드포인트 정의)
|
|
✔ `middlewares/` ➝ **공통 미들웨어** (인증, 예외 처리, 유효성 검사)
|
|
✔ `utils/` ➝ **공통 유틸리티 함수**
|
|
|
|
Java에서는?
|
|
- **기능(도메인)별로 분리**
|
|
- **변경될 가능성이 높은 부분과 낮은 부분을 분리**
|
|
- **상위 패키지는 안정적이고, 하위 패키지는 유연하게 유지**
|
|
|
|
(1) 계층별 패키지 구조 (Layered Architecture)
|
|
com/example/app/
|
|
├── controller/ (API, UI 관련 로직)
|
|
├── service/ (비즈니스 로직)
|
|
├── repository/ (데이터 접근)
|
|
├── model/ (엔티티, DTO, VO)
|
|
├── config/ (설정 관련 클래스)
|
|
└── exception/ (예외 처리)
|
|
📌 **각 패키지가 역할별로 분리되어 있어 유지보수가 쉬움**
|
|
📌 하지만, **기능이 많아지면 서비스 계층이 너무 커질 수 있음**
|
|
|
|
|
|
(2) 기능(도메인)별 패키지 구조 (Domain-Driven Design, DDD 스타일)
|
|
com/example/app/
|
|
├── user/
|
|
│ ├── controller/
|
|
│ ├── service/
|
|
│ ├── repository/
|
|
│ ├── model/
|
|
│ └── exception/
|
|
├── order/
|
|
│ ├── controller/
|
|
│ ├── service/
|
|
│ ├── repository/
|
|
│ ├── model/
|
|
│ └── exception/
|
|
└── product/
|
|
├── controller/
|
|
├── service/
|
|
├── repository/
|
|
├── model/
|
|
└── exception/
|
|
📌 **각 기능(user, order, product 등)이 독립적이어서 관리가 쉬움**
|
|
📌 **각 기능을 모듈화하여 재사용 가능**
|
|
📌 **대규모 프로젝트에서 효과적** (ex. 마이크로서비스)
|
|
|
|
**➡ 장점: 변경이 한 기능에만 영향을 주므로 확장성이 좋음**
|
|
**➡ 단점: 작은 프로젝트에서는 과도할 수 있음**
|
|
: 작은 프로젝트도 DDD를 채택하고 패키지 구조를 단순화하면 된다.
|
|
|
|
|
|
**작은 프로젝트**라면, 패키지를 지나치게 분리할 필요 없이 다음과 같이 간단하게 유지할 수도 있습니다.
|
|
/com.example.simpleproject
|
|
├── **domain/**
|
|
│ ├── User.java
|
|
│ ├── Order.java
|
|
│ ├── Product.java
|
|
│ ├── UserRepository.java
|
|
│ ├── OrderRepository.java
|
|
│ ├── ProductRepository.java
|
|
│ └── OrderStatus.java (enum)
|
|
├── **service/**
|
|
│ ├── UserService.java
|
|
│ ├── OrderService.java
|
|
│ └── ProductService.java
|
|
├── controller/
|
|
│ ├── UserController.java
|
|
│ ├── OrderController.java
|
|
│ └── ProductController.java
|
|
├── repository/ => 선택
|
|
│ ├── JpaUserRepository.java
|
|
│ ├── JpaOrderRepository.java
|
|
│ └── JpaProductRepository.java
|
|
└── MainApplication.java
|
|
📌 **이 구조의 특징**
|
|
✔ **도메인 로직(`domain`)과 서비스(`service`)를 나누되, 인프라 부분은 따로 관리하지 않음**
|
|
✔ **필요하면 `repository` 패키지를 따로 만들어 DB 구현체를 분리**
|
|
✔ **application 패키지를 없애고 서비스 계층을 단순화**
|
|
|
|
👉 **작은 프로젝트라면 위와 같은 구조로도 충분히 유지보수 가능**합니다.
|
|
![[Pasted image 20250319154830.png]]
|
|
- **도메인**은 핵심 비즈니스 로직과 모델을 다루고,
|
|
- **서비스**는 도메인 객체를 활용해 애플리케이션 로직을 처리하며,
|
|
- **인프라**는 외부 시스템과의 연결 및 구현을 담당합니다.
|
|
|
|
infra의 일부로 repository 가 있을 수 있다.
|
|
infra는 외부와의 상호작용 그 자체를 의미,
|
|
repository는 외부와의 상호작용 중 데이터베이스(DBMS 혹은 File in/output 등) 관련된 부분을 의미 |