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 등) 관련된 부분을 의미