Domain Driven Design (DDD)
DDD focuses on modeling software based on business domains.
Requirements are discovered through dialog to create a ubiquitous language.
Ubiquitous Language is primarily a DDD term emphasizing that naming within the codebase should be consistent within bounded contexts.
Large domains are divided into subdomains or bounded contexts, each with its own model and language.
Within each bounded context DDD identifies Entities, Value Objects, Aggregates, Repositories, and Services.
Developers and experts refine the model iteratively from discussions.
Assertion Modeling provides an aligned and explicit picture of the business exposing gaps and ambiguities early. Moving to solution architecture with DDD becomes a fully informed exercise. The business description work must be done somewhere but not too early.
Aligning Assertion Modeling and DDD
AM supports and feeds domains, bounded contexts and components from a business perspective.
An assertion model provides a single point of capture of the business domains.
Software components can be identified from the assertions.
Order Entry Example
In summer 2025 a second full example assertion model followed Recruitment Example. It was built to show in more detail how manual assertions(determined by a person) could be specified as UI software components, and automatic assertions could be specified and implemented with DDD software components.
Order Entry was chosen because every advocate of DDD uses it as the example. Small examples look simple, but Order Entry as a whole is hard. This example is large but assailable – it all fits together in AM. This is three examples; the model, the specification and the application!
The model shows all the stakeholders, all the decisions, all the information.
The Full Assertion Model Example – Order Entry >
The specification shows the parts to be built, and how the implementation is designed.
DDD Specifications to Implement Part of Order Entry >
The application shows a proof of concept, built in a full stack with DDD components.
Video of the Order Entry Application – coming soon…
Hands-on Learnings
Investigating how assertions can be implemented was always an objective of AM. Building the model for Order Entry, and subsequently building a proof-of-concept application, revealed vividly why the business-IT gap has been no-mans-land for so long. AM was predicated on finding the essence of business with the idea that you cannot code what you don’t understand. The language of processes and requirements seemed an ephemeral offshoot of the core.
One particular observation was that all systems evolve. Whe they come face to face with reality they must adjust. So the waterfall approach will never work well; it just gives a first approximation.
But recent, strong emphasis of Agile, relying on discussions, struggles too. The framework is missing to hang the business observations and understand it’s relationships.
Another key observation is that data design is crucial to describing business. The logical data model that recognizes cardinality and a full set of attributes for entities ensures users understand their business better that any other method. (Asking if a person can have more than one spouse creates a realization that marriage history may pay a crucial role in the data structure).
Trying to map assertions to DDD software meant that DDD had to be examined in detail. Exact meanings were difficult to grasp. Experienced practitioners knew exactly what a bounded context was but struggled to formalize it. It was more an aspiration than a thing.
From Model to Application
Can assertion specifications build a working application? Here is a proof- of-concept!
If assertion modeling produces an accurate and coherent description of the business (it does), then implementation should be much quicker(it is).
The specifications generated for Order Entry were used to create a full stack application.
The implementation itself was planned in Assertionizer, identifying the assertions to be implemented into a full stack environment.
The implementation proof-of-concept took about a week for an inexperienced full stack developer, Some of it involved refining how Assertionzer generates the specification.
Your Opportunities
If you are a developer, working with domain experts, start by using some assertion thinking to elicit assumptions. Ask what is the decision? Who makes it? Where does the information go then?
If you have your own excel and jira methods to capture this, use them.
But if you want to move into the future, try capturing them in Assertionizer. Learn how to generate an implementation specification in JSON.
Then use your knowledge of your workstream to create the application.
If you are skeptical, try a really simple model in Assertionizer. Try the tutorial, or try the challenge.
DDD (Domain-Driven Design) is a software design approach that focuses on modeling software based on the real-world business domain it serves. The business model is expressed through entities, value objects, aggregates, services, and events.
In DDD, requirements are not handed over, they are discovered through ongoing dialogue with domain experts, developing a ubiquitous language for each domain. A cycle of discuss then code. AM offers a way to capture the business description, not in meeting notes but in a coherent structure that bridges business, and the code that implements it.
Building an assertion model provides a single point of capture of the business domains, and the foundation description of the business itself. Captured, so that it can be examined from different perspectives. Captured, so that sections can be implemented in sprints with clarity of the interactions before coding begins. Captured, so that software components can be identified from the assertions to be implemented. Captured, so that simulations can be generated and reviewed with the experts.
The example assertion model of Order Entry was developed in late 2025 with a particular DDD perspective. Assertions were framed so that corresponding software components could be easily mapped. Generation of build specifications were added to Assertionizer. And the generated specifications were proofed by building a proof of concept (POC) application implemented in a React, NodeJS environment. The hard parts of designing applications moved into the business assertions realm; it was there that much of the ubiquitous language and communication between components were resolved. Results from this POC will be presented here soon.
AM CAPTURES THE BUSINESS IN ENOUGH DETAIL TO MAP TO SOFTWARE COMPONENTS!
AM CAPTURES BUSINESS LOGIC EXPLICTLY!