スクリーミング アーキテクチャは、有名なソフトウェア開発者で思想的リーダーであり、「ボブおじさん」とも呼ばれるロバート 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 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; }
}

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

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

フレームワークとライブラリはソフトウェア開発にとって重要ですが、ビジネス ロジックの構造を決定するものであってはなりません。 Screaming Architecture は、HTTP コントローラー、永続化レイヤー、データベース フレームワークなどの技術的な詳細を周辺部にプッシュすることを提唱しています。

伝統的なアーキテクチャと素晴らしいアーキテクチャを対比する例を次に示します:

伝統的な建築:

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

これは技術的には正しいですが、このシステムが何のためにあるのかはわかりません。フォルダー構造からはドメインについて何もわかりません。電子商取引システムですか？財務アプリケーションですか？コードを深く掘り下げずに知ることは不可能です。

叫ぶ建築:

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

この構造により、システムが注文と在庫を処理することがすぐに明確になります。将来さらにドメイン (顧客、支払いなど) を追加すると、アーキテクチャ内に専用の場所ができるようになります。

クリーン アーキテクチャの役割

Screaming Architecture は、多くの場合、Uncle Bob のより広範な Clean Architecture 原則と一致します。 Clean Architecture は、ビジネス ルールがフレームワーク、UI、データベースから独立していることを保証することに重点を置き、懸念事項の分離を促進します。 Screaming Architecture は、これをさらに一歩進めて、プロジェクトの構造が中核となるビジネス ロジックを明らかにする必要があると提案しています。

クリーン アーキテクチャについて簡単にまとめます:

エンティティ: コア ビジネス オブジェクトとロジック。

ユースケース: アプリケーション固有のビジネス ルール。

インターフェイス: フレームワークと外部システムのゲートウェイ。

フレームワークとドライバー: UI、データベース、その他の外部コンポーネント。

クリーン アーキテクチャ プロジェクトでは、注文、顧客、請求書などのドメイン概念が中央層の一部です。 ASP.NET Core、Django、Rails などのフレームワークは外側の層に追いやられ、コア機能を提供するメカニズムとして機能します。

コード例 2: スクリーミング アーキテクチャにクリーン アーキテクチャを適用する

スクリーミング アーキテクチャでは、ビジネス ドメインを反映する方法でユース ケースとエンティティを構造化します。 e コマースの例を拡張してみましょう:

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

注文を作成するための使用例を次に示します:

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

この例では、CreateOrderUseCase はドメイン ロジックの一部であり、OrderRepository および InventoryService と対話して注文作成のビジネス ニーズを満たします。

スクリーミングアーキテクチャの利点

可読性の向上: コードベースを開いた人は誰でも、システムの動作をすぐに理解できます。

懸念事項の分離: ビジネス ロジックは技術的な詳細から分離されたままなので、後からフレームワークやテクノロジーを簡単に変更できます。

スケーラビリティ: システムが成長しても、ドメイン構造は一貫したままであり、新しい機能やモジュールを簡単に追加できます。

保守性: ドメイン ロジックは、外部の依存関係やフレームワークから明確に分離されていると保守が容易になります。

フレームワークに依存しない: スクリーミング アーキテクチャにより、ビジネス ロジックはさまざまな技術スタック間で移植可能であり、特定のフレームワークとの密接な結合を回避できます。

叫ぶ建築に対する批判

Screaming Architecture には多くの利点がありますが、批判がないわけではありません:

複雑さの認識: ドメイン駆動設計に慣れていない開発者は、小規模アプリケーションではドメイン ロジックを技術的な詳細から分離することが不必要であるか、過度に複雑であると感じる可能性があります。
2

。オーバーヘッド: 小規模なプロジェクトや単純な CRUD アプリケーションでは、Screaming Architecture の実装は過剰に思えるかもしれません。

学習曲線: フレームワークファーストのアプローチに慣れているチームにとって、Screaming Architecture を採用するには考え方の転換が必要であり、それを理解するには時間がかかる可能性があります。

スクリーミングアーキテクチャを使用する場合

Screaming Architecture は、次のシナリオで特に役立ちます:

ドメイン駆動システム: 複雑なビジネス ルールとドメイン ロジックを備えたアプリケーション。

長期プロジェクト: 時間の経過とともに進化すると予想されるシステム。拡張性と保守性が重要です。

クロスプラットフォーム開発: フレームワークやプラットフォームを切り替える可能性のあるシステム。ビジネス ロジックを明確に分離することが不可欠です。

結論

Screaming Architecture は単なるキャッチーな名前ではありません。これは、コア ビジネス ロジックをコードベースの最も目立つ部分にすることを提唱する哲学です。技術的なフレームワークではなくドメインの概念に焦点を当てることで、開発者は長期的にはより読みやすく、保守しやすく、拡張性の高いシステムを構築できます。単純な Web アプリケーションで作業している場合でも、複雑なエンタープライズ システムで作業している場合でも、Screaming Architecture を採用すると、その目的を明確に表現した、よりクリーンで焦点を絞ったコードを作成できます。

Screaming Architecture について詳しく知りたい場合は、いくつかの参考資料と追加の資料をチェックしてください:

ロバート C. マーティンによるクリーン アーキテクチャ

エリック・エヴァンスによるドメイン駆動設計

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

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