Was ist schreiende Architektur?

Screaming Architecture ist ein Konzept, das vom renommierten Softwareentwickler und Vordenker Robert C. Martin eingeführt wurde, 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 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 Mittelpunkt der Anwendung, und alles andere – Frameworks, Datenbanken, Benutzeroberfläche und Dienste – wird zur Randerscheinung. 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äftlichen Belange wider: Buchhaltung und Vertrieb. Jede domänenspezifische Klasse, wie Ledger, Transaction und Order, wird in ihrem relevanten Domänenkontext platziert. Durch diese Struktur wird sofort klar, worum es in dem 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 widerspiegeln und nicht technische Rollen:

/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<OrderItem> Items { get; set; }
    public decimal TotalAmount { get; set; }

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

    private decimal CalculateTotal(List<OrderItem> 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 and libraries are crucial for software development, but they shouldn't dictate how your business logic is structured. Screaming Architecture advocates for pushing technical details like HTTP controllers, persistence layers, and database frameworks to the periphery.

Here’s an example that contrasts the traditional and screaming architectures:

Traditional Architecture:

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

While this is technically correct, it doesn’t tell you what the system is for. The folder structure reveals nothing about the domain. Is it an e-commerce system? A financial application? It’s impossible to know without diving deep into the code.

Screaming Architecture:

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

This structure immediately clarifies that the system handles orders and inventory. If you add more domains in the future (e.g., customers, payments), they’ll have a dedicated place in the architecture.

The Role of Clean Architecture

Screaming Architecture often aligns with Uncle Bob’s broader Clean Architecture principles. Clean Architecture promotes a separation of concerns, focusing on ensuring that business rules are independent of frameworks, UI, and databases. Screaming Architecture takes this a step further by suggesting that the project’s structure should reveal the core business logic.

Here’s a quick recap of Clean Architecture:

Entities: Core business objects and logic.

Use Cases: Application-specific business rules.

Interfaces: Gateways for frameworks and external systems.

Frameworks & Drivers: UI, databases, and other external components.

In a Clean Architecture project, domain concepts like Order, Customer, and Invoice are part of the central layer. Frameworks like ASP.NET Core, Django, or Rails are relegated to the outer layers, serving as mechanisms to deliver the core functionality.

Code Example 2: Applying Clean Architecture in Screaming Architecture

In a Screaming Architecture, you’d structure the use cases and entities in a way that reflects the business domain. Let’s extend our e-commerce example:

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

Here’s an example use case for creating an order:

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<OrderItem> 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 this example, the CreateOrderUseCase is part of the domain logic and interacts with the OrderRepository and InventoryService to fulfill the business need of creating an order.

Benefits of Screaming Architecture

Improved Readability: Anyone who opens your codebase will immediately understand what the system does.

Separation of Concerns: Business logic remains isolated from technical details, making it easier to change frameworks or technologies later.

Scalability: As the system grows, the domain structure remains consistent, allowing for easy addition of new features and modules.

Maintainability: Domain logic is easier to maintain when it’s cleanly separated from external dependencies and frameworks.

Framework Agnostic: Screaming Architecture allows the business logic to remain portable across different technical stacks, avoiding tight coupling with any particular framework.

Criticisms of Screaming Architecture

While Screaming Architecture has many benefits, it’s not without its criticisms:

Perceived Complexity: Developers unfamiliar with domain-driven design may find the separation of domain logic from technical details unnecessary or overly complex for small applications.
2

. Overhead: In small projects or simple CRUD applications, implementing Screaming Architecture may seem like overkill.

Learning Curve: For teams used to framework-first approaches, adopting Screaming Architecture requires a shift in thinking that may take time to internalize.

When to Use Screaming Architecture

Screaming Architecture is particularly useful in the following scenarios:

Domain-Driven Systems: Applications with complex business rules and domain logic.

Long-Term Projects: Systems expected to evolve over time, where scalability and maintainability are critical.

Cross-Platform Development: Systems that may switch frameworks or platforms, making a clean separation of business logic essential.

Conclusion

Screaming Architecture is more than just a catchy name; it’s a philosophy that advocates for making the core business logic the most prominent part of your codebase. By focusing on domain concepts rather than technical frameworks, developers can build systems that are more readable, maintainable, and scalable in the long run. Whether you’re working on a simple web application or a complex enterprise system, adopting Screaming Architecture can lead to cleaner, more focused code that clearly expresses its purpose.

To learn more about Screaming Architecture, you can check out some references and additional readings:

Clean Architecture by Robert C. Martin

Domain-Driven Design by Eric Evans

Uncle Bob's Blog on Clean Code

By embracing the principles of Screaming Architecture, you can create codebases that not only work but also "scream" their intent.

Das obige ist der detaillierte Inhalt vonWas ist schreiende Architektur?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!