URDAD for domain-driven design teams
Keep your bounded contexts and your ubiquitous language, and give every boundary a contract which is checked, tested and run.
URDAD is a domain-driven method. A team which already works with bounded contexts and a ubiquitous language will find both in it, under names of its own, and gains a contract at every boundary.
The concepts you know
- Bounded context is a responsibility domain, which owns its services, entities and data.
- Ubiquitous language is the model itself, every term an element with its definition.
- Context map is the Dependencies View, drawn from the model rather than by hand.
- Domain service is a service contract, stating what is required, and the process realizing it, stating how.
In the manual: concept by concept
Boundaries that are agreed, not assumed
What one context may expect of another is a service contract, i.e. when the service is refused and what it guarantees when it is not. A requester names only the contract, never the context which provides it, so a context can be reworked, outsourced or automated without its requesters changing.
In the manual: where URDAD is stronger
Data that follows the processes
Entities are not designed apart from the services. Each is assembled from the data the processes record, and each context binds only the part it needs. The tool shows which services use each part of an entity, and reports stored data which none uses.
In the manual: different starting points
Your code, held to the model
Implement a context by hand with DDD’s tactical patterns, and your pipeline tests it with requests generated from the contracts it provides, judging every answer against them. Nobody writes those tests.
Where DDD is stronger, and using both
DDD guides the structure of code, and workshops such as event storming discover a domain quickly with no tool at all. Use them to discover, and record what you find in URDAD, where it is checked and kept.