In einem unverbindlichen Gespräch finden wir gemeinsam heraus, wie ich dich am besten unterstützen kann. Kein Verkaufsgespräch, keine Vertragsbindung.
Strukturiertes Refactoring nach DDD-Prinzipien. Wir machen aus gewachsener Komplexität klare Bounded Contexts, ohne den Betrieb anzuhalten.
1 Modul, alles vermischt
4 Bounded Contexts
Refactorings begleitet bei
Wenn du dich hier wiederfindest, ist Domain-Driven Refactoring der strukturierte Ausweg.
Was als saubere Schichtung gestartet ist, hat sich zu einem Geflecht aus Querbezügen entwickelt. Eine Preisänderung im Bestellprozess löst Tests im Reporting aus.
Neue Entwickler brauchen Wochen, bis sie sicher Code committen können. Das Domain-Wissen lebt in den Köpfen von drei Senior-Devs, nicht im Code.
Jedes Deployment kann irgendwo Nebenwirkungen haben. Du testest manuell, was eigentlich automatisiert sein sollte. Quartalsweise Release-Trains sind die Folge.
0%
Downtime während Refactor
Strangler-Fig-Pattern und Charakterisierungstests halten das System lauffähig, während wir umbauen.
3-5×
Schnellere Features
Klare Bounded Contexts und Team-Topology bedeuten, dass mehrere Teams parallel liefern können, ohne Merge-Konflikte.
70%
Weniger Onboarding-Zeit
Domain-Sprache, ADRs und Context-Maps machen das System lesbar, auch für neue Team-Mitglieder.
Wie sich dein System anfühlen kann, wenn die Domain-Grenzen wieder sichtbar sind.
Nicht jede Domäne ist gleich viel wert. Wir klassifizieren dein System nach DDD-Kategorien und leiten daraus Build-vs-Buy-Entscheidungen ab, bevor du Budget bindest.
Wo du im Wettbewerb stehst
Pricing-Engine
Differenzierung am Markt
Order-Lifecycle
Kundenerlebnis-zentral
Implikation
Custom Development. Beste Softwareentwickler. Höchstes Investment.
Was du gut können musst
Inventory
Geschäftskritisch, kein Differenzierer
Shipping
Standard-Integration
Implikation
Buy oder einfacher Custom-Build. Bewährte Pattern.
Wo Standard schlägt
Identity
Entra ID, Azure B2C
Logging & Audit
Application Insights, Sentinel
Implikation
Buy oder Open Source. Niemals selbst bauen.
Im ersten Workshop gehen wir mit Fachseite und Engineering an die Wand. Das Ergebnis ist ein Event-Flow, der Bounded-Context-Grenzen sichtbar macht.
Beispiel: Bestellprozess im E-Commerce
Customer registered
↳ Identity
Item added
↳ Catalog
Order placed
↳ Order
Payment authorized
↳ Payment
Inventory reserved
↳ Inventory
Order shipped
↳ Fulfillment
Wir bauen das neue System um das alte herum. Funktionalität wird Schritt für Schritt umgeleitet, das Alte schrumpft, bis es abgeschaltet werden kann.
Event-Storming-Workshops, Kontext-Mapping, Identifikation der wichtigsten Aggregates. Output: visualisierte Domain.
Deine Zeit
8-16 h
Unsere Arbeit
2-4 Wochen
Wir definieren die Soll-Architektur und entscheiden gemeinsam, welche Contexts zuerst herausgelöst werden.
Deine Zeit
4-8 h
Unsere Arbeit
2-3 Wochen
Bevor wir anfassen, sichern wir das aktuelle Verhalten mit Charakterisierungstests ab. Niemand weiß sonst, was kaputt geht.
Deine Zeit
2-4 h pro Woche
Unsere Arbeit
fortlaufend
Neue Funktionalität geht in den neuen Context. Bestehende wird Stück für Stück umgeleitet. Feature-Flags steuern den Rollout.
Deine Zeit
Sprint-Routine
Unsere Arbeit
iterativ
Sobald der neue Context produktiv läuft, schalten wir das alte Modul ab. Dokumentation und Wissensübergabe inklusive.
Deine Zeit
Übergabe pro Modul
Unsere Arbeit
Knowledge Transfer
Event-Storming-Workshops, Kontext-Mapping, Identifikation der wichtigsten Aggregates. Output: visualisierte Domain.
Deine Zeit
8-16 h
Unsere Arbeit
2-4 Wochen
Wir definieren die Soll-Architektur und entscheiden gemeinsam, welche Contexts zuerst herausgelöst werden.
Deine Zeit
4-8 h
Unsere Arbeit
2-3 Wochen
Bevor wir anfassen, sichern wir das aktuelle Verhalten mit Charakterisierungstests ab. Niemand weiß sonst, was kaputt geht.
Deine Zeit
2-4 h pro Woche
Unsere Arbeit
fortlaufend
Neue Funktionalität geht in den neuen Context. Bestehende wird Stück für Stück umgeleitet. Feature-Flags steuern den Rollout.
Deine Zeit
Sprint-Routine
Unsere Arbeit
iterativ
Sobald der neue Context produktiv läuft, schalten wir das alte Modul ab. Dokumentation und Wissensübergabe inklusive.
Deine Zeit
Übergabe pro Modul
Unsere Arbeit
Knowledge Transfer
Event-Storming-Workshops, Kontext-Mapping, Identifikation der wichtigsten Aggregates. Output: visualisierte Domain.
Deine Zeit
8-16 h
Unsere Arbeit
2-4 Wochen
Wir definieren die Soll-Architektur und entscheiden gemeinsam, welche Contexts zuerst herausgelöst werden.
Deine Zeit
4-8 h
Unsere Arbeit
2-3 Wochen
Bevor wir anfassen, sichern wir das aktuelle Verhalten mit Charakterisierungstests ab. Niemand weiß sonst, was kaputt geht.
Deine Zeit
2-4 h pro Woche
Unsere Arbeit
fortlaufend
Neue Funktionalität geht in den neuen Context. Bestehende wird Stück für Stück umgeleitet. Feature-Flags steuern den Rollout.
Deine Zeit
Sprint-Routine
Unsere Arbeit
iterativ
Sobald der neue Context produktiv läuft, schalten wir das alte Modul ab. Dokumentation und Wissensübergabe inklusive.
Deine Zeit
Übergabe pro Modul
Unsere Arbeit
Knowledge Transfer
DDD ist nicht nur ein Modellierungs-Vokabular. Hier die fünf konkreten Stellen, an denen wir Domain-Schnitte technisch erzwingen, jede mit dokumentierter Tiefe in unserem Blog.
Jeder Context exposed seine API über ein eigenes APIM-Product. Versionierung, Throttling und Schema-Validierung sichern die Vertragsgrenze zwischen Domains.
Was DDD im Code beschreibt, machen wir mit Terraform via state-mv und Resource-Imports. Alte Module schrumpfen, neue wachsen, Zero-Downtime-State-Migration.
Self-hosted GitLab Runner pro Domäne in eigener Subscription. Teams deployen unabhängig, ohne Cross-Team-Blocker im Shared-CI.
Eigene App Registration und Managed Identity pro Bounded Context. Kein geteiltes Service-Principal, klare RBAC, Identity-Audit pro Domain.
Stateful Domain-Service auf App Service, batch-orientierter Worker auf Container Apps, hochskalierbarer Hot-Path auf AKS. Wahl nach Workload-Profil, nicht nach Default.
Acht Maßnahmen, die wir typischerweise im Code anlegen, bevor wir am Domain-Schnitt arbeiten.
Automatisiertes Bauen, Testen und Bereitstellen der Anwendung nach jedem Commit durch den Einsatz von CI/CD-Servern wie Jenkins, GitHub Actions oder GitLab CI und das Nutzen von Teil-Deployments.
Anbieterunabhängige Bereitstellung von Infrastrukturressourcen durch den Einsatz von Infrastructure as Code Lösungen mit Terraform und der Verwendung der AWS, Azure und GCP Provider.
Durch die Aktualisierung von Programmiersprachen, Frameworks und Abhängigkeiten auf aktuelle Versionen können Sicherheitslücken geschlossen, die Performance verbessert und ggf. alternative Frameworks verwendet werden.
Wir erhöhen deine Testabdeckung beim Bugfixing und wenden die Pfadfinderregel an, indem wir den Code überarbeiten und mit Tests abdecken. Dabei implementieren wir verschiedene Testarten wie Unit Tests für Klassen, Integrationstests für Komponenten und UI-Tests für das Frontend.
Event Storming, Context Mapping und Bounded-Context-Hypothesen, der erste Workshop-Block.
Zusammen mit deinen Fachexperten, Domänen-Modellierern und Entwicklern beteiligen wir uns an deinen Diskussionen und Workshops, um die Ubiquitous Language zu identifizieren und die technische Fachsprache aus der Diskussion auszuschließen.
Welche Schritte sind tatsächlich durch die Fachlichkeit begründet? Wir helfen dir dabei, die aktuelle Anwendung auf technologisch bessere Lösungen zu überführen und die abgebildeten Prozesse auf ihre Essenz zu reduzieren.
Nachdem die Ist-Situation festgestellt wurde, passen wir die abgebildeten Software-Prozesse an die Sollprozesse an.
Aus den Domain-Erkenntnissen wird ein konkretes Zielbild, diskutierbar, prüfbar, umsetzbar.
Aus jeder identifizierten Subdomäne wird ein Bounded Context erstellt, der den Soll-Zustand darstellen wird. Diese Bounded Contexts können durch Event Storming, Domain Storys usw. entstehen.
Basierend auf den bestehenden Subdomänen der Arbeitsprozesse erstellen wir eine Context-Map, die deine Subdomänen in Core, Supporting und Generic Subdomains unterteilt. Diese Subdomains unterstützen das Team bei der Aufteilung der Legacy-Systeme in Microservices oder modulare Monolithen.
Während der Aufteilung der Anwendungszuständigkeiten können wir als Teil des Entwicklungsteams Bestandteile eines Bounded Context übernehmen und die technische Verantwortung für die Umsetzung tragen.
Damit die Funktionsweise einer Subdomäne autonom bleibt, betrachten wir die Schnittstellen und Kommunikationswege zwischen den Bounded Context genauer.
Die technischen Bausteine hinter den DDD-Patterns oben. Jeder Artikel zeigt das Vorgehen an einem realen Azure-Beispiel.
Wann APIM in Azure fachlich sinnvoll ist, wo es architektonisch nicht hingehört und welche Auswirkungen SKU-, Netzwerk- und Betriebsentscheidungen in der Praxis haben.
Artikel lesen
Viele Terraform-Projekte starten pragmatisch und enden als Monolith. Dieser Leitfaden zeigt, wie Sie Azure-Infrastruktur ohne Downtime in modulare States, klare Modulgrenzen und belastbare CI/CD-Governance überführen.
Artikel lesen
Dieser Beitrag zeigt dir, wie GitLab Runner sicher und produktionsfähig in Azure betrieben werden können und vergleicht dafür die Hosting-Optionen Azure Container Apps, App Service und virtuelle Maschinen.
Artikel lesen
Um die Verwirrung hinter App Registrations und Enterprise Applications aufzulösen, erkläre ich in diesem Beitrag die Unterschiede und Merkmale der jeweiligen Ressourcen.
Artikel lesen
In diesem Blogbeitrag erhalten Sie eine detaillierte Übersicht über Azure Container Apps, deren Einsatzmöglichkeiten und besondere Merkmale. Zudem werden die wichtigsten Unterschiede zu anderen Containerlösungen in Azure beleuchtet, sodass Sie eine fundierte Entscheidung für Ihre Cloud-Architektur treffen können.
Artikel lesen
Technisch fundierte Architektur-Einordnung von Azure Front Door, Application Gateway und API Management mit klaren Entscheidungsgrundlagen, Netzwerkimplikationen und realen Integrationsmustern.
Artikel lesen
Mertkan Henden
Cloud-Engineering-Berater · Heilbronn
Domain-Driven Refactoring ist 20 Prozent Methodik und 80 Prozent Diplomatie. Ich verbinde Engineering und Fachseite in Workshops, mache aus impliziten Annahmen explizite Bounded Contexts und sorge dafür, dass am Ende beide Seiten dieselbe Sprache sprechen.
— Mertkan Henden