프로젝트 패키지를 나누는 방법

프로젝트를 진행하다 보면 항상 패키지를 어떻게 나누면 좋을지 고민되었습니다. 명확한 기준 없이 패키지를 나누다 보면 어느 클래스가 어느 패키지에 있는지 찾느라 고생하기도 했습니다.

마침 패키지를 어떻게 나누면 좋을지에 대한 글들이 있어 정리하려 합니다.

Package By Layer

Package By Layer은 최상단 패키지가 다양한 어플리케이션 계층를 반영합니다.

com.example
├── domain
│    ├── User.java
│    └── Pet.java
├── controllers
│    ├── UserController.java
│    └── PetController.java
├── repositories
│    ├── UserRepository.java
│    └── PetRepository.java
├── services
│    ├── UserService.java
│    └── PetService.java
│   // and everything else in the project
└── MyApplication.java

위와 같이 패키지를 구성하면, 컴포넌트가 어느 계층에 속해있는지 명확하게 알 수 있습니다. 이러한 패키지 구성은 프로젝트의 크기가 충분히 작을 때 효과적입니다. 모듈의 위치를 정하는데 크게 신경 쓸 필요가 없기 때문입니다.

하지만 프로젝트의 크기가 커지고 모듈의 의존성등으로 어플리케이션이 복잡해 질 때, 컴포넌트(자바 클래스)의 위치를 찾기위해 많은 시간을 써야할지도 모릅니다.

Package By Feature

Package By Feature은 말 그대로 기능별로 패키지를 나누는 방식입니다. 같은 기능을 수행하기 위한 모듈을 같은 패키지에 위치시키는 방법으로 아래와 같이 패키지를 구성할 수 있습니다.

com.example
├── pet
│    ├── Pet.java
│    ├── PetController.java
│    ├── PetRepository.java
│    └── PetService.java
├── user
│    ├── User.java
│    ├── UserController.java
│    ├── UserRepository.java
│    └── UserService.java
│   // and everything else in the project
└── MyApplication.java

Package By Feature 방식으로 패키지를 구성하면 같은 목적의 기능을 수행하기 위한 모든 컴포넌트는 같은 패키지 안에 존재하게 됩니다.

물론 위와 같은 방식은 모듈의 위치를 한번 더 생각해야 하는 번거러움이 있지만, 프로젝트의 크기가 커지더라도 Package By Layer 방식에 비해 모듈의 위치를 쉽게 찾을 수 있고, 모듈간의 의존성도 패키지 단위로 나누어지기 때문에 유지/보수 면에서 장점을 가집니다.

기능별 패키지 개념은 한 패키지가 다른 패키지에 속한 항목을 절대 사용할 수 없다는 것을 의미하지 않습니다. 오히려 패키지별 기능은 패키지-비공개를 기본 범위로 적극적으로 선호하며, 필요한 경우에만 항목의 범위를 공개로 늘리는 것을 의미합니다.

정리

패키지를 나누는 방식은 많습니다. 간단한 프로젝트라면 Package By Layer 방식을 선택해도 좋고, 기능별로 명확하게 패키지를 나누고 싶다면 Package By Feature 방식이 더 나은 선택이 될 수 있습니다. 상황에 맞게 어떤 패키지 구성이 좋을지 고민해보고 적절한 패키지로 나누도록 고민하는게 중요한 것 같습니다.

출처
Package by feature, not layer
Folder-by-type or Folder-by-feature
Structuring Your Code

Etc 카테고리 내 다른 글 보러가기