スクリーミング・アーキテクチャーとは何ですか？

スクリーミング アーキテクチャは、有名なソフトウェア開発者で思想的リーダーであり、「ボブおじさん」とも呼ばれるロバート C. マーティンによって導入されたコンセプトです。この用語は型破りに聞こえるかもしれませんが、システムのアーキテクチャにアプリケーションの主な関心事やユースケースを反映させることに焦点を当てた、ソフトウェア設計における強力な原則を表しています。簡単に言うと、ソフトウェアのアーキテクチャはその意図と目的を「叫ぶ」必要があります。

この包括的なガイドでは、スクリーミング アーキテクチャの基礎、従来のソフトウェア アーキテクチャとの対比、ドメイン駆動設計におけるその重要性、およびこのアーキテクチャをプロジェクトに実装する方法について説明します。また、Screaming Architecture によってコードの可読性、保守性、長期的なスケーラビリティが向上する実践的な例とシナリオについても説明します。

なぜ「叫ぶ」建築なのか?

Screaming Architecture の背後にある考え方は、コードベースの主要な構造がそのビジネス目的を即座に伝えるべきであるということです。これは、技術的なフレームワーク、ツール、またはその他の二次的な関心事に重点を置く可能性がある従来のアーキテクチャとは対照的です。 Screaming Architecture では、実装の詳細よりもドメインへの関心が優先されます。

ボブ・マーティンおじさんは、これを例え話で説明しました。建物に近づいて、その建築物を見たところを想像してください。標識がなくても、それが図書館なのか、学校なのか、オフィスなのかがわかることがよくあります。ソフトウェア アーキテクチャにも同じことが当てはまります。アプリケーションのフォルダー構造とデザインを見れば、それが何のためにあるのかすぐに理解できるはずです。会計システムを構築している場合、アーキテクチャは「Django」、「Spring Boot」、または「React」ではなく、「会計」を叫ぶべきです。

フレームワーク中心のアーキテクチャの問題

多くのプロジェクトでは、テクノロジー フレームワークに焦点を当てると、ビジネス ロジックやドメイン ロジックが影を落としてしまいます。次のようなファイル構造が見つかります:

controllers/

services/

repositories/

models/

これらのディレクトリは便利ですが、ソフトウェアが解決する中心的な問題を反映するものではなく、技術的な役割を説明します。たとえば、この構造は、システムが MVC (Model-View-Controller) を使用していることを示しますが、システムが財務データ、ユーザー管理、またはコンテンツ作成を処理するかどうかについては洞察を与えません。

フレームワークの罠

フレームワークを重視しすぎると、ビジネス ロジックが技術的な定型文によって曖昧になるコードベースが生成されます。フレームワークの規約に基づいて構築されたシステムは、それらのフレームワークと密接に結合されます。フレームワークやテクノロジー スタックを変更したい場合、リファクタリングは大きな労力となります。 Screaming Architecture は、ドメイン ロジックをクリーンで分離した状態に保つことを推奨しているため、フレームワークの選択は、コードベースのコア構造ではなく、実装の詳細になります。

ドメイン駆動設計 (DDD) における絶叫アーキテクチャ

ドメイン駆動設計 (DDD) とスクリーミング アーキテクチャは連携して行われることがよくあります。 DDD は、技術専門家とドメイン専門家のコラボレーションを重視したソフトウェア開発のアプローチであり、現実世界の運用と密接に連携する方法でコア ビジネス ロジックをモデル化することに重点を置いています。

Screaming Architecture では、ドメイン モデルとビジネス ロジックがアプリケーションの中心にあり、その他すべて (フレームワーク、データベース、UI、サービス) は周辺的になります。重要な考え方は、コード構造は技術的な実装の詳細ではなくドメイン モデルを反映する必要があるということです。

ドメイン駆動の原則を使用して、その意図を「叫ぶ」方法でプロジェクトを構造化する方法は次のとおりです。

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

この例では、フォルダー名はビジネス上の関心事 (会計と販売) を直接反映しています。 Ledger、Transaction、Order などの各ドメイン固有のクラスは、関連するドメイン コンテキスト内に配置されます。この構造により、システムの内容と各コンポーネントがどこに適合するかがすぐにわかります。

コード例 1: 単純なドメイン中心の構造

注文と在庫を処理する電子商取引アプリケーションを考えてみましょう。 Screaming Architecture では、フォルダー構造は技術的な役割ではなくビジネス ロジックを反映する必要があります。

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

注文コンテキストの基本的なコード例を次に示します。

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

このコードでは、ドメインの概念 (Order) が中心にあり、OrderService や OrderRepository などのサポート ロジックが別のファイルに保持されています。ビジネス ロジック (CalculateTotal) は、サービスやコントローラーに隠されているのではなく、Order エンティティの一部です。

技術的な注意散漫を避ける

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:

クリーン アーキテクチャ by Robert C. Martin

Eric Evans によるドメイン駆動設計

Uncle Bob のクリーン コードに関するブログ

Screaming Architecture の原則を採用することで、機能するだけでなく、その意図を「叫ぶ」コードベースを作成できます。

以上がスクリーミング・アーキテクチャーとは何ですか？の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。