NCA Social Media
Aktualisiert:
Autor:
Roland Golla
Grüner Wegweiser Domain Driven Design auf isometrischem Raster

Domain Driven Design: Definition und Einordnung

Domain Driven Design ist ein Ansatz für Softwareentwicklung, bei dem die Fachlichkeit die Struktur des Codes bestimmt. Entwickler und Fachexperten bauen gemeinsam ein Modell der Domäne und benutzen dieselben Begriffe im Gespräch, im Ticket und im Quelltext.
Eric Evans hat den Begriff 2003 geprägt. Der Kern ist einfach: Software wird komplex, wenn niemand mehr weiß, was ein Auftrag, ein Kunde oder eine Buchung im Unternehmen wirklich bedeutet. Domain Driven Design zwingt dazu, diese Fragen zu klären, bevor Klassen entstehen.
Der Ansatz teilt sich in zwei Ebenen. Das strategische Design schneidet ein großes System in fachliche Bereiche mit klaren Grenzen. Das taktische Design liefert die Bausteine im Code: Entities, Value Objects, Aggregate, Repositories und Domain Events. Beides gehört zusammen, in der Praxis scheitern Projekte meistens an der strategischen Ebene.

Inhalt

Domain Driven Design mit NCA: Schnelle Hilfe vom Experten

Never Code Alone arbeitet seit über zwanzig Jahren an gewachsenen PHP Systemen. Genau dort entscheidet sich, ob Domain Driven Design trägt oder zur Folienschlacht wird. Wir bauen täglich mit Symfony und Sulu CMS, sichern Grenzen mit Deptrac und PHP Arkitect ab und prüfen jede Änderung mit PHPStan und PHPUnit.
Der Weg in eine fachlich saubere Architektur führt fast nie über die grüne Wiese. Er führt über Characterization Tests, einen Anti Corruption Layer zum Altsystem und das Strangler Fig Pattern für die schrittweise Ablösung. Bei Vibe Coding Consulting ordnen wir zusätzlich ein, wie KI Agents mit fachlichen Grenzen umgehen und wo Guardrails nötig sind.
Fachlichkeit sauber schneiden mit NCA
Finde das passende Angebot für dein Projekt
Anfrage-Konfiguration
Starten Sie Ihre Anfrage
Projektart
Infos
Nachricht

Eliminierung technischer Schulden mit PHPStan, Rector PHP und PHPUnit. Über 20 Jahre Praxiserfahrung in skalierbaren Backends.

CORE EXPERTISE

Gesetzliche Konformität & Inklusion. Optimierung von Performance und Conversion durch radikal nutzerzentriertes, universelles Design.

BFSG COMPLIANT

Skalierbare KI-Systeme mit echtem Code Ownership. CI/CD, Backup-Strategien und Infrastruktur, die mit deinem Team wächst.

ENTERPRISE READY

Die Bausteine von Domain Driven Design

Domain Driven Design hat einen festen Wortschatz. Wer die Begriffe kennt, versteht auch die Diskussionen in Architektur Reviews.
  • Ubiquitous Language: die gemeinsame Sprache von Fachbereich und Entwicklung. Steht ein Begriff im Fachgespräch, steht er auch als Klasse oder Methode im Code.
  • Bounded Context: eine klare Grenze, innerhalb derer ein Modell gilt. Ein Kunde im Vertrieb ist etwas anderes als ein Kunde in der Buchhaltung.
  • Aggregate: eine Gruppe von Objekten, die zusammen konsistent bleiben muss. Der Zugriff läuft immer über die Aggregate Root.
  • Entity: ein Objekt mit eigener Identität über die Zeit, zum Beispiel eine Bestellung mit fester Nummer.
  • Value Object: ein Objekt ohne Identität, das nur über seine Werte definiert ist, zum Beispiel ein Geldbetrag oder eine Mailadresse.
  • Repository: der Zugang zu gespeicherten Aggregaten, fachlich formuliert statt als Datenbankabfrage.
  • Domain Event: eine fachliche Tatsache, die passiert ist. Sie wird veröffentlicht und von anderen Bereichen verarbeitet.
Die meisten Teams starten bei den taktischen Bausteinen, weil sie sich direkt programmieren lassen. Der Nutzen entsteht aber erst, wenn die Grenzen stimmen. Ein sauberes Value Object in einem falsch geschnittenen System löst kein einziges Problem.

Strategisches und taktisches Design im Überblick

Ebene Bausteine Frage dahinter
Strategisch Ubiquitous Language, Bounded Context, Context Mapping Wo verläuft die Grenze zwischen zwei Fachbereichen?
Taktisch Entity, Value Object, Aggregate, Repository Wie sieht das Modell im Code aus?
Integration Domain Events, Anti Corruption Layer, Published Language Wie sprechen zwei Kontexte miteinander?
Absicherung Deptrac, PHP Arkitect, PHPUnit, Cypress Wie bleibt die Grenze im Alltag bestehen?

Domain Driven Design in PHP und Symfony

PHP eignet sich gut für Domain Driven Design. Typisierte Properties, readonly Klassen und Enums seit PHP 8 machen Value Objects kurz und sicher. Ein Geldbetrag als eigenes Objekt verhindert eine ganze Klasse von Fehlern, die mit float niemals verschwinden.
Code: 
          
final readonly class Geldbetrag
{
    public function __construct(
        private int $cent,
        private Waehrung $waehrung,
    ) {
        if ($cent < 0) {
            throw new NegativerBetrag();
        }
    }

    public function plus(self $andere): self
    {
        if ($this->waehrung !== $andere->waehrung) {
            throw new WaehrungPasstNicht();
        }

        return new self($this->cent + $andere->cent, $this->waehrung);
    }
}
Im Symfony Alltag liegt die Domäne in einem eigenen Verzeichnis ohne Framework Abhängigkeiten. Controller, Doctrine und Twig bleiben außen. Die Domäne kennt keine Request Objekte und keine Datenbank, sie kennt nur Fachlichkeit. Das klingt streng, macht die Tests aber schnell und lesbar.
Damit diese Trennung hält, braucht es Werkzeuge. Deptrac definiert Layer und meldet jeden verbotenen Zugriff. PHP Architecture Tester und PHP Arkitect schreiben Architekturregeln als Test. Läuft das in der Pipeline, ist die Grenze keine Vereinbarung mehr, sondern ein roter Build.
Code: 
          
deptrac:
  layers:
    - name: Domain
      collectors:
        - type: directory
          value: src/Domain/.*
    - name: Infrastructure
      collectors:
        - type: directory
          value: src/Infrastructure/.*
  ruleset:
    Domain: ~
    Infrastructure:
      - Domain

Domain Driven Design und KI Agents 2026

KI gestützte Entwicklung macht Domain Driven Design wichtiger, nicht überflüssig. Ein Coding Agent arbeitet mit dem Kontext, den er bekommt. Ein klar geschnittener Bereich mit eindeutigen Begriffen passt in ein Kontextfenster, ein gewachsener Monolith mit drei Bedeutungen für das Wort Kunde nicht.
Drei Effekte sehen wir im Alltag mit KI gestützter Entwicklung:
  • Die Ubiquitous Language ist der beste Teil jeder Agent Anweisung. Wer seine Begriffe sauber definiert hat, schreibt bessere Prompts, ohne es zu merken.
  • Ein Bounded Context ist eine natürliche Arbeitsgrenze für einen Agenten. Der Auftrag lautet dann nicht ändere das System, sondern ändere diesen Bereich.
  • Architekturtests fangen ab, was der Agent falsch verbindet. Ohne diese Guardrails wandert Infrastrukturcode früher oder später in die Domäne.
Die Reihenfolge bleibt dieselbe wie beim Refactoring: erst Quality Gates, dann Tempo. Statische Analyse, Unit Tests und Functional Tests stehen vor jedem Agenten Einsatz. Modelle liefern Vorschläge, die fachliche Entscheidung trifft weiterhin das Team.

Wann sich Domain Driven Design lohnt und wann nicht

Domain Driven Design kostet Zeit. Diese Zeit zahlt sich nur aus, wenn die Fachlichkeit selbst kompliziert ist. Ein Formular, das Daten in eine Tabelle schreibt, braucht keine Aggregate.
Passt gut: Versicherungen, Logistik, Abrechnung, Buchungssysteme, alles mit vielen Regeln und langen Lebenszyklen. Auch gewachsene Systeme, in denen jede Änderung an drei anderen Stellen wehtut, profitieren sofort von klaren Grenzen.
Passt schlecht: reine CRUD Anwendungen, kleine Tools, Prototypen und Projekte, in denen kein Fachexperte erreichbar ist. Ohne echten Zugang zu den Menschen, die die Domäne kennen, entsteht kein Modell, sondern eine Vermutung in Klassenform.
Ein ehrlicher Zwischenweg funktioniert oft am besten. Grenzen ziehen und benennen, dann die kritischen Bereiche fachlich sauber modellieren und den Rest einfach halten. Wir helfen Teams genau bei dieser Einordnung, bevor die erste Zeile Code entsteht.

The heart of software is its ability to solve domain-related problems for its user.

Eric Evans, Autor von Domain Driven Design – Domain-Driven Design: Tackling Complexity in the Heart of Software

Die NCA Erfahrung mit fachlich getriebener Architektur

Wir begleiten Teams meistens dann, wenn das System schon läuft und trotzdem jede Änderung teuer ist. Der erste Schritt ist nie ein Aggregate, sondern Sichtbarkeit. Wo hängt was zusammen? Wir messen mit PDepend, PHP Metrics und Churn PHP und machen Abhängigkeiten mit DePHPend sichtbar.
Danach kommt die Absicherung. Characterization Tests halten das aktuelle Verhalten fest, PHPUnit und Symfony KernelTestCase decken die Logik ab, Cypress prüft die Oberfläche. Infection zeigt, ob die Tests wirklich etwas fangen. Erst dann verschieben wir Code.
Für den Umbau nutzen wir bewährte Muster: Parallel Change für Schema und API, Parallel Run zum Vergleich von alter und neuer Logik und Rector für mechanische Umbauten. Die Grenzen halten wir mit Deptrac dauerhaft sauber.
Wer tiefer einsteigen will, findet im NCA PHP Glossar die passenden Werkzeuge und bei Vibe Coding Best Practices die Regeln für KI gestützte Arbeit an gewachsenem Code.
CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.

Erreichen Sie unsere PHP Consultant Spezialisten

Wir sind Experten für PHP und helfen Ihnen, Ihre digitalen Herausforderungen zu meistern. Unser erfahrenes Team unterstützt Sie bei PHP Updates, PHP Refactoring und berät Sie remote zu allen Fragen rund um PHP. Mit unseren vollautomatischen CI/CD Deployments und einer robusten Docker-Infrastruktur bringen wir Ihre PHP-Projekte auf das nächste Level. Vertrauen Sie auf unsere Expertise für zuverlässige und skalierbare PHP-Lösungen.

Demo Team Workshop Anrufen

Häufige Fragen zu Domain Driven Design

Die wichtigsten Fragen aus Projekten, Schulungen und Architektur Reviews, kurz und ohne Buchzitat beantwortet.

Was ist Domain Driven Design 2026 kurz erklärt?

Domain Driven Design ist ein Ansatz, bei dem die Fachlichkeit die Struktur der Software bestimmt. Entwickler und Fachexperten einigen sich auf eine gemeinsame Sprache, schneiden das System in fachliche Bereiche mit klaren Grenzen und bilden diese Bereiche im Code ab. Der Ansatz stammt von Eric Evans aus dem Jahr 2003 und ist bis heute der Standard für komplexe Geschäftslogik.

Lohnt sich Domain Driven Design 2026 trotz KI gestützter Entwicklung?

Ja, und zwar mehr als vorher. Ein Coding Agent produziert schnell viel Code. Ohne klare fachliche Grenzen wächst dieser Code in alle Richtungen. Domain Driven Design liefert die Begriffe und die Grenzen, an denen ein Agent arbeiten kann, ohne das ganze System zu berühren. Die Modellierung selbst bleibt Arbeit für Menschen.

Welche Rolle spielt Domain Driven Design 2026 für KI Agents?

Ein Bounded Context ist eine natürliche Arbeitsgrenze für einen Agenten. Er passt ins Kontextfenster, hat eindeutige Begriffe und eigene Tests. Die Ubiquitous Language wird zur Grundlage der Anweisungen, weil sie jeden Begriff nur einmal definiert. Architekturtests fangen ab, wenn der Agent Infrastruktur in die Domäne zieht.

Wie startet ein PHP Team 2026 mit Domain Driven Design?

Nicht mit Aggregaten, sondern mit Sprache. Schreibt die zentralen Begriffe eures Geschäfts auf und klärt, wo dasselbe Wort zwei Bedeutungen hat. Daraus ergeben sich die Grenzen fast von selbst. Danach folgt ein kleiner Bereich als Pilot, abgesichert mit Tests, bevor die Muster auf den Rest übertragen werden.

Welche Tools helfen 2026 bei Domain Driven Design in PHP?

Deptrac und PHP Arkitect prüfen Schichtgrenzen als Test in der Pipeline. PHPStan und Psalm sichern Typen ab, PHPUnit deckt die Domänenlogik ab, Rector hilft bei mechanischen Umbauten. DePHPend und PDepend machen gewachsene Abhängigkeiten sichtbar. Für die Oberfläche prüft Cypress, ob die fachlichen Abläufe weiter funktionieren.

Was unterscheidet strategisches von taktischem Design?

Strategisches Design beantwortet die Frage nach den Grenzen: Welche fachlichen Bereiche gibt es, wie hängen sie zusammen, welche Sprache gilt wo. Taktisches Design liefert die Bausteine im Code, also Entities, Value Objects, Aggregate und Repositories. Wer nur taktisch arbeitet, bekommt saubere Klassen in einem falsch geschnittenen System.

Was ist der Unterschied zwischen Entity und Value Object?

Eine Entity hat eine Identität, die über die Zeit bestehen bleibt. Eine Bestellung bleibt dieselbe Bestellung, auch wenn sich ihr Status ändert. Ein Value Object hat keine Identität und wird nur über seine Werte bestimmt, zum Beispiel ein Geldbetrag oder eine Adresse. Value Objects sind unveränderlich und lassen sich gefahrlos kopieren.

Braucht Domain Driven Design zwingend Microservices?

Nein. Bounded Contexts sind fachliche Grenzen, keine Deployment Grenzen. Ein modularer Monolith mit sauber getrennten Bereichen ist für die meisten Teams die bessere Wahl und deutlich einfacher zu betreiben. Wenn ein Bereich später eigene Skalierung braucht, lässt er sich entlang der bestehenden Grenze herauslösen.

Passt Domain Driven Design zu Doctrine und Symfony?

Ja. Die Domäne liegt in einem eigenen Verzeichnis ohne Framework Abhängigkeiten, Doctrine bleibt Infrastruktur. Mit XML Mapping statt Attributen bleibt die Domänenklasse frei von ORM Details. Repositories werden als Interface in der Domäne beschrieben und in der Infrastruktur implementiert. Symfony liefert dafür alles Nötige mit.

Wie hängen Domain Driven Design und Event Sourcing zusammen?

Event Sourcing speichert nicht den aktuellen Zustand, sondern alle fachlichen Ereignisse. Das passt gut zu Domain Driven Design, weil Domain Events dort ohnehin vorkommen. Zwingend ist es nicht. Event Sourcing erhöht den Aufwand deutlich und lohnt sich vor allem, wenn die Historie selbst fachlich wertvoll ist, etwa bei Abrechnung oder Revision.

Wie bekommt man den Fachbereich an den Tisch?

Mit konkreten Fragen statt Methodendiskussion. Ein Workshop, in dem gemeinsam ein echter Ablauf auf Karten gelegt wird, bringt mehr als jede Einführung in Aggregate. Fachleute merken schnell, dass ihre Begriffe im System falsch verwendet werden. Dieser Moment erzeugt die Bereitschaft, dauerhaft mitzuarbeiten.

Was kostet die Einführung von Domain Driven Design?

Das hängt vom Zustand des Systems ab. Ohne Tests und Pipeline geht ein großer Teil des Aufwands in die Absicherung, bevor überhaupt modelliert wird. Bei NCA beginnt jede Zusammenarbeit mit einem kostenlosen Kennenlernen, danach schätzen wir den Aufwand ehrlich ein und rechnen transparent minutengenau ab. Feste Pakete gibt es bewusst nicht.