If I were starting a new enterprise backend in 2026 with a complex domain and multiple bounded contexts, my default would still be:
Build a modular monolith first, with strong module boundaries (Spring Modulith if you're on Spring), and evolve only the modules that actually need to become services.
That's become an increasingly common recommendation because the industry has spent years learning that distributed systems introduce substantial operational complexity that many teams don't actually need on day one.
Why I'd start with a modular monolith
A modular monolith lets you solve the hardest problem first:
Designing the domain correctly.
If the bounded contexts are wrong, splitting them into microservices simply makes those mistakes harder to change.
With Spring Modulith you can make module boundaries explicit:
- independent packages/modules
- published application events
- dependency verification
- architecture tests
- module documentation
- clear APIs between modules
Those constraints prevent the "big ball of mud" that people worry about with monoliths.
The biggest advantage isn't deployment
People often compare:
Monolith:
Microservices:
But in practice, the real difference is coordination cost.
Every service introduces:
- network failures
- versioning
- retries
- timeouts
- distributed tracing
- eventual consistency
- message ordering
- service ownership
- infrastructure
- observability
- deployment pipelines
A modular monolith has almost none of that.
Performance is usually better
Inside a modular monolith:
OrderService
|
V
InventoryService
is simply
Java method call
instead of
HTTP/gRPC
serialization
network
deserialization
authentication
timeouts
That matters more than people often realize.
Refactoring is dramatically easier
Suppose six months in you discover:
- Payments and Billing actually belong together.
- Customer should be split into CRM and Identity.
- Pricing logic belongs elsewhere.
Inside a monolith, that's mostly refactoring.
Across microservices, it's potentially months of migration work.
When I would choose microservices immediately
There are situations where I'd skip the monolith.
1. Independent engineering organizations
If you already know:
- 20+ teams
- independent release schedules
- independent ownership
microservices make more sense.
2. Very different scaling profiles
Example:
Search
1000 RPS
Orders
50 RPS
Billing
5 RPS
Scaling them independently can justify separate services.
3. Different technology requirements
Example:
- Java for transactions
- Python for ML
- Rust for high-performance processing
Separate services are a natural fit.
4. Regulatory isolation
Sometimes security or compliance requires strict separation of systems and data.
DDD works with both
People sometimes equate:
Bounded Context
=
Microservice
That's not required.
A bounded context can simply be a module.
For example:
Application
├── identity
├── customer
├── catalog
├── pricing
├── ordering
├── inventory
├── shipping
├── billing
└── notifications
Each module has:
- its own entities
- repositories
- services
- events
- API
That's already good Domain-Driven Design.
Spring Modulith's sweet spot
Spring Modulith is especially useful because it encourages:
- application events instead of direct coupling
- module verification
- module documentation
- explicit dependencies
- testing modules independently
For example:
Ordering
|
| publishes
V
OrderPlacedEvent
Inventory
Billing
Notifications
Initially that's all in-process.
If one day Inventory needs to become its own service, that event can later be delivered over Kafka or another message broker with much less change to the surrounding code.
When to extract a service
I generally wouldn't extract because "microservices are the architecture."
I'd extract because of a concrete need, such as:
- independent scaling
- separate deployments
- ownership by a different team
- different availability requirements
- different database needs
- excessive deployment coordination
- a module becoming a bottleneck for development
That's a much stronger signal than extracting early based on anticipated future needs.
A practical architecture
For a greenfield enterprise project, I'd likely organize it like this:
Spring Boot
├── modulith
│
├── identity
├── customer
├── catalog
├── pricing
├── ordering
├── inventory
├── shipping
├── billing
├── reporting
└── notifications
With each module containing its own:
- domain
- application services
- persistence
- API
- events
- tests
Cross-module communication would happen primarily through published events or well-defined interfaces, keeping dependencies intentional and minimizing tight coupling.
My 2026 rule of thumb
For most organizations (roughly up to 10–15 engineering teams), I'd choose a well-structured modular monolith over microservices unless there are clear, current requirements that justify distribution.
The architecture I'd optimize for is one where the domain is modular, but deployment remains flexible. If modules have clean boundaries and communicate through explicit contracts, you retain the option to extract a service later. Going in the opposite direction—merging a fragmented microservice architecture back into something cohesive—is typically much more difficult.
