Architektur

Entscheidungen, die man in zwei Jahren noch versteht

Ich verantworte die Migration einer gewachsenen .NET-Landschaft nach Azure und die Architekturentscheidungen dazu. Mich interessiert der Punkt, an dem Architektur zur Teamfrage wird: modularer Monolith, Bounded Contexts, Teststrategie bis zum Architekturtest.

Entscheidungen

Im Repo, mit Herkunft

Schwer revidierbare Entscheidungen landen als ADR neben dem Code, im Format MADR. Wer entschieden hat, wer gefragt wurde und wer informiert ist, steht im Kopf. Meine eigene Option steht darunter als eine unter mehreren, mit Herkunft, und durchläuft dieselbe Prüfung wie die anderen.

docs/decisions/0014-ereignisse-des-bestellservice-zuverlaessig-veroeffentlichen.md

---
status: proposed
date: 2026-09-18
decision-makers: Teamleitung (Freigabe), Autorin des ADR
consulted: zwei Entwickler aus dem Bestellservice, ein konsumierendes Team, Betrieb
informed: alle Teams, die die Ereignisse konsumieren
---

# Ereignisse des Bestellservice zuverlässig veröffentlichen

## Considered Options

* Transactional Outbox (Vorschlag der Teamleitung)
* Change Data Capture auf der Datenbank
* Direkt nach dem Commit veröffentlichen, mit Retry

Schwerpunkte

Fragen, die in echten Systemen auf meinem Tisch gelandet sind

Domain-Driven Design im modularen Monolithen

Die meisten Systeme, mit denen ich arbeite, sind nicht grün. Es gibt Tabellen, die drei Bedeutungen haben, und Services, die alles dürfen. Mich interessiert, wie man darin Bounded Contexts zieht, ohne das System für ein halbes Jahr anzuhalten – und wie ein modularer Monolith die Grenzen hält, ohne dass daraus verteilte Systeme werden.

Was ich dabei gelernt habe: die Grenze entsteht nicht im Modell, sondern in der Frage, welche Invariante zusammen committed werden muss. Durchgesetzt wird sie über Projekt-Templates und Architekturtests, nicht über Erinnerungen im Review.

Offene Fragen

Wie streng darf ein Aggregat in einem Team von 14 Leuten sein?

Wann ist ein eigener Context billiger als ein weiteres Modul?

Von WebForms nach Azure, Schnitt für Schnitt

Eine gewachsene .NET-Applikationslandschaft nach Azure zu bringen, ist kein Lift-and-Shift. Es ist eine Folge von Schnitten von .NET Framework und WebForms hin zu containerisierten ASP.NET-Core-Services, bei denen jeder einzelne für sich funktionieren muss.

Der erste Schnitt war ein .NET-Core-Gateway vor den Legacy-Schnittstellen. Der zweite war unbequemer: Daten, die zwei Systeme gleichzeitig besitzen wollten – und die Frage, was davon über Service Bus läuft und was in der Datenbank bleibt.

Offene Fragen

Welche Migration lohnt sich, welche darf stehen bleiben?

Wie viel Doppelbetrieb hält ein Team aus?

Plattform und Golden Paths

Unser internes Plattform-Framework bringt Projekt-Templates, modulare Komponenten und ein einheitliches internes Messaging mit. Es nimmt Boilerplate weg und hält Architektur teamweit konsistent, ohne dass jemand daran erinnern muss.

Ein Golden Path ist ein Angebot, keine Vorschrift. Pflicht sind wenige Leitplanken, der Rest muss überzeugen und als InnerSource wachsen. Daran prüfe ich unser Framework immer wieder, und nicht jede Stelle besteht.

Offene Fragen

Wo ist ein Template schon Vorschrift statt Angebot?

Wie viel Plattform braucht ein Team, bevor ein Portal wie Backstage sich lohnt?

Grundlage

Außerdem im Blick

#Cloud Native mit .NET Aspire #Infrastructure as Code mit Bicep #Conversational AI und Learning Analytics