Phase 4레슨 19

Modular Monolith

Module Boundary, Shared Kernel, Anti-Corruption Layer — Monolith 내부의 마이크로서비스

💡ELI5·

아파트와 Modular Monolith

┌─────────────────────────────────┐
│         Monolith (단일 배포)      │
│  ┌────────┐ ┌────────┐ ┌────────┐│
│  │ Order  │ │Payment │ │Shipping││
│  │Module  │ │Module  │ │Module  ││
│  │공개API │→│공개API │→│공개API ││
│  │private │  │private │  │private │  │
│  └────────┘ └────────┘ └────────┘│
│  각 모듈: 독립 DB 스키마, 독립 도메인│
└─────────────────────────────────┘

💡 비유 — 아파트 = Modular Monolith. 한 건물(배포) 안에 여러 호(모듈). 각 호는 독립된 생활(도메인)을 하지만, 공용 복도(공개 API)로만 소통. 다른 호의 냉장고(DB)에 직접 들어가지 않는다. 나중에 필요하면 해당 호만 별동(마이크로서비스)으로 뺄 수 있다.

🔬Deep Dive·

모듈 경계 원칙

원칙	설명	위반 예
공개/비공개 분리	모듈은 공개 API만 노출, 내부는 비공개	다른 모듈의 내부 클래스 직접 import
DB 독립	각 모듈이 자신의 테이블만 접근	Order 모듈이 Payment 테이블 직접 조회
이벤트 통신	모듈 간 비동기는 이벤트, 동기는 공개 API	모듈 간 직접 함수 호출 (공개 API 아님)
공유 최소화	Shared Kernel 최소화	공통 User 모델이 모든 모듈에 의존

🔬Deep Dive·

Microservices로의 점진적 분리

1단계: Modular Monolith (모든 모듈이 한 프로세스)
  Order ↔ Payment ↔ Shipping (공개 API 호출)

2단계: Shipping 모듈 분리 (트래픽 많음, 독립 확장 필요)
  Order → HTTP/Event → Shipping Service
  Order ↔ Payment (여전히 같은 프로세스)

3단계: Payment 분리 (결제 보안/컴플라이언스 분리 필요)
  Order → HTTP/Event → Payment Service
  Order → HTTP/Event → Shipping Service

모듈 경계가 이미 명확하므로, 분리 시 공개 API를 HTTP/gRPC로 바꾸기만 하면 된다. 내부 도메인 로직은 변경 없음. 이것이 Modular Monolith가 '징검다리'인 이유.

⚖️Trade-off·

Modular Monolith vs Microservices

구분	Modular Monolith	Microservices
배포	단일	개별
통신	함수 호출 (빠름)	네트워크 (지연)
일관성	같은 트랜잭션 가능	분산 트랜잭션 필요
확장	전체 확장	개별 확장
복잡성	중간	높음
적합 시점	초기~중기, 경계 실험	경계 확정, 개별 확장 필요

❓ 체크포인트 질문

1.Modular Monolith가 일반 Monolith와 다른 점은?
2.Shared Kernel이 무엇이고 언제 사용하는가?
3.Anti-Corruption Layer(ACL)의 역할은?
4.Modular Monolith에서 모듈 간 직접 DB 접근이 왜 문제인가?
5.Modular Monolith가 Microservices보다 나은 상황은?

← 이전

Hexagonal Architecture (Ports & Adapters)

Domain-Driven Design (DDD)