In einem unverbindlichen Gespräch finden wir gemeinsam heraus, wie ich dich am besten unterstützen kann. Kein Verkaufsgespräch, keine Vertragsbindung.
Backend-Services, APIs und Plattform-Komponenten, gebaut für Azure. Cloud-native Patterns, sauberes Identity-Konzept, Observability ab Tag eins.
Refactor: Pricing-Regeln in Aggregat ausgelagert
8 Dateien geändert · +312 −187
Im Auftrag von Engineering-Teams bei
Wenn du dich in einem dieser Punkte wiederfindest, lohnt sich ein Gespräch.
Manuelle Freigaben, fragile Pipelines und Cross-Team-Abhängigkeiten verlangsamen jede Auslieferung. Features sind fertig, kommen aber nicht in Production.
Was vor zwei Jahren als sauberer Service-Schnitt designt wurde, passt nicht mehr zur Produktrealität. Workarounds wachsen, technische Schulden auch.
Tests existieren, decken aber nicht das ab, was tatsächlich kaputt geht. Bugs werden in Production entdeckt, nicht in der Pipeline.
10×
Schnellere Deployments
Von quartalsweisen Release-Trains zu mehrfach täglichen Deployments durch CI/CD-Härtung und Trunk-Based Development.
<1%
Fehlerquote im Refactor
Strangler-Fig-Pattern und Charakterisierungstests halten das System lauffähig, während wir umbauen.
70%
Weniger Onboarding-Zeit
Saubere Architektur-Dokumentation und konsistente Code-Konventionen senken die Time-to-First-Commit für neue Entwickler deutlich.
Jede Phase hat einen klaren Output und einen messbaren Übergang. Kein Wasserfall, sondern iterative Verdichtung.
Beteiligten-Mapping, Zielbild, Erfolgskriterien und Leistungsumfang. Ich verstehe dein Geschäft, bevor Code geschrieben wird.
Deine Zeit
8-16 h
Unsere Arbeit
1-2 Wochen
Aus User-Interviews, System-Beobachtung und Aufgabenanalyse entstehen verifizierbare Anforderungen und erste Prototypen.
Deine Zeit
4-8 h pro Woche
Unsere Arbeit
2-4 Wochen
Bounded Contexts, Schnittstellen, Datenmodelle und Architekturentscheidungen werden mit ADRs festgehalten.
Deine Zeit
2-4 h pro Woche
Unsere Arbeit
2-3 Wochen
Trunk-Based Development, Pair Programming bei kritischen Stellen, automatisierte Tests auf allen Ebenen.
Deine Zeit
Sprint-Reviews
Unsere Arbeit
fortlaufend
Blue-Green-Deployments, Feature-Flags, Observability. Wir geben dich ein System, nicht nur Artefakte.
Deine Zeit
Demo + Abnahme
Unsere Arbeit
Sprintweise
SLOs, Alerting, Postmortem-Kultur. Wir bleiben verantwortlich, bis dein Team den Betrieb sicher übernimmt.
Deine Zeit
Handover-Workshops
Unsere Arbeit
nach Bedarf
Beteiligten-Mapping, Zielbild, Erfolgskriterien und Leistungsumfang. Ich verstehe dein Geschäft, bevor Code geschrieben wird.
Deine Zeit
8-16 h
Unsere Arbeit
1-2 Wochen
Aus User-Interviews, System-Beobachtung und Aufgabenanalyse entstehen verifizierbare Anforderungen und erste Prototypen.
Deine Zeit
4-8 h pro Woche
Unsere Arbeit
2-4 Wochen
Bounded Contexts, Schnittstellen, Datenmodelle und Architekturentscheidungen werden mit ADRs festgehalten.
Deine Zeit
2-4 h pro Woche
Unsere Arbeit
2-3 Wochen
Trunk-Based Development, Pair Programming bei kritischen Stellen, automatisierte Tests auf allen Ebenen.
Deine Zeit
Sprint-Reviews
Unsere Arbeit
fortlaufend
Blue-Green-Deployments, Feature-Flags, Observability. Wir geben dich ein System, nicht nur Artefakte.
Deine Zeit
Demo + Abnahme
Unsere Arbeit
Sprintweise
SLOs, Alerting, Postmortem-Kultur. Wir bleiben verantwortlich, bis dein Team den Betrieb sicher übernimmt.
Deine Zeit
Handover-Workshops
Unsere Arbeit
nach Bedarf
Beteiligten-Mapping, Zielbild, Erfolgskriterien und Leistungsumfang. Ich verstehe dein Geschäft, bevor Code geschrieben wird.
Deine Zeit
8-16 h
Unsere Arbeit
1-2 Wochen
Aus User-Interviews, System-Beobachtung und Aufgabenanalyse entstehen verifizierbare Anforderungen und erste Prototypen.
Deine Zeit
4-8 h pro Woche
Unsere Arbeit
2-4 Wochen
Bounded Contexts, Schnittstellen, Datenmodelle und Architekturentscheidungen werden mit ADRs festgehalten.
Deine Zeit
2-4 h pro Woche
Unsere Arbeit
2-3 Wochen
Trunk-Based Development, Pair Programming bei kritischen Stellen, automatisierte Tests auf allen Ebenen.
Deine Zeit
Sprint-Reviews
Unsere Arbeit
fortlaufend
Blue-Green-Deployments, Feature-Flags, Observability. Wir geben dich ein System, nicht nur Artefakte.
Deine Zeit
Demo + Abnahme
Unsere Arbeit
Sprintweise
SLOs, Alerting, Postmortem-Kultur. Wir bleiben verantwortlich, bis dein Team den Betrieb sicher übernimmt.
Deine Zeit
Handover-Workshops
Unsere Arbeit
nach Bedarf
Was ich in der Analyse-Phase liefere: Machbarkeitsstudie, Anforderungs-Spezifikation, frühe Prototypen.
Basierend auf den gegenwärtigen Bedürfnissen und Anforderungen deiner Organisation wird eine Machbarkeitsstudie durchgeführt, um die technische und wirtschaftliche Realisierbarkeit des Projekts zu bewerten. Dabei wird der Einsatz aktueller Software- und Hardwaretechnologien bewertet und basierend auf den Ergebnissen und Budget-Beschränkungen das Projektvorhaben aus geschäftlichem Standpunkt eingeschätzt.
Aus der Beobachtung deiner bestehenden System- und Anwendungslandschaft, Diskussionen mit potenziellen Usern und Aufgabenanalysen werden initiale Systemanforderungen erarbeitet. Diese können für die Implementierung erster Prototypen und die Bewertung von Systemmodellen verwendet werden.
Damit du die geplante Funktionsweise und konkreten zu erfüllenden Anforderungen auf einen Blick haben, werden Architekturdiagramme, ein Pflichtenheft und konkreten Schritte während des Projektvorhabens dokumentiert.
Um die identifizierten fachlichen und technischen Anforderungen validieren zu können, ist vor einem konkreten Projektstart initiale Prototypen möglich. Dadurch erlangst du einen ersten Eindruck von den technischen Möglichkeiten deiner finalen Lösung.
Beispielhafte Topologie für eine kundenorientierte Webanwendung mit klarer Schichtung und Cloud-nativen Bausteinen.
Front Door / CDN
Edge routing
API Management
Gateway
Application Gateway
WAF + SSL
App Service
Web + API
AKS
Kubernetes
Container Apps
Workers
Functions
Serverless
Service Bus
Async messaging
Event Hubs
Event streaming
Event Grid
Pub/Sub
Logic Apps
Orchestration
PostgreSQL
Transactional
Cosmos DB
Document
Blob Storage
Files
Application Insights
APM
Log Analytics
Logs & queries
Key Vault
Secrets
Vier Aspekte, die wir bei jeder Architektur-Bewertung anschauen. Microservices vs. modularer Monolith ist nur einer davon.
Microservices, mono- oder modulare Monolithen, Serverless oder Container-Orchestrierung? Die Auswahl der Softwarearchitektur ist abhängig von den Anforderungen an die Skalierbarkeit, Performance und Wartbarkeit deiner Anwendung. Gerne unterstützen wir dich bei der Auswahl der passenden Softwarearchitektur für dein Projekt.
Jede Softwarelösung ist eingebettet in ein bestehendes Ökosystem aus Umsystemen, die durch Schnittstellen und Kommunikationswege miteinander verbunden sind. Die Analyse der Umsysteme hilft dabei, die Anforderungen an die Softwarearchitektur zu identifizieren und die Interaktionen zwischen den Umsystemen zu definieren.
Wer kommuniziert mit wem und wie? Die Definition der Kommunikationswege zwischen den Subsystemen und Umsystemen ist ein wichtiger Schritt, um die Anforderungen an die Softwarearchitektur zu spezifizieren und die Interaktionen zwischen den Subsystemen zu modellieren und passende Technologien einzusetzen.
Die Softwarearchitektur sollte so gestaltet sein, dass sie zukünftige Erweiterungen und Anpassungen ermöglicht. Durch die Verwendung von Microservices, modularen Monolithen oder Serverless-Architekturen kannst du deine Softwarelösung flexibel und skalierbar gestalten.
Wir wählen Technologien nach Anforderung, nicht nach Mode. Diese Tools nutzen wir am häufigsten in Konzern-Umfeldern.
Frontend
Web-Interfaces, die auch in zwei Jahren noch wartbar sind.
Backend
Stabile Services, gebaut für Last und Compliance.
Daten
Persistenz, Streaming und Analytics, passend zur Domain.
Infrastruktur
Reproduzierbare Umgebungen, deklarativ und auditierbar.
Konsistente Konventionen, kleine Pull Requests, Tests die echtes Verhalten absichern. Ein Use-Case aus einem Bounded Context — der Application-Service ruft das Aggregat auf, Geschäftsregeln und Domain-Events leben dort.
1@ApplicationScoped2public class PlaceOrder {34 @Inject Customers customers;5 @Inject Orders orders;6 @Inject Clock clock;78 @Transactional9 public OrderId handle(PlaceOrderCmd cmd) {10 var customer = customers.byId(cmd.customerId())11 .orElseThrow(() -> new CustomerNotFound(cmd.customerId()));1213 var order = customer.placeOrder(cmd.cart(), clock.now());14 orders.add(order);1516 return order.id();17 }18}Drei Praxis-Felder, die ich aus echten Projekten dokumentiert habe. Keine generischen Schlagwörter, sondern Erfahrung.
GitLab Runner in deiner Azure-Subscription statt Shared-Cloud-Runner: kein Egress, vollständige Kontrolle über Cache, Secrets und Netzwerk-Sichtbarkeit.
Welche Compute-Plattform passt zu welchem Workload? Wir vermeiden den Fehler, alles auf AKS zu stellen, wenn ein App Service oder Container App reicht.
Application Insights für Telemetry, Data Collection Rules für strukturierte Custom-Logs. SLOs als Code, Alerts versioniert mit der App.
Wie ich konsistente Qualität sicherstelle, auf Code-, Prozess- und Fachbereich-Ebene.
Jedes Entwicklerteam besitzt eigene Methoden zur Projektorganisation, Abnahme von Teilergebnissen und die internen Richtlinien zur Umsetzung der idealen Lösungen. Als Teil von Entwicklungsteams in nach SAFe und Scrum orientierenden Organisationen, sind wir in der Lage Abseits von der Entwicklung von Softwarelösungen im Rahmen von Iteration Reviews, Art-Syncs und anderweitige Stakeholder-Kommunikation zu übernehmen.
Durch den Einsatz vielseitiger Maßnahmen wie Code-Reviews, hohe Testabdeckung und die iterative Vorgehensweise kann entlang des Entwicklungsprozesses dein Feedback aktiv in die technische Lösung berücksichtigt werden.
Trivy in der Pipeline scannt Images auf CVEs und Misconfigurations bevor sie das Registry erreichen. Ergebnisse als Quality-Gate, nicht als Email.
Aus unserer Engineering-Praxis dokumentiert: Compute-Entscheidungen, CI/CD-Self-Hosting, Container-Sicherheit und Observability für Anwendungen.
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
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
Ein praxisorientierter Leitfaden, wie du mit Trivy Container-Images, Registries und Kubernetes-Cluster automatisiert auf Schwachstellen prüfst und Sicherheitslücken früh schließt.
Artikel lesen
Ein praxisnaher Überblick über die Verwendung von Data Collection Rules und Data Collection Endpoints in Azure zur effizienten Erfassung von Custom Logs.
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
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
Mertkan Henden
Cloud-Engineering-Berater · Heilbronn
Ich glaube nicht an Berater, die Code reviewen, ohne selbst Code zu schreiben. In meinen Projekten committe ich, lege Pull Requests an und sitze im Pair Programming. Das ist die einzige Art, Softwareentwicklung ehrlich zu beraten: durch tatsächliches Mitmachen.
— Mertkan Henden