Executive Summary
If your AI-generated code needs constant correction, the issue is not the model; It is missing context. AI-assisted software delivery improves when models are grounded in domain-validated context before code generation begins.
AIS uses Domain-Driven Design (DDD) and EventStorming to translate discovery outputs into a structured context contract that AI tools can consistently operate against. This contract defines business rules, user roles, workflow boundaries, and MVP scope upfront, reducing rework, improving traceability from discovery through delivery, and helping ensure generated code reflects how the business actually operates.
Operational Benefits
With the right context in place, AI becomes an accelerator, not a source of rework. For customers, this approach enables faster delivery with fewer structural corrections, clearer traceability from discovery through implementation, and AI-generated outputs that better reflect real business behavior. On the oncology guidance platform referenced in this document, the team used EventStorming before code generation to define the domain clearly enough to support a production-ready application in less than eight weeks.
With this change, the team spent less time correcting generic AI assumptions and more time reviewing meaningful edge cases. The context contract also helped control scope by making the approved domain model the source of truth for what should and should not be generated.
Creating Context using DDD
AI code generation tools are now part of everyday software development, but their biggest limitation is context. When a model does not understand the domain it is building for, it fills gaps with familiar patterns from prior training. The result may look correct while behaving incorrectly around business rules, user roles, security boundaries, and workflow expectations.
DDD provides the language and structure needed to define that context. Bounded contexts give both the development team and the AI tool a shared source of truth. This is especially important for greenfield applications, where the domain has not yet been codified in existing systems or documentation.
EventStorming as Context Engineering
The reliability of AI-generated code improves when EventStorming is used to define context, not just capture requirements. This technique maps a domain through events, commands, aggregates, policies, and bounded contexts. While many teams use it as a requirements activity, this approach treats EventStorming output as context engineering: every sticky note represents a decision the AI needs before it generates infrastructure, API stubs, data models, or tests.
When those decisions are captured in a structured form the AI can consume, generation becomes a more reliable implementation step. Without them, the AI guesses. It may guess reasonably, but it can still guess wrong for the domain.
Figure 1: EventStorming the development cycle of a feature or task
Start With the Domain, Not the Prompt
Before pointing AI at a codebase, we need real conversations with domain experts. These conversations surface the rules that no model will infer correctly from a vague starting point.
On this project, we found that user registration involved multiple distinct roles. That technical detail shaped how every downstream feature behaved. Questions worth asking during domain exploration:
- What are the primary goals for each user type?
- Should the onboarding experience differ by role, and if so, how?
- Are there privacy or security considerations unique to each registration path?
We also found that certain content was publicly discoverable while access was gated. That boundary needed to be explicitly mapped with guided questions like
- What should unauthenticated users see?
- Where does preview end and access begin?
These are not questions to resolve later in a design review. They are domain rules that need to be in the context contract before generation starts.
High-Value Outputs
The most valuable output of our EventStorming sessions was what we called the context contract. The team created a structured Markdown specification that captured the full domain model in a form both engineers and AI tooling could consume.
The contract covered:
- Bounded contexts and the relationships between them
- Actor types with their distinct workflows and permissions
- Commands with preconditions and expected outcomes
- Domain events and their subscribers across context boundaries
- Policies encoding business rules and domain constraints
- AI generation instructions specifying scope, order, and integration approach
The AI generation instructions were significant to unlock. Instead of re-explaining the domain in every prompt session, the contract became the persistent context. We pointed GitHub Copilot’s plan mode at the contract. Giving the plan feature access to the context contract and other project specific documents, meant the gap-finding happened before generation, not after. Assumptions that the AI might otherwise bake silently into generated code became visible and correctable at the plan stage.
The event-driven architecture also came directly out of the EventStorming process. This meant we could publish events and let subscribers react, rather than sending commands across bounded context boundaries. That decision carried forward consistently into the Statement of Work, Software Requirements Specification, and System Design Review. The contract kept design decisions traceable from the workshop to the deliverable.
Figure 2: Process Model of the Development cycle of a feature or task
Tech Takeaway
AI-first delivery works better when models are given domain-validated contracts instead of inferred context. EventStorming is the mechanism for building those contracts. The workshop output becomes the specification, the specification becomes the context, and generation follows from there.
The quality of the contract directly affects the quality of the output. A vague contract produces generic code. A precise contract produces code that matches the domain, supports bounded-context delivery, and gives teams a repeatable pattern for using AI safely in complex software environments. The contract also kept generation aligned with the development phase’s scope. When the contract is the source of truth, it is harder for generation to drift into features that were not designed.
Human-in-the-loop review remained a critical part of the AI-assisted development process. By using GitHub Copilot’s plan mode before generation, the team could review the model’s proposed approach, identify likely assumptions, and correct gaps in domain understanding before those assumptions became codified mistakes that had to be found and fixed later in QA. Those fixes were applied back to the context contract.
The process became a repeatable Playbook:
- Run EventStorming for process modeling with domain experts
- Identify bounded contexts and the relationships between them
- Codify outputs into a structured context contract for the LLM
- Embed AI generation instructions directly in the contract
- Use Copilot plan mode to surface gaps and assumptions before generation runs
- Generate code and tests scoped to one bounded context at a time
- Integrate via events and contracts, not direct coupling
The quality of the contract directly affects the quality of the output. A vague contract produces generic code. A precise contract produces code that matches the domain. That tradeoff is worth investing in before writing a single line.
