Qu'est-ce que l'architecture qui crie ?

Screaming Architecture est un concept introduit par le célèbre développeur de logiciels et leader d'opinion Robert C. Martin, souvent surnommé « Oncle Bob ». Le terme peut sembler non conventionnel, mais il représente un principe puissant dans la conception de logiciels, visant à faire en sorte que l'architecture d'un système reflète les principales préoccupations et cas d'utilisation de l'application. En termes plus simples, l'architecture de votre logiciel doit « crier » son intention et son objectif.

Dans ce guide complet, nous explorerons les principes fondamentaux de Screaming Architecture, comment elle contraste avec l'architecture logicielle traditionnelle, son importance dans la conception axée sur le domaine et comment vous pouvez mettre en œuvre cette architecture dans vos projets. Nous aborderons également des exemples pratiques et des scénarios dans lesquels Screaming Architecture peut améliorer la lisibilité, la maintenabilité et l'évolutivité à long terme du code.

Pourquoi une architecture « hurlante » ?

L'idée derrière Screaming Architecture est que la structure principale de votre base de code doit immédiatement transmettre son objectif commercial. Cela contraste avec les architectures traditionnelles, qui peuvent mettre l'accent sur les cadres techniques, les outils ou d'autres préoccupations secondaires. Dans Screaming Architecture, les préoccupations du domaine ont priorité sur les détails de mise en œuvre.

Oncle Bob Martin a illustré cela par une analogie : imaginez marcher jusqu'à un bâtiment et voir son architecture. Sans avoir besoin d’un panneau, vous pouvez souvent savoir s’il s’agit d’une bibliothèque, d’une école ou d’un bureau. La même chose devrait s’appliquer à l’architecture logicielle. Lorsque vous examinez la structure des dossiers et la conception d’une application, vous devez immédiatement comprendre à quoi elle sert. Si vous construisez un système de comptabilité, l'architecture doit crier « comptabilité », et non « Django », « Spring Boot » ou « React ».

Les problèmes liés à l'architecture centrée sur le framework

Dans de nombreux projets, l'accent mis sur les cadres technologiques éclipse la logique métier ou de domaine. Vous trouverez des structures de fichiers telles que :

controllers/

services/

repositories/

models/

Bien que ces répertoires soient utiles, ils décrivent les rôles techniques plutôt que de refléter le problème principal résolu par le logiciel. Par exemple, cette structure vous indique que le système utilise MVC (Model-View-Controller) mais ne donne aucune idée si le système gère les données financières, la gestion des utilisateurs ou la création de contenu.

Le piège du cadre

L'accent excessif mis sur les frameworks aboutit à des bases de code où la logique métier est obscurcie par un passe-partout technique. Un système construit autour de conventions-cadres devient étroitement couplé à ces cadres. Si jamais vous souhaitez changer de framework ou de pile technologique, la refactorisation devient un effort majeur. Screaming Architecture préconise de garder votre logique de domaine propre et séparée, de sorte que le choix du framework devient un détail d'implémentation plutôt que la structure de base de votre base de code.

Architecture criante dans la conception pilotée par domaine (DDD)

Domain-Driven Design (DDD) et Screaming Architecture vont souvent de pair. DDD est une approche du développement logiciel qui met l'accent sur la collaboration entre les experts techniques et du domaine, et se concentre sur la modélisation de la logique métier de base d'une manière qui s'aligne étroitement sur les opérations du monde réel.

Dans Screaming Architecture, le modèle de domaine et la logique métier sont au centre de l'application, et tout le reste (frameworks, bases de données, interface utilisateur et services) devient périphérique. L'idée clé est que la structure du code doit refléter le modèle de domaine plutôt que les détails techniques de mise en œuvre.

Voici comment structurer votre projet de manière à « crier » son intention en utilisant des principes axés sur le domaine :

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

Dans cet exemple, les noms de dossiers reflètent directement les préoccupations métiers : comptabilité et ventes. Chaque classe spécifique à un domaine, comme Ledger, Transaction et Order, est placée dans son contexte de domaine pertinent. Cette structure montre immédiatement en quoi consiste le système et où se situe chaque composant.

Exemple de code 1 : une structure simple centrée sur le domaine

Envisagez une application de commerce électronique qui gère les commandes et l'inventaire. Avec Screaming Architecture, la structure des dossiers doit refléter la logique métier plutôt que les rôles techniques :

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

Voici un exemple de code de base issu du contexte des commandes :

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; }
}

Dans ce code, le concept de domaine (Order) est au premier plan, avec une logique de support comme OrderService et OrderRepository conservée dans des fichiers séparés. La logique métier (CalculateTotal) fait partie de l'entité Order, plutôt que cachée dans un service ou un contrôleur.

Éviter les distractions techniques

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:

Architecture propre par Robert C. Martin

Conception basée sur le domaine par Eric Evans

Le blog de l'oncle Bob sur le code propre

En adoptant les principes de Screaming Architecture, vous pouvez créer des bases de code qui non seulement fonctionnent, mais qui « crient » également leur intention.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!