[refactor] backend project 구조 정리

[rnjstjdgh]

기존 프로젝트 구조 설명

• 프로젝트가 잘 진행됨에 따라 backend 코드도 점점 늘어나고 있습니다.
• 개발을 진행할 수록 초기 구성했던 프로젝트 구조로는 부족하다고 느끼고 있습니다.
• 지금 프로젝트 구조는 아래와 같습니다.

  1.  common
  * configuration
      * spring project 를 위한 설정을 몰아둠
  * exception
      * 예외 처리 로직을 몰아둠
      * advice & error object &  공통 exception class
  * request
      * 공통으로 사용 될 요청 DTO가 위치
  * response
      *  공통으로 사용 될 응답 DTO가 위치
      *  공통 된 스팩의 응답을 주기 위한 응답 객체와 로직 위치
  * utils
      *  해당 프로젝트와 의존이 전혀 없는 포조들이 위치
      *  단순 유틸
  * validation
      * 요청 DTO 를 검증하기 위한 로직이 위치
  2.  domain
  * post
  * img
  * postComment
  3.  security
  * JWT
  * sign
  * user

• 공통 기능을 common 에 모두 몰아두기로 했습니다.
• domain package 에는 각 domain 별로 분리하여 코드를 작성하기로 했습니다.
  • 이때 common 의 로직을 언제든지 제 사용 할 수 있습니다.(그러려고 common 을 만들었습니다)
• security 는 조금 특별한 도메인이라고 판단 -> 별도로 분리했습니다.

리팩토링의 동기(현 상황에서 문제)

1. common 에 너무 많은 기능이 몰리고 있습니다.

• 그에 따라 모듈 의미의 명확성이 떨어지고 단순히 공통으로 쓰일 것 같은 코드를 일단 넣고 보는 상황이 되고 있습니다.
• 프로젝트를 진행할 수록 common 은 더욱 방대해 지고 명확성이 떨어질 것이고 이는 기존 코드 분석에 더 오랜 시간이 걸림을 의미합니다.
• 이는 생산성 저하로 이어질 것입니다.

2. 프로젝트가 커짐에 따라 단순히 domain & common 2개의 모듈 만으로는 완벽한 모듈 분리가 이루어 질 수 없습니다.

• 단일 책임을 갖도록 모듈을 조금 더 세분화 하고 세분화 된 모듈 간의 의존 관계를 명확하게 정의할 수 있다면 생산성이 증가할 것으로 기대 합니다.

[rnjstjdgh]

해야할 것

1. 모듈을 분리하기 위한 명확한 계층 및 책임 분리가 필요합니다.

• 책임
  • 그 의미에 맞게 역할 분배 & 캡슐화
• 계층( => 각 모듈 사이의 의존관계)
  • 역할 분배와 캡슐화가 잘 되어 있는 모듈 끼리의 의존 관계 원칙

2. 멀티 모듈 프로젝트로 구성할 계획이기 때문에 구성을 위한 사전 지식 학습이 필요합니다.

• maven 기반? gradle 기반? 어느 것이 멀티 모듈 프로젝트에서 더 유리한지?
• 등등.. 안 해본 거라 사전 지식 학습 필요

3. 멀티 모듈 프로젝트로 구성할 때 발생하는 프로젝트 관리 복잡성을 잘 따져봐야 합니다.

• 멀티 모듈로 가게 되면 프로젝트 설정이 모듈 수 만큼 분산 되기 때문에 관리의 복잡성이 증가할 수 있다.
  1. 의존성 설정(build.gradle or pom.xml)
     • 상위 모듈이 하위 모듈을 참조하는 계층이 발생할 수 있음
     • 복잡한 의존 관계가 발생할 시 필요한 의존성을 어느 프로젝트에서 설정할지 기준이 필요
  2. 프로퍼티 설정(application.properties or application.yml)
     • 의존 설정과 마찬가지로 어느 프로젝트에서 어떤 설정을 관리하는 것이 적절한지 고민 필요

       4. 기타 문제들

• 안 해본 것이기 때문에 하면서 문제가 발생할 수 있음

[rnjstjdgh]

참고 레퍼런스

• https://ahndy84.tistory.com/14?category=339592
• https://techblog.woowahan.com/2637

[rnjstjdgh]

2022-06-11 note

• 서비스가 비대해 지는 것을 방지하자
• 왜?
  • PostService 에서 글에 대한 CRUD 를 전부 한다고 가정해 보자
  • 그러면, 어느 한 사람이 글 페이징 api 를 수정하는 branch 를 만들고 어느 한 사람이 글 등록 api 를 수정하는 branch 를 만들게 되면 충돌이 발생하게 된다.
    • 같은 PostService 를 2개의 다른 branch 에서 수정하게 되기 때문
  • 따라서 이러한 상황에서는 글 작성을 위한 PostWriteService & 글 페이징을 위한 PostPagingService 2 개로 분리하는 것이 여러명이 작업할 때 충돌을 방지하고 병렬적으로 작업하기 좋다.
• 서비스를 잘게 쪼개면 클래스가 많아져 복잡한 것 처럼 보일 순 있으나 다수의 개발자가 동시 작업 하기에는 더 좋을 것으로 보임!