Domain-Centric Development

The domain at the center.
Everything else points inward.

Business rules end up scattered across controllers, entities and services. Domain-Centric Architecture (DCA) puts them in the domain; web and persistence stay outside, as adapters. An architecture test fails the build when technology reaches in — in Java and .NET.

What you get framework updates stay out of the domain, the build names the boundary that broke, and an agent is held to the same bar as a colleague.

Add architecture checks Read the guide Explore the sample
web rest events persistence mcp scheduler domain

the mark is the architecture: adapters on the boundary, the domain at the core, neighbor contexts with a core of their own

Infrastructure → Adapters → Application → Domain

One rule governs everything: dependencies point inward. The domain knows no framework, no database, no protocol, and the build checks it. Whether the model is right stays a human question.

1 · the mistake 
package shop.checkout.domain;

import shop.checkout
  .infrastructure.persistence
  .OrderRow;

An entity reaches for its table row. A year later the model cannot change without the database.

2 · the rule that catches it 
DCA-LAY-002
Domain must not depend on
Infrastructure

selects  classes in *.domain..
checks   no dependency on
         *.infrastructure..

One structural rule, the same in Java and .NET. The mistake becomes a red test, not a review comment.

3 · the boundary 
checkout.application.shared
  OrderRepository   ← interface

checkout.adapter.outgoing
  .persistence
  JpaOrderRepository

The application states what it needs; the adapter implements it. The same rule keeps it that way.

The guide

The decisions, before the code

Every pattern is decided once and written down in the guide — read in an afternoon, looked up later.

architecture/

The style itself

The four layers · use cases · aggregates and value objects · which way dependencies run · integration between contexts · the rule catalog in prose.

topics/

Where it meets a stack

ArchUnit · Spring Modulith · C#/.NET · how it differs from Clean Architecture · deployment · teams and boundaries · end-user tests.

process/

How work is delivered

One story from plan to documentation, with a gate between the stages · ADRs that record the why.

Reading path

Three documents, in this order

Elements for the vocabulary, Rules for the constraints, Package structure for where files go. The rest is lookup.

Read the full guide on GitHub

The reference implementation

A shop that runs, not a snippet

Two working webshops demonstrate DCA, in Java and .NET, with the same routes, markup and seed data. End-user tests check both implementations.

Java · Spring Boot

The Java shop on a desktop browser: the domaincentric.commerce home page with its hero and an orange JAVA ribbon in the corner
docker compose up --build — localhost:8080. The ribbon says which stack is running.
The same Java shop on a phone: the logo on its own line, every link under it, the orange JAVA tag in the top-right corner
The same page at 393 px — links under the logo, the stack tag in the corner.
  • Java 25 · Spring Boot 4Spring Modulith for the module boundaries, the event publication registry as the outbox.
  • 8 bounded contextsaccount, product, pricing, inventory, cart, checkout, portal, backoffice — each with its own model.
  • Architecture checks in the build./gradlew test-architecture. A boundary violation fails the build with the rule id.
The Java shop on GitHub

.NET · ASP.NET Core

The .NET shop on a desktop browser: the domaincentric.commerce home page with its hero and a violet .NET ribbon in the corner
docker compose up --build — localhost:5080. The same page, down to the wording.
The same .NET shop on a phone: the logo on its own line, every link under it, the violet .NET tag in the top-right corner
The same page at 393 px — links under the logo, the stack tag in the corner.
  • ASP.NET Coreone project per bounded context, the boundaries carried by the solution layout instead of a module system.
  • The same shopsame routes, same markup; both end-user suites check the same 22 scenarios.
  • The same rule idsdotnet test on ArchUnitNET, plus six DCA-NET rules for .NET only.
The .NET shop on GitHub

One architecture, six artifacts

Everything describes the same system

Guide, libraries, two shops, catalog and plugins describe one system. The catalog is generated; maintenance keeps the rest in step.

Guide

The compact guide

The architectural decisions for team members and agents: tactical DDD, ports & adapters, naming, package layout, the purpose of each rule.

dca-guide

Building Blocks

Markers and rules as libraries

Marker interfaces for the DDD and hexagonal building blocks, plus the architecture rules, on Maven Central and NuGet. The markers have no dependencies.

Already on jMolecules? Point the rules at org.jmolecules.ddd.types.* — no type needs migrating.

dca-java dca-dotnet

Reference implementation · Java

A working webshop

Java 25, Spring Boot 4, eight bounded contexts, full tactical patterns. The rules run in the build.

dca-ecommerce-sample-java

Reference implementation · .NET

The same shop, built twice

ASP.NET Core, one project per bounded context, the same Ubiquitous Language. The evidence that DCA carries over to C# unchanged.

dca-ecommerce-sample-dotnet

Knowledge catalog

Knowledge that travels, machine-readable

Guide, markers and rules as one graph of over 500 nodes for agents to look up and cite. Generated, tool-agnostic.

dca-knowledge-catalog

Tooling

Three plugins as skill folders, a fourth as a cockpit

  • dca-core describes, creates and reviews a project.
  • dca-factory delivers stories, with a gate between the stages.
  • dca-craft carries TDD, clean code, ADRs and reviews.
  • dca-factory-cockpit shows and steers the cycle, in Claude Code only.

Claude Code, Codex and OpenCode read the same skill folders.

dca-marketplace

Why it is built this way

Architecture an agent can be held to

DCA is the architecture, a synthesis of Domain-Driven Design, Hexagonal and Clean Architecture. Domain-Centric Development is how software is built with it, with AI support. What a machine can check should be deterministic: the structure and red before green. Whether an agent gets the domain right is not measured yet.

  1. 01

    The rules are executable, and they have ids

    121 shared ids like DCA-USE-009, for Java and .NET. A shared id means the same intent; what each platform checks is in its rule list.

    see what the rules check · compare Java and .NET coverage

  2. 02

    The knowledge is machine-readable

    The catalog connects guide, markers and rules in one graph. Agents look things up in it and cite them.

  3. 03

    The pipeline decides, not the stage

    Gate scripts require an end-user test per acceptance criterion and read red before green from the test report, not from an exit code. A story with a page counts as delivered only once a person has accepted it.

    watch one cycle in the cockpit, from the first topic to the app

  4. 04

    Two webshops, as evidence and as the experiment field

    An agent built the same story in both stacks, and two divergences showed. Both were closed in a rule and the catalog, not in the shop code — that is what the pair is for.

Start small

One command, one architecture test

DCA does not begin with a rewrite, but with one test that fails when a dependency points the wrong way.

# in Claude Code; Codex and OpenCode read the same skill folders
/plugin marketplace add domain-centric-development/dca-marketplace
/plugin install dca-core@dca-marketplace

# on an existing Java or .NET project
/dca-init        # Building Blocks and an architecture test, fitted to the existing layout
/dca-new         # or: a new project in an empty directory

./gradlew test-architecture   # Java
dotnet test                   # .NET — the architecture project, Debug build
  1. 01

    Adapt, do not overwrite

    Existing marker interfaces are kept or aliased. Nothing is replaced just because it has a different name.

  2. 02

    Select the rules for the project

    Rules come in sets. One that does not fit yet is switched off by id — in writing, not quietly.

  3. 03

    Then grow the model

    Then aggregates, value objects and use cases, with naming conventions and a glossary per context.

  4. 04

    Deliver through the optional pipeline

    One story through every stage, with gates. Optional: the architecture works without it.

What the checks do and do not show

The rule suites check structure: where a type lives, what it depends on, how it is named. Whether the model is correct and a use case does what the business meant needs behaviour tests, a domain expert and review.

Deliver with the factory

Set it up once, then deliver story by story

dca-factory delivers one story at a time, with a gate between the stages. It needs a project description, a backlog and a stack profile; /factory-setup adds what is missing.

# once per machine, next to dca-core from above
/plugin install dca-craft@dca-marketplace     # tests, reviews, glossary for the stages
/plugin install dca-factory@dca-marketplace

# the foundation — once per project, and when something moves
/factory-setup      # description, git, runner, gate, hook, profile — only what is missing

# the cycle — discover → backlog → run → decide → delivered
/factory-discover   # optional: which problem is worth solving
/factory-backlog    # epic and story with checkable criteria
/factory-run        # plan → test → build → tidy → judge → document
/factory-decisions  # answer questions, accept results
/factory-status     # what is delivered, running, waiting, what it cost

# unattended, from a shell
bash .agents/factory/factory.sh run
  1. 01

    The description comes first

    /dca-describe writes project/ with you: product, technology, domain. Every stage reads it; none invents what it leaves open.

  2. 02

    The profile belongs to the project

    dca-factory.profile.yaml holds the build and test commands. Detection prefills it, a person corrects it. A run never guesses a command.

  3. 03

    A person releases the story

    /factory-backlog writes stories with scenarios. Only status: approved runs; an open question stops the run and waits in /factory-decisions.

  4. 04

    In a session or unattended

    /factory-run runs in the session, factory.sh run unattended from a shell. Both write the same files; /factory-status shows either.

    watch one run below · read how the stages and gates work · install the plugins

Example

One factory cycle, steered from the cockpit

A small task list, from the first topic to the running app. Claude writes the report and the stories, a person releases them, the worker delivers them.

2 min 22 — the stories and the app are in German, as the product is.

AI-generated from the logs of a real run on 2 October 2026 (dca-factory 0.61.0, Opus 5.5). Times, tokens and costs are real; the session and the app stills are reconstructed. 50 minutes of run time take one minute in the video.

Principles

Structural rules are checked; design choices need review

The rule suites encode structural conventions for developers and agents.