- Domain-Driven Design
- Enterprise modular monolith practices
- Modern distributed architecture patterns
- "Do not join tables across modular boundaries" architectural principle
Many modular monoliths are only modular at code level.
The persistence layer remains fully coupled through:
- cross-domain joins
- shared DbContexts
- direct entity access
- shared repositories
- cross-module foreign keys
This creates:
- hidden coupling
- low autonomy
- difficult evolution
- AI reasoning complexity
- poor scalability
Recommended.
Each bounded context must:
- own its persistence
- own its rules
- expose contracts
- avoid direct persistence access from external domains
- contracts
- APIs
- events
- projections
- read models
- query services
- cross-domain joins
- shared repositories
- direct DbSet access across domains
- global DbContexts
- modular autonomy
- independent evolution
- clearer ownership
- better AI-assisted engineering
- safer decomposition into distributed systems
- increased integration complexity
- possible data duplication
- eventual consistency scenarios
- more explicit contracts
High.
AI agents reason significantly better when domains are isolated conceptually and technically.
- ADR: Bounded Context Isolation
- ADR: No Cross-Domain Database Joins
- ADR: Contract First Integration