Domain-Centric Development

Die Domäne im Zentrum.
Alles andere zeigt nach innen.

Fachregeln landen verstreut in Controllern, Entities und Services. Domain-Centric Architecture (DCA) legt sie in die Domäne; Web und Persistence bleiben außen, als Adapter. Ein Architekturtest bricht den Build, wenn Technik hineingreift – in Java und .NET.

Was ihr davon habt Framework-Updates bleiben aus der Domäne, der Build nennt die verletzte Grenze, und ein Agent wird gemessen wie ein Kollege.

Architekturtest einbauen Guide lesen Beispiel ansehen
web rest events persistence mcp scheduler domain

die Marke ist die Architektur: Adapter auf der Grenze, die Domäne im Kern, daneben Nachbarkontexte mit eigenem Kern

Infrastructure → Adapter → Application → Domain

Eine Regel steht über allem: Abhängigkeiten zeigen nach innen. Die Domäne kennt kein Framework, keine Datenbank, kein Protokoll, und der Build prüft das. Ob das Modell richtig ist, bleibt eine Frage an Menschen.

1 · der Fehler 
package shop.checkout.domain;

import shop.checkout
  .infrastructure.persistence
  .OrderRow;

Eine Entity greift nach ihrer Tabellenzeile. Ein Jahr später lässt sich das Modell nicht mehr ohne die Datenbank ändern.

2 · die Regel, die das fängt 
DCA-LAY-002
Domain must not depend on
Infrastructure

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

Eine Strukturregel, dieselbe in Java und .NET. Der Fehler wird ein roter Test, kein Review-Kommentar.

3 · die Grenze 
checkout.application.shared
  OrderRepository   ← Interface

checkout.adapter.outgoing
  .persistence
  JpaOrderRepository

Die Application nennt, was sie braucht; der Adapter setzt es um. Dieselbe Regel hält es so.

Der Guide

Die Entscheidungen, vor dem Code

Jedes Pattern ist einmal entschieden und im Guide aufgeschrieben – an einem Nachmittag gelesen, später zum Nachschlagen.

architecture/

Der Stil selbst

Die vier Layer · Use Cases · Aggregates und Value Objects · die Richtung der Abhängigkeiten · Integration zwischen Kontexten · der Regelkatalog in Prosa.

topics/

Wo DCA auf einen Stack trifft

ArchUnit · Spring Modulith · C#/.NET · der Unterschied zu Clean Architecture · Deployment · Teams und Grenzen · End-User-Tests.

process/

Wie geliefert wird

Eine Story vom Plan bis zur Doku, mit einem Gate zwischen den Stufen · ADRs, die das Warum festhalten.

Lesereihenfolge

Drei Dokumente, in dieser Reihenfolge

Elements für das Vokabular, Rules für die Vorgaben, Package structure für die Ablage. Der Rest ist Nachschlagen.

Den ganzen Guide auf GitHub lesen

Die Referenzimplementierung

Ein Shop, der läuft, kein Snippet

Zwei laufende Webshops zeigen DCA, in Java und .NET, mit denselben Routen, demselben Markup und denselben Seed-Daten. End-User-Tests prüfen beide Implementierungen.

Java · Spring Boot

Der Java-Shop im Desktop-Browser: die Startseite von domaincentric.commerce mit Hero und einer orangen JAVA-Markierung in der Ecke
docker compose up --build — localhost:8080. Die Markierung zeigt den laufenden Stack.
Derselbe Java-Shop auf dem Smartphone: das Logo in einer eigenen Zeile, alle Links darunter, die orange JAVA-Marke oben rechts
Dieselbe Seite bei 393 px — Links unter dem Logo, die Stack-Marke in der Ecke.
  • Java 25 · Spring Boot 4Spring Modulith für die Modulgrenzen, die Event Publication Registry als Outbox.
  • 8 Bounded Contextsaccount, product, pricing, inventory, cart, checkout, portal, backoffice – jeder mit eigenem Modell.
  • Architekturprüfungen im Build./gradlew test-architecture. Eine Grenzverletzung bricht den Build mit der Regel-Id.
Der Java-Shop auf GitHub

.NET · ASP.NET Core

Der .NET-Shop im Desktop-Browser: die Startseite von domaincentric.commerce mit Hero und einer violetten .NET-Markierung in der Ecke
docker compose up --build — localhost:5080. Dieselbe Seite, bis in die Formulierung.
Derselbe .NET-Shop auf dem Smartphone: das Logo in einer eigenen Zeile, alle Links darunter, die violette .NET-Marke oben rechts
Dieselbe Seite bei 393 px — Links unter dem Logo, die Stack-Marke in der Ecke.
  • ASP.NET Coreein Projekt pro Bounded Context; die Grenzen trägt das Solution-Layout statt eines Modulsystems.
  • Derselbe Shopdieselben Routen, dasselbe Markup; beide End-User-Suiten prüfen dieselben 22 Szenarien.
  • Dieselben Regel-Idsdotnet test auf ArchUnitNET, dazu sechs DCA-NET-Regeln nur für .NET.
Der .NET-Shop auf GitHub

Eine Architektur, sechs Artefakte

Alles beschreibt dasselbe System

Guide, Bibliotheken, zwei Shops, Katalog und Plugins beschreiben ein System. Der Katalog wird generiert; den Rest hält Pflege in Deckung.

Guide

Der kompakte Guide

Die Architekturentscheidungen für Kollegen und Agenten: taktisches DDD, Ports & Adapter, Benennung, Package-Layout, der Zweck jeder Regel.

dca-guide

Building Blocks

Marker und Regeln als Bibliotheken

Marker-Interfaces für die Bausteine aus DDD und Hexagonaler Architektur, dazu die Architekturregeln, auf Maven Central und NuGet. Die Marker haben keine Abhängigkeiten.

Ihr nutzt schon jMolecules? Die Regeln lassen sich auf org.jmolecules.ddd.types.* zeigen – ohne einen Typ zu migrieren.

dca-java dca-dotnet

Referenzimplementierung · Java

Ein laufender Webshop

Java 25, Spring Boot 4, acht Bounded Contexts, alle taktischen Patterns. Die Regeln laufen im Build.

dca-ecommerce-sample-java

Referenzimplementierung · .NET

Derselbe Shop, zweimal gebaut

ASP.NET Core, ein Projekt pro Bounded Context, dieselbe Ubiquitous Language. Der Beleg, dass DCA ohne Umbau auf C# passt.

dca-ecommerce-sample-dotnet

Knowledge Catalog

Wissen, das mitkommt – maschinenlesbar

Guide, Marker und Regeln als ein Graph mit über 500 Knoten, den Agenten nachschlagen und zitieren. Generiert, unabhängig vom Werkzeug.

dca-knowledge-catalog

Werkzeuge

Drei Plugins als Skill-Ordner, ein viertes als Cockpit

  • dca-core beschreibt, erzeugt und reviewt ein Projekt.
  • dca-factory liefert Stories, mit einem Gate zwischen den Stufen.
  • dca-craft bringt TDD, Clean Code, ADRs und Reviews.
  • dca-factory-cockpit zeigt und steuert den Ablauf, nur in Claude Code.

Claude Code, Codex und OpenCode lesen dieselben Skill-Ordner.

dca-marketplace

Warum es so gebaut ist

Architektur, an der man einen Agenten messen kann

DCA ist die Architektur, eine Synthese aus Domain-Driven Design, Hexagonaler und Clean Architecture. Domain-Centric Development ist die Art, damit KI-gestützt zu entwickeln. Deterministisch soll sein, was eine Maschine prüfen kann: die Struktur und rot vor grün. Ob ein Agent die Domäne trifft, ist noch nicht gemessen.

  1. 01

    Die Regeln sind ausführbar und haben Ids

    121 gemeinsame Ids wie DCA-USE-009, für Java und .NET. Dieselbe Id heißt dieselbe Absicht; was jede Plattform prüft, steht in ihrer Regelliste.

    was die Regeln prüfen · Java und .NET im Vergleich

  2. 02

    Das Wissen ist maschinenlesbar

    Der Katalog verbindet Guide, Marker und Regeln in einem Graph. Agenten schlagen darin nach und zitieren.

  3. 03

    Die Pipeline entscheidet, nicht die Stufe

    Gate-Skripte verlangen einen End-User-Test je Akzeptanzkriterium und lesen rot vor grün aus dem Testbericht, nicht aus einem Exit-Code. Eine Story mit Seite gilt erst als geliefert, wenn ein Mensch sie abgenommen hat.

    einen Ablauf im Cockpit ansehen, vom ersten Thema bis zur App

  4. 04

    Zwei Webshops, als Beleg und als Experimentierfeld

    Ein Agent hat dieselbe Story in beiden Stacks gebaut; dabei fielen zwei Abweichungen auf. Geschlossen wurden beide in Regel und Katalog, nicht im Shop-Code – dafür ist das Paar da.

Klein anfangen

Ein Befehl, ein Architekturtest

DCA beginnt nicht mit einem Rewrite, sondern mit einem Test, der rot wird, wenn eine Abhängigkeit falsch zeigt.

# in Claude Code; Codex und OpenCode lesen dieselben Skill-Ordner
/plugin marketplace add domain-centric-development/dca-marketplace
/plugin install dca-core@dca-marketplace

# in einem bestehenden Java- oder .NET-Projekt
/dca-init        # Building Blocks und Architekturtest, passend zum vorhandenen Layout
/dca-new         # oder: ein neues Projekt im leeren Verzeichnis

./gradlew test-architecture   # Java
dotnet test                   # .NET – das Architekturprojekt, Debug-Build
  1. 01

    Anpassen, nicht überschreiben

    Vorhandene Marker-Interfaces werden übernommen oder per Alias deklariert. Nichts wird ersetzt, nur weil es anders heißt.

  2. 02

    Regeln für das Projekt auswählen

    Regeln kommen in Sets. Was noch nicht passt, wird per Id abgeschaltet – schriftlich, nicht stillschweigend.

  3. 03

    Dann das Modell wachsen lassen

    Danach Aggregates, Value Objects und Use Cases, mit Namenskonventionen und Glossar je Kontext.

  4. 04

    Über die optionale Pipeline liefern

    Eine Story mit Gates durch alle Stufen. Optional: Die Architektur funktioniert auch ohne.

Was die Prüfungen zeigen und was nicht

Die Rule Suites prüfen Struktur: wo ein Typ liegt, wovon er abhängt, wie er heißt. Ob das Modell stimmt und ein Use Case tut, was das Business meint, zeigen Verhaltenstests, Fachexperten und Review.

Liefern mit der Factory

Einmal aufsetzen, dann das Backlog abarbeiten

dca-factory liefert eine Story nach der anderen, mit einem Gate zwischen den Stufen. Sie braucht Projektbeschreibung, Backlog und Stack-Profil; /factory-setup ergänzt, was fehlt.

# einmal pro Rechner, neben dca-core von oben
/plugin install dca-craft@dca-marketplace     # Tests, Reviews, Glossar für die Stages
/plugin install dca-factory@dca-marketplace

# die Grundlage — einmal pro Projekt, und wenn sich etwas bewegt
/factory-setup      # Beschreibung, git, Runner, Gate, Hook, Profil – nur, was fehlt

# der Ablauf — discover → backlog → run → decide → delivered
/factory-discover   # optional: welches Problem sich lohnt
/factory-backlog    # Epic und Story mit prüfbaren Kriterien
/factory-run        # plan → test → build → tidy → judge → document
/factory-decisions  # Fragen beantworten, Ergebnisse abnehmen
/factory-status     # was geliefert ist, läuft, wartet, kostet

# unbeaufsichtigt, aus der Shell
bash .agents/factory/factory.sh run
  1. 01

    Zuerst die Beschreibung

    /dca-describe schreibt project/ mit euch: Produkt, Technik, Domäne. Jede Stage liest es; keine erfindet, was offen ist.

  2. 02

    Das Profil gehört dem Projekt

    dca-factory.profile.yaml hält die Build- und Testbefehle. Die Erkennung füllt es vor, ein Mensch korrigiert. Ein Lauf rät nie einen Befehl.

  3. 03

    Ein Mensch gibt die Story frei

    /factory-backlog schreibt Stories mit Szenarien. Nur status: approved läuft; eine offene Frage hält den Lauf an und wartet in /factory-decisions.

  4. 04

    In der Session oder unbeaufsichtigt

    /factory-run läuft in der Session, factory.sh run unbeaufsichtigt aus der Shell. Beide schreiben dieselben Dateien; /factory-status zeigt beides.

    einen Lauf ansehen, gleich darunter · nachlesen, wie Stages und Gates arbeiten · die Plugins installieren

Beispiel

Ein Factory-Ablauf, gesteuert aus dem Cockpit

Eine kleine Aufgabenliste, vom ersten Thema bis zur laufenden App. Claude schreibt Bericht und Stories, ein Mensch gibt sie frei, der Worker liefert sie.

2 min 22 — Untertitel und Session auf Deutsch, das Cockpit und die Ausgaben der Pipeline auf Englisch.

KI-generiert aus den Logs eines echten Laufs vom 2. Oktober 2026 (dca-factory 0.61.0, Opus 5.5). Zeiten, Tokens und Kosten sind echt, Session und App-Bilder nachgestellt. 50 Minuten Laufzeit dauern im Video eine Minute.

Prinzipien

Strukturregeln werden geprüft; Designentscheidungen brauchen Review

Die Rule Suites kodieren Strukturkonventionen für Entwickler und Agenten.