[Spring Boot] 멀티 모듈 참고 영상 및 정리

🐣 실전! 멀티 모듈 프로젝트 구조와 설계 | 인프콘 2022

• "왜" 멀티 모듈 프로젝트 구조가 중요할까?
  1. 잘못 구성시 추후 변경이 어려움
  2. 프로젝트 초기에 이루어져야 하는 일련의 설계 과정
  3. 개발 생산성에 막대한 영향
• "무엇"을 기준으로 멀티 모듈 프로젝트 구조를 나누어야 하는가?
  • 경계 안에서 의미를 가질 수 있는 그룹을 정의하고 나누는 것이 가장 중요 (Bounded Context)
  • 역할, 책임, 협력 관계가 올바른지 다시 생각
• "어떻게" 실전 모듈 프로젝트를 구현해야 하는가?
  • 프로젝트가 커지고 있다면 다시 경계를 나누고 그 기준으로 소스 저장소를 분리
  • Infra(외부) 라이브러리에는 Data 관련 구현 지향
  • 서비스 구현은 각자 역할에 맞게 각각 구현될 수 있음(공통으로 한쪽에 구현 X)
  • 시스템 레벨 구현이 실제 서비스 애플리케이션과 밀접하게 연관되지 않도록 격리하거나 전환

• 멀티 모듈 프로젝트란?
  • 기술 베이스 기반 구조
• 중복 제거를 이유로 Core와 Common에 공통 모듈을 구현하면 코드가 증가했을 때 모듈 간 종속성 문제 발생
• core와 common 삭제
  • 코드 중복이 갖고 있는 위험보다 중복을 허용하지 않았을 때의 잠재적인 위험성이 더 큰 문제
    
• DDD(: Domain-Driven Design) Bounded Context
  • 특정한 컨텍스트 문맥 하에서 완전한 의미를 갖는 경계의 기준을 나누어야 함
• ex) 멀티모듈 그룹이라는 4개의 그룹을 정의해서 사용
  1. Boot(Server)
     • batch, admin, api
     • 코드의 변화가 잦은 모듈
  2. Data(Domain)
     • meta, user, chart
     • 서버 모듈과 밀접한 관계
  3. Infra(연동모듈)
     • and, vod, photo, billing
     • 유관 부서 및 업체 연결을 위한 그룹
     • 구현 시 변화는 적지만, 추후 버전 업 시 코드에 큰 변화
  4. Cloud(System)
     • config, gateway, discovery
     • 서버 관리를 위한 그룹(컨테이너 환경, 트래픽 제어를 위한 시스템 관리 그룹)
     • 변화 적음
• 빌드 도구(gradle)에서 그룹 폴더명을 기준으로 정의할 기술들을 일괄적으로 선언 가능
• 모듈을 나누고 모듈 특성에 맞게 더 분리하면 빌드 시간이 감소하고 프로젝트 경계가 명확해져 인터페이스 분리가 명확해짐
• 일반적인 Spring 프로젝트의 경우 컨트롤러 → 서비스 → 레포지토리의 순서인데 "서비스"는 어느 모듈에 위치해야 할까?
  • Boot와 Data 양쪽에 모두 존재해 Boot 서비스에서 Event 발생 시 Data 서비스가 저장하는 방식
  • 이처럼 서비스 구현체는 프로젝트 별로 역할에 맞도록 각각 구현할 수 있음
  • • Data 프로젝트에서는 Survlet Request와 같은 웹 서버에 의존적인 객체를 전달하지 않아야 됨 (R&R 위반)
      Servlet Request 객체가 말단 Layer까지 내려가는 경우 역할과 책임, 협력관계에 올바르지 않음
      Data 모듈은 Batch, 웹 어플리케이션, 원타임 어플리케이션에도 사용할 수 있어(모두가 웹 서버 기반으로 동작하지 않을 수 있기 때문) 쿠키, 세션, 웹 등 의존적인 클래스들 전달 X)
    • Data 프로젝트에 웹 개발 의존성이 강하게 주입되면, 테스트 코드 작성 시 웹 서버 관련 라이브러리가 모두 필요해져 Mock 객체를 선언해야 되는 등 모듈을 나눈 의미가 상실됨Boot와 Meta 프로젝트 간에는 상호 간 규칙 필요

---

🐣 우리는 이렇게 모듈을 나눴어요: 멀티 모듈을 설계하는 또 다른 관점 | 인프콘 2023

[Server] 멀티 모듈을 설계하는 관점과 고려사항 with Spring & Gradle

GitHub - MangKyu/multimodule-sample

• "어떤" 모듈부터 만들어야 하는가?
  
  • 변경이 거의 없는 공통 코드 → 수준에 따라 분리 → 기능별 분리
    
  • SRP를 위반하지 않게
• "어떻게" 모듈 프로젝트를 구현해야 하는가?
  • 유스케이스(비즈니스 로직)는 공통 모듈에서 제거
  • 자동 빈 스캔 방식 사용 X
  • 엄격하게 공통 모듈 관리

• Common 모듈
  • 의존성 관리, Entity, Application, Service 계층 코드 관리
  • 직업 수행 및 히스토리 파악 어려움
    • Common을 수정하고 배포해야 다른 프로젝트들의 작업이 가능함
    • 하나의 히스토리가 여러 히스토리에 퍼져있어 관리가 어려움
  • 서비스 분리 어려움
  • SRP를 위반하기 쉬움
    • SRP = 변경의 이유가 하나여야 한다 = 액터가 하나여야 한다
  • Common의 변경이 어려움
    • Common 수정 시 모든 프로젝트에 영향
    • 의존성 관리까지 Common에서 한다면 다른 프로젝트의 build나 실행에까지 영향
    • dead 코드가 늘어나고 자연스럽게 legacy 코드 늘어남
  • Common에 배포 의존성이 있음
    • 효율적인 개발을 위해서는 배포 독립성과 개발 독립성이 확보되어야 하지만, 현재 구조라면 배포를 위해서 라이브러리를 먼저 배포해야만 함
• 개발할 때 인식의 전환
  • 개발 시작을 테이블 설계부터 했을 때 테이블 구조가 맞지 않아 테이블을 엎은 적이 있지 않은가?
    → 테이블 설계부터 하는 것이 맞을까?
  • 애플리케이션을 만들 때 "프레임워크에 AOP를 써야지, Cache는 Redis DB는 Mysql을 써야지" 등은 가장 중요한 것은 아님
    → 이런 것들은 세부 사항에 가까움
  • 가장 중요한 것은 핵심 비즈니스 로직과 유스케이스
    • 핵심 비즈니스 로직: 시스템의 유/무와 상관없이 존재하는 비즈니스 로직
      이런 로직들은 보통 데이터를 필요로 함. 이를 핵심 비즈니스 데이터라고 부름
      이 둘을 묶어서 도메인 엔티티 혹은 도메인 객체라고 부를 수 있음
    • 유스케이스: 시스템이 있어야 유효한 비즈니스 로직
      
• 어떤 모듈부터 만들어야 할까?
  
  • 가장 단순한 것부터
    1. global-utils(공통 코드)
       • 변경이 거의 없는 모듈(도메인에 무관한 코드는 거의 없음)
       • 시스템에 독립적인 공통 코드 ex) StringUtils
       • 시스템에 종속적인 공통 코드 ex) ProductCode
         • 도메인
         • 인프라
    2. appstore-core
       • 공통 모듈
       • 수준(Level: 입력과 출력까지의 거리)에 따라 분리
         - 입력: HTTP, 웹소켓 등
         - 출력: 캐시, 데이터베이스 등
       • 고수준(Domain)
         - 입력과 출력으로부터 거리가 먼 것
         - 비즈니스 요구사항에 의해 수시로 변경됨
       • 저수준(Infra)
         - 입력과 출력으로부터 가까운 것
         - 새로운 환경 또는 보안 취약점 등에 의해 특정 시점에 변경됨
         - 회사 공공망 추가 운영, DB Migration 등의 작업을 할 때 저수준 변경됨
       • Domain과 Infra 영역은 다른 수준 = 다른 변경 속도
  • 그 후로는 기능별로 의존성을 나눔
    기능별로 필요한 의존성과 코드 변경의 주기가 다름
    ex. api 제공: RestDocs 등, admin: thymeleaf 등, 배치 작업: Spring Batch 등
    1. appstore-batch
    2. appstore-admin
    3. appstore-apis
       • 서로 다른 Actor를 기반으로 모듈 나눔(SRP 위반하지 않도록 하기 위함)
         • creater: 앱을 만드는 사람들을 위한 API
         • enduser: 앱을 설치/사용하는 사람들을 위한 API
         • 기타 등
• 유스케이스가 공통 모듈에 존재하면 side effect 생김
  • SRP를 위반하기 때문
    (모든 Actor들이 사용할 수 있는 공통 모듈에 비즈니스 로직인 유스케이스가 있어서)
  • 유스케이스를 공통 모듈에서 제거했을 때 중복인 코드들이 보인다면 우발적 중복(Actor가 다르지만 중복처럼 보이는 코드) 의심
  • 우발적 중복이 아닌 진짜 중복인 코드라면, 중복을 허용하거나 공통 API를 만들어서 처리
  • 절대 코드 공유 X
• 자동 빈 스캔 방식 사용하지 않기
  • ComponentScan을 통해 빈을 자동 등록하면 사용되지 않는 모든 서버에서도 해당 빈 설정이 강제됨
    데이터베이스 리소스 낭비
  • @Enable 어노테이션으로 동적 구성 요소 선택을 통해 인프라 구성 제어 가능
• 엄격하게 공통 모듈 관리
  • 컴파일 제한: 언어(package-private 가시성 등) 또는 빌드 도구를 활용한 컴파일 제한
  • 빌드 제한: 빌드 도구 또는 ArchUnit 라이브러리 등을 활용한 빌드 제한
  • 머지 제한: Merge를 위한 Approve 수 제한 등
  • 기타: Github Actions를 이용한 변경 모듈 라벨링 등

---

🐣 [우아한테크세미나] 190829 우아한멀티모듈 by 우아한형제들 권용근님

멀티모듈 설계 이야기 with Spring, Gradle | 우아한형제들 기술블로그

1. 독립 모듈 계층(independently available)
   • 시스템과 무관하게 어디서나 사용가능한 라이브러리 성격의 모듈
   • 자체로서 독립적인 역할을 가지며 프로젝트 내에 의존 관계를 두지 않음
2. 공통 모듈 계층(system core)
   • 하나의 프로젝트에서 모든 모듈에서 사용될 수밖에 없는
   • Type, Util 등을 정의(많이 쓰이는 Type 성격의 DTO 혹은 기본적인 Util Class)
   • 가능하면 사용하지 않음
3. 도메인 모듈 계층(system domain)
   • 내부 모듈 계층과 비슷한 성격이지만, 저장소와 밀접한 중심 도메인을 다루는 계층
   • 서비스 비즈니스를 모름
   • 하나의 모듈은 최대 하나의 Infrastructure에 대한 책임만을 가짐
   • 도메인 모듈을 조합한 더 큰 단위의 도메인 모듈 존재 가능
   • 단일 인프라스트럭처 사용 모듈
     • Domain
       - Java 클래스로 표현된 도메인 Class들
     • Repository
       - 도메인 CRUD
       - 시스템에서 가장 보호받아야 하고 견고해야 함
       - 구현하려는 기능이 중심 역할이면 도메인 모듈, 아니면 사용을 하는 측에서 작성
     • Service
       - 도메인의 비즈니스를 책임짐
       - 도메인의 비즈니스가 단순하다면 생성 X
       - 트랜잭션의 단위 정의, 요청 데이터 검증, 이벤트 발생 등 도메인의 비즈니스 작성
4. 내부 모듈 계층(in system available)
   • 저장소, 도메인 외 시스템에서 필요한 모듈들
   • 애플리케이션, 도메인 비즈니스를 모름
   • 전체적인 시스템 서포트를 위한 기능 모듈
   • 프로젝트의 어떠한 애플리케이션에서도 독립 사용 가능한 모듈이 위치되어야 하므로 도메인 계층 의존 X
   • web, client, event-publisher 등 처리
5. 애플리케이션 모듈 계층(application)
   • batch, worker, internal-api, external-api 등의 모듈 존재
   • 사용성에 따라 다른 모든 계층에 의존성 추가하여 사용 가능