Screaming Architecture ist ein Konzept des renommierten Softwareentwicklers und Vordenkers Robert C. Martin, der oft als „Onkel Bob“ bezeichnet wird. Der Begriff mag unkonventionell klingen, stellt aber ein wirkungsvolles Prinzip im Software-Design dar, bei dem es darum geht, die Architektur eines Systems so zu gestalten, dass sie die Hauptanliegen und Anwendungsfälle der Anwendung widerspiegelt. Einfacher ausgedrückt: Die Architektur Ihrer Software sollte ihre Absicht und ihren Zweck „schreien“.

In diesem umfassenden Leitfaden untersuchen wir die Grundlagen der Screaming Architecture, wie sie sich von der traditionellen Softwarearchitektur unterscheidet, welche Bedeutung sie für domänengesteuertes Design hat und wie Sie diese Architektur in Ihren Projekten implementieren können. Wir werden auch praktische Beispiele und Szenarien behandeln, in denen Screaming Architecture die Lesbarkeit, Wartbarkeit und langfristige Skalierbarkeit des Codes verbessern kann.

Warum „schreiende“ Architektur?

Die Idee hinter Screaming Architecture ist, dass die Primärstruktur Ihrer Codebasis sofort ihren Geschäftszweck vermitteln sollte. Dies steht im Gegensatz zu traditionellen Architekturen, bei denen möglicherweise technische Frameworks, Tools oder andere sekundäre Aspekte im Vordergrund stehen. In der Screaming Architecture haben Domänenbelange Vorrang vor Implementierungsdetails.

Onkel Bob Martin veranschaulichte dies mit einem Vergleich: Stellen Sie sich vor, Sie gehen auf ein Gebäude zu und sehen seine Architektur. Ohne ein Schild zu benötigen, kann man oft erkennen, ob es sich um eine Bibliothek, eine Schule oder ein Büro handelt. Dasselbe sollte auch für die Softwarearchitektur gelten. Wenn Sie sich die Ordnerstruktur und das Design einer Anwendung ansehen, sollten Sie sofort verstehen, wozu sie dient. Wenn Sie ein Buchhaltungssystem aufbauen, sollte die Architektur „Buchhaltung“ lauten und nicht „Django“, „Spring Boot“ oder „React“.

Die Probleme mit Framework-zentrierter Architektur

In vielen Projekten überschattet der Fokus auf Technologie-Frameworks die Geschäfts- oder Domänenlogik. Sie finden Dateistrukturen wie:

controllers/

services/

repositories/

models/

Obwohl diese Verzeichnisse nützlich sind, beschreiben sie eher technische Rollen als das Kernproblem widerzuspiegeln, das die Software löst. Diese Struktur sagt Ihnen beispielsweise, dass das System MVC (Model-View-Controller) verwendet, gibt aber keinen Einblick, ob das System Finanzdaten, Benutzerverwaltung oder Inhaltserstellung verarbeitet.

Die Framework-Falle

Die Überbetonung von Frameworks führt zu Codebasen, in denen die Geschäftslogik durch technische Boilerplates verdeckt wird. Ein System, das auf Framework-Konventionen basiert, ist eng mit diesen Frameworks verknüpft. Wenn Sie jemals Frameworks oder Technologie-Stacks ändern möchten, wird Refactoring zu einem großen Aufwand. Screaming Architecture plädiert dafür, Ihre Domänenlogik sauber und getrennt zu halten, damit die Wahl des Frameworks zu einem Implementierungsdetail und nicht zur Kernstruktur Ihrer Codebasis wird.

Schreiende Architektur im Domain-Driven Design (DDD)

Domain-Driven Design (DDD) und Screaming Architecture gehen oft Hand in Hand. DDD ist ein Ansatz zur Softwareentwicklung, der die Zusammenarbeit zwischen Technik- und Fachexperten in den Vordergrund stellt und sich auf die Modellierung der Kerngeschäftslogik in einer Weise konzentriert, die eng mit dem realen Betrieb übereinstimmt.

In Screaming Architecture stehen das Domänenmodell und die Geschäftslogik im Zentrum der Anwendung, und alles andere – Frameworks, Datenbanken, Benutzeroberfläche und Dienste – wird peripher. Der Schlüsselgedanke besteht darin, dass die Codestruktur das Domänenmodell und nicht technische Implementierungsdetails widerspiegeln sollte.

So können Sie Ihr Projekt mithilfe domänengesteuerter Prinzipien so strukturieren, dass es seine Absicht „schreit“:

/src
    /accounting
        Ledger.cs
        Transaction.cs
        Account.cs
        TaxService.cs
    /sales
        Order.cs
        Invoice.cs
        Customer.cs
        DiscountPolicy.cs

In diesem Beispiel spiegeln die Ordnernamen direkt die Geschäftsbelange wider: Buchhaltung und Vertrieb. Jede domänenspezifische Klasse, wie Ledger, Transaction und Order, wird in ihrem relevanten Domänenkontext platziert. Diese Struktur macht sofort klar, worum es im System geht und wo die einzelnen Komponenten passen.

Codebeispiel 1: Eine einfache domänenzentrierte Struktur

Stellen Sie sich eine E-Commerce-Anwendung vor, die Bestellungen und Lagerbestände verwaltet. Bei Screaming Architecture sollte die Ordnerstruktur die Geschäftslogik und nicht technische Rollen widerspiegeln:

/src
    /orders
        Order.cs
        OrderService.cs
        OrderRepository.cs
    /inventory
        InventoryItem.cs
        InventoryService.cs
        InventoryRepository.cs

Hier ist ein einfaches Codebeispiel aus dem Auftragskontext:

public class Order
{
    public Guid Id { get; set; }
    public DateTime OrderDate { get; set; }
    public List Items { get; set; }
    public decimal TotalAmount { get; set; }

    public Order(List items)
    {
        Id = Guid.NewGuid();
        OrderDate = DateTime.Now;
        Items = items;
        TotalAmount = CalculateTotal(items);
    }

    private decimal CalculateTotal(List items)
    {
        return items.Sum(item => item.Price * item.Quantity);
    }
}

public class OrderItem
{
    public string ProductName { get; set; }
    public decimal Price { get; set; }
    public int Quantity { get; set; }
}

In diesem Code steht das Domänenkonzept (Order) im Vordergrund, wobei unterstützende Logik wie OrderService und OrderRepository in separaten Dateien gespeichert wird. Die Geschäftslogik (CalculateTotal) ist Teil der Order-Entität und nicht in einem Dienst oder Controller versteckt.

Technische Ablenkungen vermeiden

Frameworks und Bibliotheken sind für die Softwareentwicklung von entscheidender Bedeutung, aber sie sollten nicht diktieren, wie Ihre Geschäftslogik strukturiert ist. Screaming Architecture plädiert dafür, technische Details wie HTTP-Controller, Persistenzschichten und Datenbank-Frameworks an die Peripherie zu verlagern.

Hier ist ein Beispiel, das die traditionelle und die auffällige Architektur gegenüberstellt:

Traditionelle Architektur:

/src
    /controllers
        OrderController.cs
    /services
        OrderService.cs
    /repositories
        OrderRepository.cs
    /models
        Order.cs
        OrderItem.cs

Obwohl dies technisch korrekt ist, sagt es Ihnen nicht, wofür das System gedacht ist. Die Ordnerstruktur verrät nichts über die Domain. Handelt es sich um ein E-Commerce-System? Ein Finanzantrag? Es ist unmöglich, es zu wissen, ohne tief in den Code einzutauchen.

Schreiende Architektur:

/src
    /orders
        OrderController.cs
        OrderService.cs
        OrderRepository.cs
        Order.cs
        OrderItem.cs
    /inventory
        InventoryController.cs
        InventoryService.cs
        InventoryRepository.cs
        InventoryItem.cs

Diese Struktur verdeutlicht sofort, dass das System Bestellungen und Lagerbestände verwaltet. Wenn Sie in Zukunft weitere Domänen hinzufügen (z. B. Kunden, Zahlungen), erhalten diese einen eigenen Platz in der Architektur.

Die Rolle sauberer Architektur

Screaming Architecture stimmt oft mit den umfassenderen Clean Architecture-Prinzipien von Uncle Bob überein. Clean Architecture fördert die Trennung von Belangen und konzentriert sich darauf, sicherzustellen, dass Geschäftsregeln unabhängig von Frameworks, Benutzeroberflächen und Datenbanken sind. Screaming Architecture geht noch einen Schritt weiter und schlägt vor, dass die Struktur des Projekts die Kerngeschäftslogik offenbaren sollte.

Hier ist eine kurze Zusammenfassung von Clean Architecture:

Entitäten: Kerngeschäftsobjekte und Logik.

Anwendungsfälle: Anwendungsspezifische Geschäftsregeln.

Schnittstellen: Gateways für Frameworks und externe Systeme.

Frameworks und Treiber: Benutzeroberfläche, Datenbanken und andere externe Komponenten.

In einem Clean Architecture-Projekt sind Domänenkonzepte wie Bestellung, Kunde und Rechnung Teil der zentralen Ebene. Frameworks wie ASP.NET Core, Django oder Rails werden in die äußeren Schichten verbannt und dienen als Mechanismen zur Bereitstellung der Kernfunktionalität.

Codebeispiel 2: Anwenden von Clean Architecture in Screaming Architecture

In einer Screaming Architecture würden Sie die Anwendungsfälle und Entitäten so strukturieren, dass sie die Geschäftsdomäne widerspiegeln. Erweitern wir unser E-Commerce-Beispiel:

/src
    /orders
        CreateOrderUseCase.cs
        OrderRepository.cs
        Order.cs
        OrderItem.cs
    /inventory
        AddInventoryItemUseCase.cs
        InventoryRepository.cs
        InventoryItem.cs

Hier ist ein Beispielanwendungsfall für die Erstellung einer Bestellung:

public class CreateOrderUseCase
{
    private readonly IOrderRepository _orderRepository;
    private readonly IInventoryService _inventoryService;

    public CreateOrderUseCase(IOrderRepository orderRepository, IInventoryService inventoryService)
    {
        _orderRepository = orderRepository;
        _inventoryService = inventoryService;
    }

    public Order Execute(List items)
    {
        // Ensure all items are available in inventory
        foreach (var item in items)
        {
            _inventoryService.CheckInventory(item.ProductName, item.Quantity);
        }

        var order = new Order(items);
        _orderRepository.Save(order);
        return order;
    }
}

In diesem Beispiel ist CreateOrderUseCase Teil der Domänenlogik und interagiert mit OrderRepository und InventoryService, um die Geschäftsanforderung der Erstellung einer Bestellung zu erfüllen.

Vorteile der schreienden Architektur

Verbesserte Lesbarkeit: Jeder, der Ihre Codebasis öffnet, wird sofort verstehen, was das System tut.

Trennung von Belangen: Die Geschäftslogik bleibt von technischen Details isoliert, was es einfacher macht, Frameworks oder Technologien später zu ändern.

Skalierbarkeit: Wenn das System wächst, bleibt die Domänenstruktur konsistent und ermöglicht das einfache Hinzufügen neuer Funktionen und Module.

Wartbarkeit: Domänenlogik ist einfacher zu warten, wenn sie sauber von externen Abhängigkeiten und Frameworks getrennt ist.

Framework-unabhängig: Screaming Architecture ermöglicht es der Geschäftslogik, über verschiedene technische Stacks hinweg portierbar zu bleiben, wodurch eine enge Kopplung mit einem bestimmten Framework vermieden wird.

Kritik an Screaming Architecture

Obwohl Screaming Architecture viele Vorteile hat, ist es nicht ohne Kritikpunkte:

Wahrgenommene Komplexität: Entwickler, die mit domänengesteuertem Design nicht vertraut sind, finden die Trennung der Domänenlogik von technischen Details möglicherweise unnötig oder für kleine Anwendungen zu komplex.
2

. Overhead: Bei kleinen Projekten oder einfachen CRUD-Anwendungen kann die Implementierung von Screaming Architecture übertrieben erscheinen.

Lernkurve: Für Teams, die an Framework-First-Ansätze gewöhnt sind, erfordert die Einführung von Screaming Architecture einen Umdenken, dessen Verinnerlichung einige Zeit in Anspruch nehmen kann.

Wann man Screaming Architecture verwendet

Screaming Architecture ist besonders nützlich in den folgenden Szenarien:

Domänengesteuerte Systeme: Anwendungen mit komplexen Geschäftsregeln und Domänenlogik.

Langfristige Projekte: Systeme, von denen erwartet wird, dass sie sich im Laufe der Zeit weiterentwickeln, bei denen Skalierbarkeit und Wartbarkeit von entscheidender Bedeutung sind.

Plattformübergreifende Entwicklung: Systeme, die Frameworks oder Plattformen wechseln können, wodurch eine saubere Trennung der Geschäftslogik unerlässlich ist.

Abschluss

Screaming Architecture ist mehr als nur ein eingängiger Name; Es handelt sich um eine Philosophie, die sich dafür einsetzt, die Kerngeschäftslogik zum wichtigsten Teil Ihrer Codebasis zu machen. Durch die Konzentration auf Domänenkonzepte statt auf technische Frameworks können Entwickler Systeme erstellen, die auf lange Sicht besser lesbar, wartbar und skalierbar sind. Unabhängig davon, ob Sie an einer einfachen Webanwendung oder einem komplexen Unternehmenssystem arbeiten, kann die Einführung von Screaming Architecture zu saubererem, fokussierterem Code führen, der seinen Zweck klar zum Ausdruck bringt.

Um mehr über Screaming Architecture zu erfahren, können Sie sich einige Referenzen und zusätzliche Lektüre ansehen:

Saubere Architektur von Robert C. Martin

Domänengesteuertes Design von Eric Evans

Onkel Bobs Blog über Clean Code

Indem Sie die Prinzipien der Screaming Architecture übernehmen, können Sie Codebasen erstellen, die nicht nur funktionieren, sondern auch ihre Absicht „schreien“.