모듈형 모노리스(Modular Monolith) 설계, 모듈 간 통신은 어떻게?

게시물에서는 모듈 간 통신을 위한 다양한 패턴을 제시하며, 각 방식의 장단점을 분석한다. 클라이언트/API 호출(Clients/APIs) 방식은 단순하지만, 동기 호출(Synchronous Call)로 인해 모듈 분리 시 성능 저하 및 트랜잭션(Transaction) 문제 발생 가능성이 있다. 애플리케이션 이벤트(Application Events) 방식은 간단하지만, 데이터베이스 공유(Shared Database)에 대한 암묵적 의존성을 갖는다. 반면, 아웃박스 패턴(Outbox Pattern)은 데이터 격리 아키텍처(Data Isolation Architecture)를 통해 모듈 간의 독립성을 확보하고, 백그라운드 데이터 동기화(Background Data Synchronization)는 모듈 간의 느슨한 결합을 유지하면서 데이터 일관성을 확보하는 데 중점을 둔다.

아웃박스 패턴(Outbox Pattern)은 데이터베이스 트랜잭션(Database Transaction) 내에서 이벤트를 저장하고, 별도의 프로세스를 통해 이벤트를 처리함으로써 모듈 간의 데이터 일관성을 보장한다. 특히, 데이터 격리 아키텍처(Data Isolation Architecture)를 통해 모듈 간의 결합도를 낮추고, 모듈의 독립성을 확보하는 데 기여한다. 게시물에서는 UserCreatedEvent와 같은 예시를 통해 아웃박스 패턴(Outbox Pattern)의 구현 방식을 설명하며, 메시지 브로커(Message Broker)를 활용한 확장성을 강조한다. 또한, 이벤트 소비(Event Consumption)의 멱등성(Idempotency)을 보장해야 함을 언급한다.

게시물은 모듈 간 통신 방식 선택에 앞서, 모듈 설계(Module Design)의 중요성을 강조한다. 모듈은 명확하게 정의된 기능(Functionality)을 담당해야 하며, 다른 모듈과의 의존성을 최소화해야 한다. 이상적으로는 각 모듈이 다른 모듈과 통신 없이 자체적으로 기능을 수행할 수 있도록 설계해야 한다. 이를 위해, 시스템의 기능과 동작을 식별하고, 모듈 간의 관계와 종속성을 파악하는 것이 중요하다. 또한, 모듈 간의 느슨한 결합(Loose Coupling)을 유지하고, 변경에 유연하게 대응할 수 있는 설계를 권장한다.

댓글에서는 아웃박스 패턴(Outbox Pattern)의 장점을 높이 평가하며, 데이터베이스 경계(Database Boundary)에서의 트랜잭션 일관성(Transactional Consistency)을 확보하는 데 유용하다고 언급한다. 또한, 모듈 독립성(Module Independence)과 운영상의 단순성(Operational Simplicity) 간의 트레이드오프(Trade-offs)를 강조하며, 백그라운드 동기화(Background Synchronization) 방식의 복잡성과 지연 시간(Latency) 증가를 지적한다. 반면, 클라이언트/API 호출 방식은 단순하지만, 동기적인 호출로 인해 모듈 간의 결합도가 높아진다는 점을 지적한다. 결론적으로, 모듈형 모노리스(Modular Monolith)의 핵심은 모듈 경계를 명확하게 정의하고, 필요에 따라 모듈을 분리할 수 있도록 설계하는 것이다.