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 implémenter cette architecture dans vos projets. Nous aborderons également des exemples pratiques et des scénarios dans lesquels Screaming Architecture peut améliorer la lisibilité du code, la maintenabilité et l'évolutivité à long terme.

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étier : 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 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; }
}

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

Les frameworks et les bibliothèques sont cruciaux pour le développement de logiciels, mais ils ne devraient pas dicter la façon dont votre logique métier est structurée. Screaming Architecture préconise de pousser les détails techniques tels que les contrôleurs HTTP, les couches de persistance et les cadres de bases de données vers la périphérie.

Voici un exemple qui contraste les architectures traditionnelles et criardes :

Architecture traditionnelle :

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

Bien que cela soit techniquement correct, cela ne vous dit pas à quoi sert le système. La structure des dossiers ne révèle rien sur le domaine. Est-ce un système de commerce électronique ? Une demande financière ? Il est impossible de le savoir sans plonger profondément dans le code.

Architecture hurlante :

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

Cette structure précise immédiatement que le système gère les commandes et les stocks. Si vous ajoutez d'autres domaines à l'avenir (par exemple, clients, paiements), ils auront une place dédiée dans l'architecture.

Le rôle de l'architecture propre

Screaming Architecture s'aligne souvent sur les principes plus larges de l'architecture propre d'Oncle Bob. Clean Architecture favorise une séparation des préoccupations, en veillant à ce que les règles métier soient indépendantes des frameworks, de l'interface utilisateur et des bases de données. Screaming Architecture va encore plus loin en suggérant que la structure du projet doit révéler la logique métier fondamentale.

Voici un bref récapitulatif de Clean Architecture :

Entités : objets métier et logique de base.

Cas d'utilisation : règles métier spécifiques à l'application.

Interfaces : passerelles pour les frameworks et les systèmes externes.

Frameworks et pilotes : interface utilisateur, bases de données et autres composants externes.

Dans un projet Clean Architecture, les concepts de domaine tels que Commande, Client et Facture font partie de la couche centrale. Les frameworks comme ASP.NET Core, Django ou Rails sont relégués aux couches externes, servant de mécanismes pour fournir les fonctionnalités de base.

Exemple de code 2 : application d'une architecture propre dans une architecture criante

Dans une architecture Screaming, vous structureriez les cas d'utilisation et les entités d'une manière qui reflète le domaine métier. Étendons notre exemple de commerce électronique :

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

Voici un exemple de cas d'utilisation pour créer une commande :

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

Dans cet exemple, CreateOrderUseCase fait partie de la logique de domaine et interagit avec OrderRepository et InventoryService pour répondre au besoin commercial de création d'une commande.

Avantages de l'architecture hurlante

Lisibilité améliorée : toute personne qui ouvre votre base de code comprendra immédiatement ce que fait le système.

Séparation des préoccupations : la logique métier reste isolée des détails techniques, ce qui facilite la modification ultérieure des cadres ou des technologies.

Évolutivité : à mesure que le système se développe, la structure du domaine reste cohérente, permettant l'ajout facile de nouvelles fonctionnalités et modules.

Maintenabilité : la logique de domaine est plus facile à maintenir lorsqu'elle est clairement séparée des dépendances et des frameworks externes.

Agnostique du framework : Screaming Architecture permet à la logique métier de rester portable sur différentes piles techniques, évitant ainsi un couplage étroit avec un framework particulier.

Critiques de l'architecture hurlante

Bien que Screaming Architecture présente de nombreux avantages, elle n'est pas sans critiques :

Complexité perçue : les développeurs peu familiers avec la conception axée sur le domaine peuvent trouver la séparation de la logique de domaine et des détails techniques inutile ou trop complexe pour les petites applications.
2

. Frais généraux : dans les petits projets ou les simples applications CRUD, la mise en œuvre de Screaming Architecture peut sembler exagérée.

Courbe d'apprentissage : pour les équipes habituées aux approches axées d'abord sur le framework, l'adoption de Screaming Architecture nécessite un changement de pensée qui peut prendre du temps à internaliser.

Quand utiliser l'architecture criante

Screaming Architecture est particulièrement utile dans les scénarios suivants :

Systèmes pilotés par domaine : applications avec des règles métier complexes et une logique de domaine.

Projets à long terme : les systèmes devraient évoluer au fil du temps, où l'évolutivité et la maintenabilité sont essentielles.

Développement multiplateforme : systèmes capables de changer de framework ou de plate-forme, ce qui rend essentielle une séparation claire de la logique métier.

Conclusion

Screaming Architecture est plus qu'un simple nom accrocheur ; c'est une philosophie qui préconise de faire de la logique métier principale la partie la plus importante de votre base de code. En se concentrant sur les concepts de domaine plutôt que sur les cadres techniques, les développeurs peuvent créer des systèmes plus lisibles, maintenables et évolutifs à long terme. Que vous travailliez sur une simple application Web ou sur un système d'entreprise complexe, l'adoption de Screaming Architecture peut conduire à un code plus propre et plus ciblé qui exprime clairement son objectif.

Pour en savoir plus sur Screaming Architecture, vous pouvez consulter quelques références et lectures supplémentaires :

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.