DomainSpec tackles one core problem: context and modeling intent get progressively distorted along the delivery chain.

Teams often speak clearly during the discovery phase, but by the time work goes through architecture, development, and testing, the original intent has drifted. DomainSpec is not yet another way to write documents; it is a framework for letting the same context penetrate execution and verification end‑to‑end.

The core idea is straightforward: define boundaries first, then define procedures.

First use DDD to carve out bounded contexts and clarify which concepts belong to which context; then use process design to define standard procedures, making explicit the inputs, outputs, and checkpoints at each step. Only after boundaries and procedures are nailed down can Agents execute efficiently, instead of guessing.

Even without Agents, this problem has always existed: requirements gradually deform as they pass between architecture, development, and testing; context gets lost at every handoff.

Agents are not the root cause; they simply increase the speed. Problems surface earlier and are amplified more easily. Speed without boundaries only accelerates deviation. DomainSpec’s value is in fixing boundaries, rules, and handoff relationships up front.

Unified Language and Context

This directly hits the hardest part of DDD in practice: ubiquitous language.

Domain experts, architects, developers, and validators often use the same word to refer to different things, or different words to refer to the same thing. Humans will misunderstand each other; Agents will only amplify that misunderstanding.

DomainSpec turns “unified language” from a meeting‑room consensus into transferable artifacts, and keeps passing these artifacts down into later stages so that the Agent’s context stays aligned with the DDD context.

1. Here, “context” is not background material; it is the boundary conditions for decisions.

   A bounded context in DDD is not only a unit of business modeling, but also a collaboration unit for Agents. The domain glossary is not just explanation text for humans, but also the anchor for prompts, task specs, and validation criteria.

   Once context changes, it must be propagated via explicit artifacts, not patched in via fuzzy notes in chat history.

2. Layering is not for formal completeness; it is to prevent semantic drift.

   The specification layer is responsible for defining meaning, structures, and procedures; the execution layer is responsible for implementation and verification. Feedback must not bypass the upstream model; it should flow back through explicit change requests.

   That way, what the system corrects is the specification itself, rather than quietly rewriting the original intent in implementation.

---

flowchart TB
    subgraph SPEC[Specification Layer]
        D[DDD ‑ Define Domain Boundaries]
        P[Process ‑ Design Standard Procedures]
        C[Unified Language & Shared Context]
        D --> C
        P --> C
    end

    C --> DEV[Agents Execute Within Clear Task Context]
    DEV --> VAL[Validate Whether Delivery Matches Intent]
    VAL -. Explicit Feedback & Change Requests .-> C

Agents

Human‑led, Agent‑assisted

• Domain Analysis Assistant
  • Responsibility: Define the business domain model and keep terminology consistent across all domain artifacts.
  • Artifacts: Glossary, Four‑Color Model, Event Map, Context Map.
• Architecture Design Assistant
  • Responsibility: Translate domain boundaries into system‑ and service‑level architecture, making constraints explicit.
  • Artifacts: System Context, Service Decomposition, Communication Map, NFR Analysis, ADRs, service‑level component designs.
• Process Design Assistant
  • Responsibility: Turn architectural constraints into reusable procedures and executable stories.
  • Artifacts: Procedure Catalog, Story Specs, process consistency checks.

Agent‑led, Human‑reviewed

• Developer
  • Responsibility: Implement approved stories under architectural and procedural constraints.
  • Artifacts: Implementation plans, business code, unit tests, developer‑side validation reports.
• Validator
  • Responsibility: Black‑box validation of delivery, feeding gaps back into the delivery layer.
  • Artifacts: Test plans, test code, test reports, defect‑type change requests.

In one sentence: DDD defines the boundaries; process defines the flow; Agents only become truly effective when context remains consistently unified — and DomainSpec’s role is to fix that context, propagate it, and continually correct it via feedback.

---

Project: https://github.com/Anddd7/domain-spec-agents

Examples: https://github.com/Anddd7/domain-spec-examples/pulls