모듈형 모놀리스(Modular Monolith)는 단일 배포 단위를 유지하면서 내부를 느슨하게 결합된 모듈로 구성하는 아키텍처다. 마이크로서비스의 네트워크 복잡성 없이 모듈화의 장점을 취한다.
마이크로서비스 vs 모듈형 모놀리스
| 비교 | 모듈형 모놀리스 | 마이크로서비스 |
|---|
| 배포 | 단일 | 독립 서비스별 |
| 통신 | 인프로세스(빠름) | 네트워크(느림) |
| 트랜잭션 | ACID 가능 | 분산 트랜잭션 필요 |
| 복잡도 | 낮음 | 높음 |
| 팀 규모 | 소~중 | 중~대 |
| 확장 | 전체 스케일 | 서비스별 독립 |
패키지 구조
src/
├── orders/ # 주문 모듈
│ ├── api/ # HTTP 핸들러
│ ├── domain/ # 엔티티, 도메인 로직
│ ├── application/ # 유즈케이스
│ └── infra/ # DB, 외부 연동
├── payments/ # 결제 모듈
│ ├── api/
│ ├── domain/
│ └── ...
├── inventory/ # 재고 모듈
└── shared/ # 공통 유틸리티
규칙:
모듈 간 직접 import 금지
공개 API(인터페이스)를 통해서만 통신
모듈 간 통신 (이벤트 기반)
java
// 주문 모듈이 이벤트 발행 (인프라 없이 인메모리)
@Service
public class OrderService {
@Autowired
private ApplicationEventPublisher eventPublisher;
public void createOrder(CreateOrderCommand cmd) {
Order order = orderRepository.save(new Order(cmd));
eventPublisher.publishEvent(new OrderCreatedEvent(order));
}
}
// 재고 모듈이 이벤트 수신
@Component
public class InventoryEventHandler {
@EventListener
public void onOrderCreated(OrderCreatedEvent event) {
inventoryService.reserve(event.getProductId());
}
}
마이크로서비스로의 진화
모듈형 모놀리스 → 마이크로서비스 전환이 쉬움:
1. 모듈 경계 = 서비스 경계
2. 인메모리 이벤트 → Kafka 이벤트로 교체
3. 인터페이스 → HTTP/gRPC API로 교체
스트랭글러 피그 패턴과 결합:
핵심 모듈만 먼저 분리
나머지는 모놀리스에 유지
관련 개념
