1. Was ist Domain‑Driven Design?

DDD ist ein Architekturansatz, der darauf abzielt, Fachlogik und Softwarelogik eng miteinander zu verzahnen.

Zentrale Elemente sind:

• Domänen: Themenbereiche wie Accounting, Tax, Treasury, Controlling

• Subdomänen: z. B. Revenue Recognition, Inventory Accounting, VAT Handling

• Bounded Contexts: klar definierte fachliche Räume mit eigener Sprache, eigenen Datenmodellen, eigenen Regeln

• Ubiquitous Language: eine gemeinsame, einheitliche Fachsprache zwischen Finance & IT

DDD stellt sicher, dass technische Systeme nicht um technische Strukturen, sondern um Geschäftslogik herum gebaut werden.

Die MVA©‑Perspektive: DDD als Fundament moderner Finanzarchitekturen

Im MVA©‑Modell (Minimum Viable Audit) dient DDD als fachlicher Bauplan:

Warum?

Finance‑Prozesse wie:

• Order‑to‑Cash

• Procure‑to‑Pay

• Continuous Close

• Realtime‑Tax

• IFRS‑Bewertung

• Cashflow & Exposure Management

sind hochkomplex und lassen sich nicht in ein einziges ERP pressen.

DDD zerlegt diese Komplexität in fachlich kohärente Bausteine, die man anschließend mit Microservices, Events und Data Products implementieren kann.

2. Die vier Kernbausteine von DDD

1. Domänen (Domains)

Eine Domäne ist ein klar abgrenzbarer fachlicher Bereich, z. B.:

• Accounting

• Tax

• Treasury

• Controlling

• Billing

• Risk/Compliance

Die Domäne definiert „Worum es geht“.

2. Subdomänen

Innerhalb einer Domäne befinden sich spezialisierte Bereiche, z. B.:

• Accounting → Revenue Recognition, Ledger Posting, Asset Accounting

• Tax → VAT Engine, Withholding Tax, Transfer Pricing

• Controlling → Cost Center Planning, Profitability Analysis

Subdomänen helfen, die Architektur verdaubar zu machen.

3. Bounded Contexts

Jeder Bounded Context besitzt:

• ein eigenes Datenmodell

• eigene Regeln

• klare Verantwortlichkeiten

• eine eindeutige Ubiquitous Language

• eigene APIs oder Events

Beispiele im Finance:

• Ledger‑Context

• Tax‑Context

• Billing‑Context

• FX‑Valuation‑Context

• Tokenization‑Context

• Audit‑Context

Der Bounded Context ist der „Container“ für saubere Finanzlogik.

4. Ubiquitous Language

Alle Beteiligten sprechen dieselbe Sprache.

Beispiel:

Wenn Controlling „Revenue“ sagt, muss genau definiert sein, ob es sich um:

• Bruttoumsatz,

• Nettoumsatz,

• On‑Ship Revenue,

• IFRS‑konformes Realized Revenue

handelt.

Ohne sprachliche Klarheit entsteht Chaos — im Datenmodell, in Microservices, in AI‑Modellen, im Reporting.

3. Warum DDD für Event Driven Finance unverzichtbar ist

Moderne Finanzsysteme basieren auf:

• Event Sourcing

• Kafka‑Streaming

• Microservices

• Token‑Logiken (Triple‑Entry)

• Finance Data Mesh

• Agentic AI

Ohne DDD ist es praktisch unmöglich, diese Bausteine koordiniert, skalierbar und auditfähig zu kombinieren.

DDD sorgt dafür:

1. Events sind fachlich korrekt modelliert

Ein Event wie „InvoiceIssued“ bedeutet in jedem Kontext dasselbe.

2. Microservices sind sauber geschnitten

Tax‑Service bleibt Tax‑Service — keine Vermischung mit Ledger‑Logik.

3. Saga‑Orchestrierung ist verständlich

Jeder Kontext kennt seine Rolle in der Transaktion.

4. Tokenization & Triple‑Entry sind korrekt verortet

Der Token‑Service sitzt in einem eigenen Bounded Context.

5. Data Mesh nutzt dieselben Domänen

Datenprodukte spiegeln die DDD‑Domänen wider.

Damit entsteht eine durchgängige Architektur vom Event bis zum Datenprodukt.

4. DDD in der Praxis: Finance‑Beispiele

Order‑to‑Cash (O2C)

Bounded Contexts:

• Order Management

• Billing

• Tax

• Ledger Posting

• Payment & Settlement

• Tokenization (optional)

Jeder Kontext ist unabhängig, eigenständig deploybar, und liefert seine eigenen Events.

Continuous Close

DDD trennt:

• Bewertungslogiken

• Abgrenzungsmodelle

• Steuerlogiken

• Buchungsflüsse

Dadurch werden Abschlüsse automatisierbar.

IFRS‑Bewertungen

Komplexe IFRS‑Themen (IFRS36, IFRS9, IFRS15) lassen sich in eigene Kontexte schneiden:

• Lease Valuation Context

• Financial Instrument Valuation Context

• Revenue Allocation Context

Tax Engine

Ein perfekter DDD‑Bounded Context:

Input‑Events → Berechnung → Output‑Events → keine Seiteneffekte.

5. DDD & Data Mesh: Die perfekte Verbindung

Data Mesh nutzt Domänen, um Datenprodukte zu definieren. DDD liefert die fachliche Grundlage, auf der die Datenprodukte entstehen.

DDD = fachliche Struktur

Data Mesh = analytische Struktur

Beide gemeinsam:

• minimieren Fehlinterpretationen

• vereinfachen Governance

• schaffen AI‑Readiness

6. DDD & Microservices

Microservices ohne DDD = Chaos. Microservices mit DDD = klare, entkoppelte, skalierbare Architektur.

DDD liefert:

• den Schnitt der Services

• den Datenbesitz

• die API‑Grenzen

• die Eventdomain

• die Verantwortlichkeiten

7. DDD & Saga‑Pattern

Komplexe Transaktionen (O2C, P2P, Revenue Recognition) benötigen Orchestrierung.

DDD definiert:

• welche Kontexte beteiligt sind

• wer führt

• wer kompensiert

• welche Events veröffentlicht werden

Dadurch entsteht ein stabiler, auditierbarer Prozess.