Die Entity-Falle innerhalb einer Clean Architecture

Erstellt am: 08.11.2024

Einleitung

Moderne Software-Architekturen profitieren von klaren Strukturen und Schnittstellen. Das Zusammenspiel von Backend for Frontend (BFF), Domain Driven Design (DDD) und einer sauberen Onion/Clean Architecture ermöglicht es, komplexe Anforderungen zu erfüllen und die Wartbarkeit zu erhöhen.

Architekturüberblick

In einer typischen Architektur mit ASP.NET Core als BFF, DDD und Onion Architecture sieht der Aufbau folgendermaßen aus:

• Frontend: Das UI (z.B. Web, Mobile)
• BFF (Backend for Frontend): Spezifische API für das jeweilige Frontend, implementiert als ASP.NET Core Controller
• Application Layer: Enthält die Usecases (Application Services), die Geschäftsprozesse orchestrieren
• Domain Layer: Hier leben die eigentlichen Domänenmodelle und Regeln
• Infrastructure Layer: Technische Details wie Datenbankzugriff, externe Schnittstellen

PlantUML-Skizze

@startuml
!theme plain
actor "Frontend" as FE

package "BFF (ASP.NET Core)" {
  [OrdersController]
  [ProductsController]
}

package "Application Layer" {
  [CreateOrderUseCase]
  [GetProductListUseCase]
}

package "Domain Layer" {
  [Order]
  [Product]
}

package "Infrastructure Layer" {
  [OrderRepository]
  [ProductRepository]
}

FE --> OrdersController : HTTP Request
FE --> ProductsController : HTTP Request

OrdersController --> CreateOrderUseCase : Call Usecase
ProductsController --> GetProductListUseCase : Call Usecase

CreateOrderUseCase --> Order : Domainlogik
GetProductListUseCase --> Product : Domainlogik

CreateOrderUseCase --> OrderRepository : Persistenz
GetProductListUseCase --> ProductRepository : Persistenz
@enduml

Die Entity-Falle: Warum eine API mehr als nur CRUD sein sollte

Ein häufiges Problem in API-Designs ist die Entity-Falle: APIs werden oft nur als generische CRUD-Interfaces (Create, Read, Update, Delete) für Datenbank-Entities gebaut. Das klingt zunächst einfach, führt aber schnell zu Problemen:

• Fachlogik fehlt: Komplexere Geschäftsregeln werden umgangen oder müssen im Frontend implementiert werden.
• Unpassende Schnittstellen: Die API passt nicht zum Usecase, sondern nur zur Datenstruktur.
• Sicherheits- und Konsistenzprobleme: Validierungen und Abläufe werden nicht zentral gesteuert.
• Schwierige Erweiterungen: Neue Anforderungen führen zu Bruchstellen oder unsauberen Workarounds.

BFF und DDD lösen diese Falle, indem die API sich an den jeweiligen Usecases orientiert und die Geschäftslogik zentral im Backend verbleibt. Die Controller rufen gezielt Usecase-Handler auf, die die Domänenmodelle korrekt behandeln – statt nur rohe Entities zu bearbeiten.

Beispiel: Unterschied zwischen CRUD und Usecase-orientierter API

CRUD-API:

1POST /api/orders
2PUT /api/orders/{id}
3DELETE /api/orders/{id}
4GET /api/orders/{id}

Usecase-orientiert:

1POST /api/orders/submit    // Validiert und verarbeitet einen Bestellvorgang
2POST /api/orders/{id}/cancel  // Führt Geschäftsregeln zur Stornierung aus
3GET /api/orders/{id}/status   // Liefert Status inkl. Fachlogik

Fazit

Das Zusammenspiel von BFF, DDD und Clean Architecture sorgt für klare Verantwortungstrennung, bessere Wartbarkeit und eine API, die sich an den tatsächlichen Geschäftsprozessen orientiert. Die Entity-Falle wird so vermieden und die Software bleibt flexibel und fachlich korrekt.

#Nuget #Mediatr #Brighter #Messenger