[프로젝트 개발 회의 회고록] / 모듈화

4F 방법

• 사실(Fact): 일어난 일에 대한 객관적인 기록
• 느낌(Feeling): 상황에 대한 감정적인 반응
• 교훈(Finding): 경험을 통해 배울 수 있었던 것
• 향후 행동(Future action): 향후 할 수 있는 개선된 행동

Fact

프로젝트 기획을 마치고 개발을 위해 패키지 구성을 어떻게 할지 정하는 중
계층형과 도메인형중 어느것을 선택할지 이야기가 나왔다.

1️⃣ 계층형 패키지 구조 (Layered Package Structure)

기능별 역할(계층)로 패키지를 구분하는 방식

📂 구조 예시

com.example.project
 ┣ 📂 controller
 ┣ 📂 service
 ┣ 📂 repository
 ┣ 📂 dto
 ┣ 📂 config
 ┗ 📂 domain (또는 entity)

📌 구조 설명

controller: 클라이언트 요청을 처리하는 API 엔드포인트와 관련된 클래스
service: 비즈니스 로직을 담당하는 클래스
repository: 데이터베이스와 직접 상호작용하는 클래스 (JPA의 Repository 인터페이스)
dto: 클라이언트와 데이터를 주고받기 위한 데이터 전송 객체
domain (entity): 데이터베이스와 매핑되는 엔티티 클래스 (JPA Entity)
config: 보안, CORS, OAuth2 등 설정 파일

📚 장점

명확한 계층 구분: 각 계층의 역할이 명확하므로, 코드를 처음 접하는 개발자도 쉽게 이해할 수 있습니다.
재사용성 향상: Controller, Service, Repository를 재사용하기 쉽습니다.
확장성: 계층별로 기능이 추가될 때 쉽게 확장할 수 있습니다.

🔥 단점

파일 간 의존 관계가 복잡: 관련 도메인에 속하는 로직이 여러 패키지에 흩어져 있어 파일 이동이 빈번합니다.
도메인 간 비즈니스 로직 결합이 어려움: 여러 도메인에 걸친 복잡한 비즈니스 로직을 처리하기 어렵습니다.
변경에 취약: 특정 도메인에 변경이 필요할 경우, 여러 패키지(controller, service, repository)를 수정해야 합니다.

2️⃣ 도메인형 패키지 구조 (Domain Package Structure)

도메인 단위로 패키지를 구분하는 방식

📂 구조 예시

com.example.project
 ┣ 📂 user
 ┃   ┣ 📂 controller
 ┃   ┣ 📂 service
 ┃   ┣ 📂 repository
 ┃   ┣ 📂 dto
 ┃   ┗ 📂 entity
 ┣ 📂 product
 ┃   ┣ 📂 controller
 ┃   ┣ 📂 service
 ┃   ┣ 📂 repository
 ┃   ┣ 📂 dto
 ┃   ┗ 📂 entity
 ┗ 📂 config

📌 구조 설명

user 도메인: 사용자와 관련된 기능(로그인, 회원가입, 정보수정 등)과 관련된 모든 클래스가 모여있습니다.
product 도메인: 제품과 관련된 기능(상품 조회, 상품 등록, 상품 수정 등)과 관련된 모든 클래스가 모여있습니다.
공통 패키지 (config, global 등): 보안, CORS, 예외 처리 등 공통 설정 파일이 위치합니다.

📚 장점

높은 응집도: 도메인 단위로 모듈화되기 때문에 관련 클래스가 한 곳에 모여 있습니다.
변경에 유연: 특정 도메인의 기능 변경이 필요할 때 해당 도메인 패키지만 수정하면 됩니다.
비즈니스 로직 중심: 비즈니스 요구사항에 맞는 구조로 설계할 수 있습니다.
모듈화 용이: 하나의 도메인에 모든 요소가 모여 있으므로 독립적인 모듈로 만들기 쉽습니다.

🔥 단점

중복 코드 발생: 여러 도메인에 공통적으로 사용되는 유틸리티, 예외처리, 공통 서비스 로직이 중복될 가능성이 있습니다.
도메인 간 관계 파악이 어려움: 도메인 간 연관 관계를 파악하기 어려울 수 있습니다.
초기 설계가 중요: 도메인 단위로 나누는 과정에서 잘못된 도메인 설계가 프로젝트에 큰 영향을 미칠 수 있습니다.

🔥 어떤 구조를 선택해야 할까?

1️⃣ 단순한 CRUD 프로젝트:
계층형 구조 추천
규모가 작은 프로젝트는 계층형 구조가 더 단순하고 직관적입니다.
2️⃣ 대규모 프로젝트, 도메인이 명확한 경우:
도메인형 구조 추천
여러 개발자가 협업할 때, 도메인 단위로 업무를 나누고 각 도메인에 맞는 코드만 작업하면 되므로 협업에 유리합니다.
3️⃣ 마이크로서비스 아키텍처 (MSA) 프로젝트:
도메인형 구조 필수
MSA는 도메인 단위로 서비스를 나누기 때문에, 도메인 중심으로 코드를 관리하는 것이 적합합니다.

---

Feeling

지금까지 해왔던 프로젝트들은 전부 계층형 패키지 구조를 사용해왔어서 도메인형에 대한 정보가 많이 없었지만 최근 참여하고 있는 교육에서 강사님께서 도메인형으로 프로젝트를 진행하고 계셔서 그 구조를 참고하였다.

우리 프로젝트의 경우 기능이 많아서 대규모 프로젝트에 속하는 편이고, 도메인이 명확하며 6명이서 협업하기 때문에 도메인 단위로 업무를 나누고 각 도메인에 맞는 코드를 작업하는 것이 좋겠다 생각하여 도메인형 구조를 선택하게 되었다.

---

Finding

우리 프로젝트의 경우 기능이 많다보니, 어디까지 나눠야 하는지 기준이 명확하지 않아 어려움을 겪었었다. 기능 간의 관계를 생각해보며 여러 곳에 쓰이는 기능이라면 코드 중복을 피하기 위해서 따로 모듈로 빼는 것이 좋다고 판단하였다.
팀원들과 회의를 통해 기능 간의 관계성을 생각해볼 수 있는 시간이었다.

---

Future action

앞으로 프로젝트를 시작할 때는 내가 진행하는 프로젝트가 어떤 특징을 가지고 있는지 파악한 후 어떤 구조를 사용하면 좋을 지 먼저 생각하는 습관을 가져야겠다.