Domain Driven Agent Design
Why your AI agents need domain awareness
The Corpse, the Agent, the Map
The board loved the demo. The agent was smooth. It answered questions, pulled up charts, even cracked a joke. The consultants left the room glowing.
Three months later, it was dead. Nobody used it.
Why? Because the “AI Assistant for Finance” didn’t know the difference between a “booking” and a “reservation.” In one bounded context, it meant revenue. In another, it meant risk. The agent mashed them like a bad DJ and began taking action that would’ve landed the CFO in handcuffs.
When finance flagged it, the engineers shrugged, “That’s how the model works.” Integration teams had bolted it onto systems it knew nothing of. Compliance was never invited to the party.
The result: another corporately embalmed AI pilot. A shiny demo that never made it to production.
All because they skipped the hard part — the domain. They built horsepower with no map.
Why DDD and DICE Matter in Enterprise AI
AI agents are the new rock stars of tech. Everyone wants one. Few know how to build one that lasts. They show up like new joiners with PhDs — clever, fluent, and useless on day one.
Because they don’t understand the business. They don’t understand the domain.
DDD is not a fad. It’s a survival strategy. It’s the difference between an AI that can sing karaoke with your data and one that can actually approve a loan, track a shipment, or detect a compliance breach.
But DDD alone is not enough. We must also integrate that domain with context engineering. For this challenge, Rod Johnson gives us DICE — Domain-Integrated Context Engineering — as the bridge between domain models and LLM (agent) contexts.
Here’s how DICE reframes what we must do:
Domain: Not just the vocabulary, but the objects, behaviours, invariants. The real business logic and constraints lived in your company.
Integration: It’s not enough to shape what you send into the LLM; you must shape what you ask back. The same domain model must mediate inputs and outputs.
Context Engineering: We fill the agent’s window with structured context drawn from domain objects, not from free-text or fuzzy embeddings alone.
Bidirectionality: The language used going in must align with what comes out. The agent should speak the business’s dialect in both directions.
Johnson argues that DICE “supplements context engineering by emphasising the importance of a domain model to help structure context, and considering LLM outputs as well as inputs.”
In practice, DICE means:
We treat domain objects as first-class context units, not just data dumps or JSON blobs.
We use typed domain models to filter, trim, and shape the context window to what really matters — business semantics, not token bloat.
We integrate the agent tightly with existing systems (CRM, ERP, audit logs) via the shared domain model, not via ad hoc adapters.
We enforce consistency: what the agent returns must map to domain types and invariants, reducing translation loss between natural language and system operations.
DDD gives the scaffolding; DICE wires that scaffolding into the agent’s memory and reasoning. This alignment is the difference between a demo and a dependable system.
The Core Gifts: Ubiquitous Language, Bounded Contexts, Strategic Design
When DDD + DICE are applied your prompts, ontologies, and agent actions are unified under the ubiquitous language shared by domain experts and developers. Bounded contexts protect you. The agent in “Risk” doesn’t bleed into “Customer Service.”
Strategic design ensures you don’t waste time automating trivia. You focus on the core domain where an agent can deliver real leverage. When you skip DDD + DICE, you get what countless enterprises already have: zoological collections of pilots, chatbots, and assistants that work fine in isolation—but detonate on real business data.
With DDD + DICE, your agent becomes a trusted teammate. It tells the difference between a “claim” and a “ticket,” “approval” and “authorisation.” It speaks the dialect of your business, not Silicon Valley pitch-deck English.
Redemption: The Living Agent
Another enterprise. Another AI project. Same hype. Same expectations.
But this time, the team started with the domain. They locked themselves in a room with sticky notes and business experts. They mapped the flows of money, risk, approvals. They fought over words until they reached a ubiquitous language that all — humans and machines — could share.
They carved bounded contexts like clean cuts of meat. Finance was one, Risk another. No sloppy overlaps. Integration was deliberate, with clear seams.
Then they built the agent. Not a general genius, but a specialist. Fluent in its context, sharp in its language. It didn’t try to do everything. It did one thing — compliance checks — better, faster, more reliably than any human. Because it spoke the business dialect, people trusted it.
What made it real? The DICE alignment.
The context fed into the LLM was shaped by domain objects, pruned for business relevance. The outputs were validated back into domain types. Its interactions were mediated via the same domain model used in existing systems.
Months later, the CFO wasn’t killing it. The CFO was fighting to fund three more like it.
Maxim
“An agent without a domain is a tourist without a map.”
Some Practices
Start with event storming to uncover domain behaviour and edge cases.
Define bounded contexts before writing prompts or wiring inference.
Model (or even reuse) domain objects as first-class in the agent’s context — not just free text.
Shape agent prompts via domain types, not ad hoc JSON dumps.
Enforce bidirectional alignment: outputs must validate back to domain invariants.
Integrate with systems (ERP, CRM) via the same domain model.
Some things to avoid
Letting the LLM or vendor dictate your domain model.
Accidentally overloading a single agent with multiple bounded contexts.
Treating the agent as a black box: no observability, no traceability.
In enterprise AI, agents must act inside real, messy business realities. DDD gives you the map; DICE wires it to the agent’s mind.
Further Exploration
Eric Evans, Domain-Driven Design
Alberto Brandolini, Introducing EventStorming
Rod Johnson, “Context Engineering Needs Domain Understanding” (DICE)
Christian Posta & Mark Fisher on secure integration of tools for enterprise agents