Sustainable AI Coding
with DDD & Modular Monoliths
AI coding assistants can generate entire features in seconds. Without architectural guardrails, they optimise for functionality — not maintainability. Here’s how to fix that.
AI coding assistants can generate entire features in seconds — but without architectural guardrails, they optimise for functionality, not maintainability. Domain-Driven Design and a Modular Monolith give you the boundaries AI needs to generate code that strengthens your architecture instead of quietly eroding it.
01The Hidden Cost of Moving Fast with AI
There is a moment every engineering team eventually hits. You have adopted AI-assisted development. Productivity is genuinely impressive — APIs, schemas, validation logic, tests, entire features generated in minutes. The backlog is moving. Stakeholders are happy.
Then, six months later, you open a pull request and something feels wrong.
Business logic has migrated into controllers. Modules that should be independent are reaching directly into each other’s database tables. The same validation rule exists in three different places. A seemingly isolated change breaks something in a completely unrelated part of the system.
The application still works. But the architecture has been silently degrading with every generated feature.
AI optimises for what you ask it to do — not for the architecture you intended to build. Without explicit boundaries, AI takes the path of least resistance. That path rarely respects domain ownership.
The problem is not code generation. The problem is unguided code generation. This is where Domain-Driven Design and Modular Monolith Architecture become essential — not as theoretical ideals, but as practical guardrails that give AI the boundaries it needs to generate sustainable software.
02The Rise of Vibe Coding — and Its Limits
Modern AI coding assistants have given rise to what many are calling Vibe Coding — a development style where engineers express intent in natural language and AI generates the implementation.
Tell an AI to create an Order Processing API with validation and persistence — within seconds, it may produce hundreds of lines of code. And it will likely work. But left unconstrained, AI-generated code introduces a predictable set of architectural issues:
Logic in the Wrong Place
Business rules end up inside controllers, repositories, or infrastructure — anywhere except the domain where they belong.
Tight Coupling
Modules that should be independent end up reaching directly into each other’s database tables and internal logic.
Duplicate Validation
The same rule exists in three different places. When it changes, one instance gets missed — and bugs ship to production.
Anemic Domain Models
Domain objects become data containers with no real behaviour — all logic leaks out into services, making the model useless as a guardrail.
Vibe Coding is not the problem. Vibe Coding without architecture is.
03Domain-Driven Design — Modelling Around Business Reality
Domain-Driven Design (DDD) organises systems around business capabilities rather than technical components. Most codebases are structured around technical layers. DDD structures them around the business instead.
controllers/
services/
repositories/
// No guidance to AI about ownership or responsibility.
// AI will mix concerns freely across these layers.OrderManagement/
InventoryManagement/
Billing/
CustomerManagement/
// The directory structure is itself an architectural instruction.
// AI knows exactly where new code belongs.DDD also introduces a shared vocabulary — called a Ubiquitous Language — that both the codebase and the team use consistently. When a developer asks AI to “submit an order,” DDD ensures that concept maps to a specific, well-defined operation in a specific, well-defined place — not a vague action that could mean six different things to six different layers.
04Bounded Contexts — The First Guardrail
A Bounded Context is a clearly defined area of the system with explicit ownership over its business rules, domain model, use cases, and data. It is a hard boundary that prevents different business capabilities from bleeding into one another.
| Bounded Context | Owns |
|---|---|
| Order Management | Order lifecycle, submission rules, fulfilment status |
| Inventory | Stock levels, reservation logic, availability checks |
| Billing | Payment processing, invoicing, refund rules |
| Customer | Profile data, preferences, identity |
| Shipping | Carrier logic, delivery tracking, address validation |
Without bounded contexts, AI generates code that mixes these concerns freely — an Order Service that directly queries Inventory tables, a Billing module that reaches into Customer data, a controller that handles logic from three domains. With bounded contexts, you instruct AI to operate within a defined boundary. The scope is explicit. The ownership is clear.
05Modular Monolith — The Right Starting Point
Many teams assume adopting DDD means adopting microservices. This assumption regularly leads to unnecessary complexity and operational overhead. The reality: DDD is about business boundaries, not deployment boundaries.
A Modular Monolith implements DDD principles inside a single deployable application — giving you strong business boundaries without distributed-systems complexity.
OrderManagement/
Domain/ <- Business rules, aggregates, domain events
Application/ <- Use cases, orchestration, application services
Infrastructure/ <- Persistence, external integrations
InventoryManagement/
Domain/
Application/
Infrastructure/
BillingManagement/
Domain/
Application/
Infrastructure/| Operational Benefits | Architectural Benefits |
|---|---|
| Single deployment pipeline | Strong business boundary enforcement |
| Simpler local debugging | Each module independently evolvable |
| Lower infrastructure cost | Clear ownership and responsibility |
| Faster onboarding | Pathways to microservices when genuinely needed |
Design as if modules could become microservices. Deploy as a monolith until business needs justify distribution. Avoid premature complexity while preserving future options.
06Guardrail Files — Your Architectural Constitution
The most practical implementation of guardrails is a set of structured files that travel with the codebase and are loaded as context when working with AI tools such as Cursor, Claude Code, or GitHub Copilot.
.architecture.md <- Overall system design decisions
.ddd-rules.md <- DDD-specific constraints
.coding-standards.md <- Layer dependencies, naming, patterns
.ai-guardrails.md <- Explicit rules for AI-assisted development# Architecture Rules
## Domain Layer
Business logic must exist only in:
- Entities
- Aggregates
- Domain Services
Forbidden locations for business logic:
- Controllers
- Repositories
- Infrastructure components
## Module Boundaries
Modules cannot access each other's database tables directly.
Cross-module communication must use:
- Domain Events (async state propagation)
- Application Contracts (synchronous queries)
## Layer Dependencies
Allowed: API -> Application -> Domain
Forbidden: Domain -> Infrastructure | Domain -> APIThese files serve a dual purpose: documentation for human developers and active constraints for AI assistants. When an AI tool has these files in context, it generates code within the defined boundaries rather than inventing its own.
07Aggregates — Enforcing Business Invariants
One of the most important guardrails in DDD is the Aggregate: a cluster of domain objects treated as a single unit that enforces business rules and prevents invalid state transitions.
order.setStatus("Submitted");
order.setSubmittedAt(LocalDateTime.now());
// Nothing stops this from being called at the wrong time,
// with missing data, or from violating business rules.order.submit(submittedBy, currentInventory);
// The aggregate validates:
// - Required fields are present
// - Order is in a valid state to be submitted
// - Inventory is available
// - Business rules are satisfied
// Only then does the state change.When AI is instructed to generate business operations through aggregates rather than direct state manipulation, a large class of architectural violations simply cannot occur. The aggregate is both the boundary and the enforcer.
08Better Prompts — The Simplest Improvement
Most developers write AI prompts like this:
"Create an Order Service."
// AI has no guidance on boundaries, layers, or responsibilities.
// Output is functional. Architecturally ambiguous."Create an Order Aggregate within the OrderManagement bounded context.
Business rules must reside in the Domain layer.
Repositories belong to Infrastructure and persist aggregates only.
Application Services may orchestrate workflows but must not contain
business logic. Use Domain Events for cross-module communication.
Follow the architecture defined in .ai-guardrails.md."
the generated output adheres to the intended architectural design.
09How to Start — Five Practical Steps
Architecture and AI are not in tension. But architecture has to come first. Here is where to begin:
- 1Create your .ai-guardrails.md file Capture your three most important architectural rules. Load this file as context on your next AI-assisted feature. Observe the difference in what it generates.
- 2Map your Bounded Contexts Identify your system’s core business capabilities. Each becomes a bounded context with explicit ownership of its rules and data. Document these in .ddd-rules.md.
- 3Restructure into a Modular Monolith Reorganise your codebase by business capability. Each module gets Domain, Application, and Infrastructure sub-layers. The structure becomes an architectural instruction AI respects.
- 4Implement Aggregates for business rules Replace direct state manipulation with aggregate methods. Instruct AI to generate all business operations through aggregates. Bypass routes become structurally impossible.
- 5Write DDD-oriented prompts Specify bounded context, layer, responsibilities, and guardrail file reference in every AI prompt. The clearer the specification in the prompt, the stronger the architecture is.
10The Real Question for Engineering Leaders
The industry has moved past debating whether AI will generate code. It does. The question engineering leaders need to answer now is: what architectural principles will guide the code AI generates?
Organisations that adopt AI coding tools without guardrails will accelerate — but they will accelerate in the wrong direction, compounding technical debt faster than any team in history could manage manually.
Organisations that combine AI-assisted development with Domain-Driven Design, a Modular Monolith structure, and well-defined guardrails achieve something qualitatively different: sustainable engineering velocity — the ability to ship fast today without undermining the ability to ship fast next year.
The architectural decisions you make during AI-assisted development compound. Boundaries established early stay cheap to enforce. As we explored in our AI Engineering Mindset post, understanding the problem deeply before generating code is what separates teams that scale from teams that stall.
In the age of Vibe Coding, architecture is not optional. It is the difference between accelerating innovation and accelerating technical debt.
Frequently Asked Questions
Ready to Build AI into Your Architecture the Right Way?
Sails Software helps enterprise engineering teams implement DDD guardrails and Modular Monolith structure — so AI generates code that strengthens your architecture, not one that slowly dismantles it.
Talk to Our Team