Solution Architect
Domänenschnitt, Bounded Contexts, Migrationspfade aus Legacy-Systemen, ereignisgesteuerte Architekturen. Dort, wo eine gewachsene Landschaft ein Zielbild und einen gangbaren ersten Schritt braucht.
Solution Architect mit 8 Jahren PO-Erfahrung · Domain Driven Design · Legacy-Modernisierung
Monolithen auflösen, ohne den Betrieb anzuhalten.
23 Jahre Softwareentwicklung. Ich schneide gewachsene Systemlandschaften nach fachlichen Domänen und überführe sie schrittweise in verteilte Architekturen. Weil ich selbst acht Jahre Product Owner war, liefere ich das Zielbild so, dass ein PO es schneiden und priorisieren kann. Die Konsequenzen stehen im Klartext daneben.
E-Mail schreibenVerfügbar ab 01.09.2026 · 32–40 h/Woche
Hybrid, NRW vor Ort möglich
Das operative Geschäft der blitzblank GmbH wird übergeben.
Hybrid, NRW vor Ort möglich
Das operative Geschäft der blitzblank GmbH wird übergeben.
Profil
Eine Soll-Architektur ist nur so gut wie der erste Schritt, den ein Team davon umsetzen kann. Diesen Schritt formuliere ich mit.
Schwerpunkte
Domänenschnitt nach Domain Driven Design, Bounded Contexts und die Integrationsmuster dazwischen, Migration aus Legacy-Systemen, ereignisgesteuerte Architekturen.
Gegenüber dem Produkt
Ich war acht Jahre Product Owner. Heute nutze ich das, um POs zuzuarbeiten statt sie zu vertreten: Optionen mit Aufwand und Konsequenz, Epics, die sich schneiden lassen, technische Abhängigkeiten vor der Planung auf dem Tisch.
- 23
- Jahre Softwareentwicklung
- CPSA-A
- iSAQB, Modul DDD
- 5
- Fachbereiche als Stakeholder
- 6
- Personen im cross-funktionalen Team
Zwei Rollen
Ich besetze eine davon – und weiß, wie die andere arbeitet.
Product Owner
Acht Jahre in der Rolle, unabhängig von Architekturthemen: Stakeholder aus fünf Fachbereichen, Backlog und Priorisierung, Refinements, Akzeptanzkriterien, UAT und Freigabe – auch für zwei native Apps und laufende Produkte ohne Umbauvorhaben.
Architektur
Wofür man mich holt und was am Ende dasteht.
Domänenschnitt und Bounded Contexts
Fachliche Grenzen finden, Kontexte benennen, Datenhoheit je Kontext festlegen. Dazu die Integrationsmuster zwischen den Kontexten: Anticorruption Layer, Open Host Service, Published Language.
Migration aus dem Monolithen
Soll-Architektur plus Migrationspfad: einzelne Kontexte schrittweise herauslösen, im laufenden Betrieb. Jeder Schritt liefert erkennbaren Nutzen.
Ereignisgesteuerte Architekturen
Eventmodellierung und Service-Schnitt an fachlichen Grenzen. Services nach hexagonaler Architektur, Ports und Adapter, klare Schichtentrennung.
Erhebung mit dem Fachbereich
EventStorming zur Ist-Erhebung; Core-, Supporting- und Generic-Klassifikation als Grundlage für Buy-vs-Build-Entscheidungen und den Teamzuschnitt entlang der Domänen.
Zusammenarbeit mit dem PO
Die Produktverantwortung bleibt beim Product Owner. Ich sorge dafür, dass sie auf belastbarem Grund steht.
Gemeinsame Sprache
EventStorming mit Fachbereich, PO und Entwicklung. Danach reden alle über dieselben Begriffe. Der PO hat ein Modell, auf das die Roadmap passt.
Schneidbare Epics
Bounded Contexts geben vor, was unabhängig lieferbar ist. Ich mache technische Abhängigkeiten sichtbar, bevor sie im Sprint auffallen – priorisiert wird im Backlog des PO.
Entscheidbare Optionen
Zwei bis drei Wege statt einer Empfehlung, jeweils mit Aufwand, Risiko und Folgekosten. Die Entscheidung trifft, wer das Produkt verantwortet – sie muss nur informiert sein.
Projekte
Vier Arbeiten, an denen sich der Ansatz zeigt.
Monolith zu verteilter, ereignisgesteuerter Architektur
Für die B2B-Handelsplattform Zielbild und Migrationspfad entworfen: Bounded Contexts geschnitten, Eventmodell und Datenhoheit je Kontext festgelegt, Services nach hexagonaler Architektur aufgebaut. Herauslösung schrittweise im laufenden Betrieb, technische Abhängigkeiten zwischen Teams und Systemen über den gesamten Pfad gesteuert.
- Domain Driven Design
- Event-Driven
- Hexagonal
- Migration
Domain Driven Design im Unternehmen etabliert
DDD initiiert und als Arbeitsgrundlage verankert: Kontextschnitt gemeinsam erarbeitet, Teams als Change Lead an den Domänengrenzen restrukturiert, Wechsel von Kanban auf Scrum initiiert und OKR eingeführt.
- Context Mapping
- Team Topologies
- Change Lead
- OKR
SaaS-Produkte von der Domäne bis zum Deployment
Eigene Produkte – Bestandsprognose und Disposition, USt-ID-Prüfdienst – nach DDD und Clean Architecture selbst verantwortet: fachlicher Schnitt, Domänenmodell, Ports und Adapter, Persistenz, API-Design, Livebetrieb. PHP, PostgreSQL, TypeScript.
- Clean Architecture
- PHP
- PostgreSQL
- API-Design
Integrationsarchitektur über ERP, Shop und Marktplatz
Order-to-Cash durchgängig über ERP (weclapp), B2B-Shop, Amazon-Marketplace, Fulfillment und Buchhaltung: Integrationsmuster gewählt, Datenhoheit und Eventflüsse definiert, Schnittstellen gebaut (REST, GraphQL, Webhooks) und externe Dienstleister gegen Akzeptanzkriterien gesteuert.
- Integrationsmuster
- ERP
- Webhooks
- Order-to-Cash
Erfahrung
Solution Architect / Product Owner · eigene SaaS-Produkte
blitzblank GmbH, Lüdinghausen · Gründer und GeschäftsführerArchitektur, Produktschnitt und Umsetzung in einer Hand – inklusive der Konsequenzen aus der eigenen Priorisierung.
- Architektur und Umsetzung eigener SaaS-Produkte nach Domain Driven Design, hexagonaler und Clean Architecture: fachlicher Schnitt, Domänenmodell, Ports und Adapter, Persistenz, API-Design
- Konzeption von Systemschnittstellen zwischen ERP, Shop, Marktplätzen und Buchhaltung: Integrationsmuster, Datenhoheit, Eventflüsse
- Aufbau der digitalen Systemlandschaft: ERP (weclapp), B2B-Shop, Amazon-Marketplace, Fulfillment- und Logistikanbindung
- Auswahlentscheidungen zwischen Standardsoftware und Eigenentwicklung nach fachlicher Differenzierung
- Steuerung externer Entwicklungsdienstleister: Spezifikation, Review, Abnahme gegen Akzeptanzkriterien
Solution Architect / Product Owner / Change Lead
Simplicity networks GmbH, Oelde- Domain Driven Design im Unternehmen initiiert und etabliert; maßgeblich am Schnitt der fachlichen Kontexte beteiligt
- Bounded Contexts, Eventmodell und Datenhoheit je Kontext festgelegt; Services nach hexagonaler Architektur
- Zielbild und Migrationspfad aus dem Monolithen in eine verteilte, ereignisgesteuerte Architektur; schrittweise Herauslösung im laufenden Betrieb
- Product Owner der B2B-Handelsplattform in verteilter Microservice-Architektur, cross-funktionales Team mit sechs Personen
- Anforderungsaufnahme mit fünf Fachbereichen, Priorisierung, Refinements, User Acceptance Testing, Freigabe
- Restrukturierung der Teams entlang der Domänenschnitte als Change Lead; Wechsel auf Scrum, Einführung von OKR
Senior Software Engineer / Tech Lead
Simplicity networks GmbH, Oelde · freiberuflich- Aufbau der Softwarearchitektur der B2B-Handelsplattform: Modulschnitt, Schichtentrennung, Ablösung gewachsener Strukturen
- Umbau der Codebasis nach Clean-Code-Prinzipien, Migration der Anwendung nach AWS
- Aufbau agiler Arbeitsweisen im Unternehmen und in der IT
Senior Software Engineer
clubgolf Marketing GmbH, Dortmund- Entwicklung und Betrieb eines CRM inkl. Automatisierungen, Bestellung, Vertragswesen und Mahnlauf
- PHP, Infrastruktur- und Betriebsthemen
Softwareentwickler
leasingmarkt.de GmbH, Dortmund- Neuentwicklung einer Fahrzeug-Marktplatzplattform
- PHP, Datenbankmodellierung, Schnittstellen zu Händler- und Anbietersystemen
Softwareentwicklung
dogado.de, crossconcept, crebyte- Hostingplattform, diverse Kundenprojekte, Performance-Marketing-Anwendungen
Skills
Alles hier stammt aus eigener Anwendung.
Architektur
- Domain Driven Design
- Bounded Contexts, Context Mapping
- Event-Driven Architecture
- Microservices
- Hexagonale und Clean Architecture
- Modularisierung
- Legacy-Modernisierung
Technik
- PHP
- PostgreSQL
- TypeScript
- REST- und GraphQL-APIs
- CI/CD
- AWS
Prozesse und Produkt
- Requirements Engineering
- Prozessanalyse und -optimierung
- Order-to-Cash
- ERP-Integration
- CRM-, Vertrags- und Abrechnungsprozesse
- Backlog Management
- Scrum, Kanban, OKR
- Jira, Confluence
Arbeitsweise
Der PO behält das Steuer
Ich liefere Modell, Optionen und Konsequenzen. Die Reihenfolge macht der Product Owner. Weil ich die Rolle selbst hatte, weiß ich, in welcher Form Architekturarbeit dort brauchbar ankommt.
Entscheidungen begründen statt anordnen
Eine Architekturentscheidung, die ein Team nicht nachvollzieht, hält keine zwei Sprints. Ich lege Optionen und Konsequenzen offen und entscheide dann sichtbar.
Zielbilder in Schritten mit Nutzen
Kein Big Bang. Jeder Migrationsschritt löst einen Kontext heraus und liefert etwas, das im Betrieb erkennbar besser läuft.
Analytisch, bis der Prozess steht
Stammdaten, Bestellung, Preisfindung, Abrechnung – erst wenn der Ablauf verstanden ist, wird geschnitten. Ein Modell ohne verstandenen Prozess ist Dekoration.