NCA Social Media
Aktualisiert:
Autor:
Roland Golla
Grüner Zaun zwischen zwei Bereichen mit Schild Bounded Context

Bounded Context: Definition und Einordnung

Ein Bounded Context ist ein abgegrenzter Bereich, in dem ein fachliches Modell und seine Begriffe eindeutig gelten. Außerhalb dieser Grenze darf dasselbe Wort etwas völlig anderes bedeuten, ohne dass daraus ein Problem wird.
Das Standardbeispiel ist der Kunde. Im Vertrieb ist ein Kunde ein Ansprechpartner mit Interessen und Historie. In der Buchhaltung ist derselbe Kunde ein Debitor mit Zahlungsziel und Mahnstufe. Wer beides in eine Klasse presst, bekommt ein Objekt mit dreißig Feldern, von denen jeweils die Hälfte leer bleibt.
Bounded Context gehört zum strategischen Teil von Domain Driven Design und ist dort der wichtigste Baustein. Die Grenze ist keine Ordnerstruktur, sondern eine Vereinbarung: Innerhalb gilt ein Modell, an der Grenze wird bewusst übersetzt.

Inhalt

Bounded Context mit NCA: Schnelle Hilfe vom Experten

Grenzen zu ziehen ist einfach, sie zu halten ist die Arbeit. Never Code Alone baut täglich mit Symfony und Sulu CMS und kennt beide Enden der Skala: den Monolithen ohne jede Trennung und das verteilte System mit zu vielen Grenzen. Wir helfen beim Schnitt und sichern ihn mit Deptrac und PHP Arkitect in der Pipeline ab.
An der Grenze zum Altsystem arbeiten wir mit einem Anti Corruption Layer, für die schrittweise Ablösung mit dem Strangler Fig Pattern. Vorher steht immer die Absicherung mit Characterization Tests und PHPUnit. Wie KI Agents mit solchen Grenzen umgehen, ordnen wir bei Vibe Coding Consulting ein.
Grenzen sauber ziehen 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

Woran man einen guten Schnitt erkennt

Gute Grenzen folgen der Sprache und der Organisation, nicht der Technik. Wo ein Begriff seine Bedeutung wechselt, liegt fast immer eine Grenze. Wo zwei Teams unterschiedliche Prioritäten haben, ebenfalls.
  • Sprachwechsel: Dasselbe Wort bedeutet in zwei Abteilungen etwas anderes.
  • Eigener Rhythmus: Ein Bereich ändert sich monatlich, der andere einmal im Jahr.
  • Klare Verantwortung: Ein Team kann den Bereich alleine ändern und ausrollen.
  • Wenige Übergänge: Der Austausch mit anderen Bereichen passt auf eine Seite.
Ein schlechter Schnitt verrät sich schnell. Jede Änderung braucht Abstimmung mit drei Teams, Datenstrukturen wandern hin und her, und niemand kann einen Bereich alleine testen. Dann liegt die Grenze an der falschen Stelle oder sie existiert nur auf dem Papier.

Bounded Context in PHP umsetzen

Ein Bounded Context braucht keinen eigenen Service und keinen eigenen Server. In den meisten PHP Projekten reicht ein eigener Namespace mit eigenem Modell, eigener Persistenz und einer klaren Schnittstelle nach außen.
Code: 
          
src/
  Vertrieb/
    Domain/
    Application/
    Infrastructure/
  Buchhaltung/
    Domain/
    Application/
    Infrastructure/
  Shared/
    Domain/
Entscheidend ist, was zwischen den Ordnern erlaubt ist. Vertrieb darf Buchhaltung nicht direkt aufrufen und umgekehrt. Der Austausch läuft über Domain Events oder ein schmales Interface. Shared bleibt bewusst klein, sonst entsteht dort ein neuer Monolith.
Code: 
          
deptrac:
  layers:
    - name: Vertrieb
      collectors:
        - type: directory
          value: src/Vertrieb/.*
    - name: Buchhaltung
      collectors:
        - type: directory
          value: src/Buchhaltung/.*
  ruleset:
    Vertrieb:
      - Shared
    Buchhaltung:
      - Shared
Diese Konfiguration gehört in die Pipeline. Ein Verstoß bricht den Build, nicht erst das Code Review. Ergänzend beschreiben PHP Architecture Tester und PHP Arkitect Regeln als normale Tests, die mit PHPUnit laufen.

Ein Modell für alles gegen mehrere Bounded Contexts

Thema Ein gemeinsames Modell Mehrere Bounded Contexts
Begriffe Ein Wort muss alle Bedeutungen abdecken Jeder Kontext definiert seine Begriffe selbst
Änderungen Jede Änderung betrifft potenziell alle Teams Änderungen bleiben innerhalb der Grenze
Tests Lange Laufzeit, viele Abhängigkeiten Kleine, schnelle Tests pro Bereich
KI Agents Kontext zu groß, Agent ändert Unbeteiligtes Klarer Arbeitsbereich mit eigenen Tests

Grenzen als Arbeitsbereich für KI Agents

Ein Coding Agent braucht einen klaren Auftrag und einen begrenzten Ausschnitt. Genau das liefert ein Bounded Context. Der Bereich hat eigene Begriffe, eigene Tests und eine überschaubare Menge Code, die in ein Kontextfenster passt.
In der Praxis heißt das: Der Auftrag lautet ändere die Preisberechnung im Vertrieb, nicht ändere die Preisberechnung. Läuft die Testsuite des Bereichs grün und meldet Deptrac keinen Verstoß, war der Eingriff sauber. Ohne diese Absicherung wandert Infrastrukturcode in die Domäne, und niemand merkt es beim Review.
Die Regel bleibt: erst Quality Gates, dann Tempo. Statische Analyse mit PHPStan, Unit Tests, Functional Tests und Cypress für die Oberfläche. Mehr dazu in unseren Vibe Coding Best Practices.

A model is a selectively simplified and consciously structured form of knowledge.

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

Die NCA Erfahrung mit Grenzen in gewachsenen Systemen

In gewachsenen Systemen existieren Grenzen meistens schon, nur unsichtbar. Wir machen sie sichtbar, bevor wir etwas verschieben: DePHPend zeigt Abhängigkeiten, PDepend und PHP Metrics liefern Zahlen, Churn PHP zeigt, welche Stellen ständig angefasst werden.
Dann wird abgesichert. Characterization Tests halten das Verhalten fest, Symfony KernelTestCase deckt die Integration ab, Infection prüft die Aussagekraft der Tests. Für den Umbau nutzen wir Parallel Change, Parallel Run und Rector.
Weitere Werkzeuge und Begriffe stehen im NCA PHP Glossar. Wer mit KI gestützter Entwicklung arbeitet, findet den passenden Einstieg bei Vibe Coding lernen.
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 Bounded Context

Antworten auf die Fragen, die in Architektur Workshops regelmäßig auf dem Tisch liegen.

Was ist ein Bounded Context 2026 einfach erklärt?

Ein Bounded Context ist ein abgegrenzter fachlicher Bereich, in dem ein Modell und seine Begriffe eindeutig gelten. Innerhalb der Grenze bedeutet ein Wort genau eine Sache. Außerhalb darf dasselbe Wort etwas anderes heißen, weil dort ein eigenes Modell gilt. Die Grenze ist eine fachliche Vereinbarung, keine technische Ordnerstruktur.

Wie viele Bounded Contexts braucht ein Projekt 2026?

So wenige wie möglich und so viele wie nötig. In der Praxis liegen die meisten Systeme bei einer einstelligen Zahl. Jeder Kontext kostet Übersetzungsaufwand an der Grenze. Wenn zwei Bereiche ständig dieselben Daten austauschen und immer gemeinsam geändert werden, waren es wahrscheinlich zwei Kontexte zu viel.

Braucht ein Bounded Context 2026 einen eigenen Microservice?

Nein. Ein Bounded Context ist eine fachliche Grenze, kein Deployment. Ein modularer Monolith mit klar getrennten Namespaces erfüllt denselben Zweck und ist einfacher zu betreiben. Wenn ein Bereich später eigene Skalierung oder ein eigenes Release braucht, lässt er sich entlang der bestehenden Grenze herauslösen.

Wie sichert man Grenzen 2026 technisch ab?

Mit Werkzeugen in der Pipeline. Deptrac beschreibt Layer und meldet jeden verbotenen Zugriff. PHP Architecture Tester und PHP Arkitect formulieren Architekturregeln als normale Tests, die mit PHPUnit laufen. Ein Verstoß bricht damit den Build und nicht erst das Code Review, in dem ihn ohnehin niemand sieht.

Warum helfen Bounded Contexts 2026 bei KI Agents?

Weil sie einen begrenzten Arbeitsbereich liefern. Der Code eines Kontexts passt ins Kontextfenster, die Begriffe sind eindeutig und die Testsuite ist klein genug für schnelles Feedback. Der Auftrag lautet dann ändere diesen Bereich statt ändere das System. Architekturtests fangen ab, was der Agent falsch verbindet.

Wie findet man die richtigen Grenzen?

Über die Sprache. Wo ein Begriff seine Bedeutung wechselt, liegt fast immer eine Grenze. Zweiter Hinweis ist die Organisation: Bereiche, die von unterschiedlichen Teams mit unterschiedlichem Rhythmus geändert werden, gehören getrennt. Ein Workshop mit den Fachleuten bringt hier mehr als jede Analyse des bestehenden Codes.

Was ist der Unterschied zwischen Bounded Context und Modul?

Ein Modul ist eine technische Gliederung, ein Bounded Context eine fachliche. Ein Modul kann Teil eines Kontexts sein, ein Kontext kann aus mehreren Modulen bestehen. Entscheidend ist die Frage nach dem Modell: Gilt innerhalb der Einheit genau eine Bedeutung je Begriff, handelt es sich um einen Bounded Context.

Wie kommunizieren zwei Bounded Contexts miteinander?

Über eine bewusst gestaltete Schnittstelle. Üblich sind Domain Events, ein schmales Interface oder eine veröffentlichte Sprache, auf die sich beide Seiten einigen. Zum Altsystem hin übersetzt ein Anti Corruption Layer. Direkter Zugriff auf die Datenbank des anderen Kontexts ist der schnellste Weg, die Grenze wieder aufzulösen.

Dürfen zwei Kontexte dieselbe Datenbank nutzen?

Technisch ja, fachlich nur mit getrennten Tabellen und klaren Eigentumsverhältnissen. Jede Tabelle gehört genau einem Kontext, andere lesen nicht direkt mit. Sobald zwei Kontexte auf dieselbe Tabelle schreiben, ist die Grenze weg, und jede Schemaänderung betrifft wieder beide Seiten gleichzeitig.

Wie geht man mit gemeinsam genutztem Code um?

Sparsam. Ein Shared Bereich für echte Allgemeinplätze wie Geldbeträge oder Zeitspannen ist sinnvoll. Sobald dort fachliche Logik landet, entsteht ein neuer Monolith in der Mitte. Im Zweifel lieber doppelter Code in zwei Kontexten als eine gemeinsame Klasse, die von beiden Seiten in verschiedene Richtungen gezogen wird.

Lassen sich Grenzen nachträglich in Legacy Code einziehen?

Ja, das ist der Normalfall. Zuerst wird sichtbar gemacht, was heute zusammenhängt, danach wird das Verhalten mit Tests festgehalten. Erst dann wird verschoben, Stück für Stück, mit Parallel Change für Schema und API. Ein Big Bang Umbau ohne diese Vorarbeit scheitert zuverlässig.

Wie viel Aufwand steckt in der Einführung?

Das hängt vom Zustand des Systems ab. Fehlen Tests und Pipeline, geht der größere Teil in die Absicherung, bevor überhaupt eine Grenze gezogen wird. Bei NCA startet jede Zusammenarbeit mit einem kostenlosen Kennenlernen, danach schätzen wir den Aufwand ein und rechnen transparent minutengenau ab.