Architecture Knowledge Base
This site collects the concepts, specifications, and examples for building software around autonomous domain capabilities.
I spent years building systems with Domain-Driven Design, object-oriented models, layered architectures, vertical slices, event sourcing, and distributed systems. In practice they pushed the code toward shared models, technical layers, repositories, services, and large coordination structures.
Here the domain is built from autonomous capabilities. Each capability owns one kind of business decision and the facts needed to decide, and returns a clear result.
This site documents the vocabulary and the structure around that idea.
The Book
These ideas are developed in full in the book Autonomous Domain Capabilities: Building Maintainable Software Around Business Decisions. It covers Request Processing Units, Command Context Consistency, and thinking in events, and shows how software built around business decisions stays simple to change as it grows and matches how teams own their work.
The book is in progress. Leanpub can email you the moment it's published.
Core Concepts
The domain is built from Domain Capabilities. Each is one thing the domain can do, a command or a query, implemented by a Request Processing Unit that owns the whole path from request to response.
Every capability works on one Application State, the authoritative record of facts, and shares nothing else. Command Context Consistency keeps each decision valid at the moment it commits, scoped to the facts the decision is based on rather than to an aggregate or an entity.
Around the domain, Delivery Mechanisms translate outside requests, Reactors coordinate interactions that need several capabilities, and Providers reach external resources.
See Concepts for the full model and a diagram of how the parts fit together.
Specifications
Some ideas need a stricter contract. The Command Context Consistency specification defines the event-store operations that realize the concept.
Intention
The intention is to make ownership boundaries explicit:
- user interactions are not domain capabilities
- delivery mechanisms are not domain logic
- reactors coordinate but do not decide
- providers access external resources but do not own domain behavior
- RPUs own domain capabilities
- capabilities share the Application State and nothing else
- consistency belongs to the facts the decision is based on
This structure keeps domain behavior local, reduces coupling, and makes systems easier to change without constantly reshaping shared models or technical layers.
Start Here
- Concepts — the vocabulary and the whole-picture diagram.
- Specifications — the Command Context Consistency contract.
- Examples — working implementations in Rust, C#, and event sourcing.