Skip to main content

ADR-001: Modular Monolith over Microservices

Status: Proposed
Date: 2026-01-20
Context: WepNG Modernization Strategy

Decision​

We adopt a Modular Monolith architecture instead of decomposing into Microservices.

Context​

The WepNG_MVC platform is a legacy monolith with:

  • High Transaction Density: OrderOMGT operations touch 10+ entities in a single transaction.
  • Coupled Data Model: EITWEP.Model (840+ DbSets) is shared across all modules.
  • Limited Team Size: No dedicated platform/infrastructure team for Kubernetes/Service Mesh.

Considered Options​

Option A: Microservices​

  • Pros: Independent deployment, technology freedom.
  • Cons:
    • Distributed transactions nightmare (Saga complexity for OMGT).
    • Network latency for 10+ inter-service calls per request.
    • Operational overhead (monitoring, tracing, API gateways).

Option B: Modular Monolith​

  • Pros:
    • Same benefits of clean boundaries without network overhead.
    • Simpler debugging and deployment.
    • Can evolve to Microservices later if needed.
  • Cons: Requires discipline to maintain module boundaries.

Rationale​

"First make the change easy, then make the easy change."
— Kent Beck

Microservices are a solution to organizational scaling, not technical scaling. With a small team, the operational overhead outweighs the benefits. A Modular Monolith provides the same code separation while avoiding distributed system complexity.

Consequences​

  1. Code Separation: Enforce strict namespace boundaries (Wep.Core.Orders, Wep.Core.Crm).
  2. No Distributed Transactions: All OMGT logic stays in-process.
  3. Future Path: If a module needs independent scaling (e.g., Reporting), it can be extracted as a Microservice using the Strangler Fig pattern.

References​