Matthias Noback理想的なアーキテクチャについて-レイヤー、ポート、アダプター（パート2-レイヤー）

2017年、Matthias Noback（ Symfonyでの1年の著者）は、長年の実践を通じて形成された理想的な企業アプリケーションアーキテクチャに関する彼の見解を説明する3つの記事シリーズを公開しました。 。 2番目の翻訳はこの記事です。 3番目の翻訳版がまもなく利用可能になります。

私にとって、「クリーン」アーキテクチャの必須要件の1つは、アプリケーションコードをレイヤーに適切に分離することです。 レイヤー自体は何もしません。すべてのソルトは、その使用方法と、それに属するコンポーネントに課せられる制限に関係しています。 興味深い実用的なテクニックを検討する前に、少し哲学しましょう。

レイヤーが必要な理由

• レイヤーは、その下にあるものを隠す/保護するのに役立ちます。 レイヤーをフィルターバリアとして認識できます。レイヤーを介して送信されるデータは、次のレイヤーに進む前に検証する必要があります。 それらは、他のレイヤーが正しく機能できる形式に縮小する必要があります。 また、レイヤーは、より深いレイヤーのどのデータと関数を外部で使用できるかを決定します。
• レイヤーは責任を明確に示し、したがってコード内のクラスの場所を明確にします。 アプリケーション内でどのレイヤーが使用され、各レイヤーが何を担当するかについて、チーム内で厳密な合意を達成した場合、目的を知っているだけで、適切なクラスを見つけたり、新しいクラスを追加する場所を簡単に決定したりできます。
• レイヤーを使用することにより、アプリケーション開発の段階の優先順位と順序を自由に変更できます。 ビジネスロジックのコアから始めて、その上にレイヤーを重ねて、プロジェクトを順番に開発できます。 また、プロセスを逆にして、ユーザーインタラクションレイヤーを開発することから始めることができます。 このアイテムは、ORM、データベース、フレームワークなどを決定する前にほとんどのアプリケーションを開発できるため、私たちにとって非常に重要です。
• 多数の古いソフトウェアには、「スパゲッティ」コードと呼ばれるレイヤーに分割されていないコードが含まれています。プロジェクトのどの部分でも、必要なものやメソッド、構造を呼び出して使用できます。 レイヤーシステムを（正しい方法で）使用することで、懸念事項を高度に分離することができます。 これらのルールを文書化し、レビューコードとのコンプライアンスを監視すると、プロジェクトのランクへのロールダウンの速度が大幅に低下します。 ガヴノコダ 「技術的負債」

• もちろん、テストを作成します。 有能な設計されたレイヤーシステムにより、テストが非常に簡素化されます。 さまざまなタイプのテストが、さまざまなレイヤーのコードに適しています。 各テストの目的がより明確になります。 テストスイート全体がより安定し、高速になります。

  
  
  
  
  
  
  

  ただし、Twitterの警告者がいます。
  
  
  
  スパゲッティコードのOOPバージョンは、豊富なレイヤーを備えたクライミングコードです。

  
  
  
  
  
  
  

個人的には、コードラザニアに出会ったことはありませんが、多くのヌードルコードを見ました。 確かに、深刻なアーキテクチャエラーを引き起こし、アプリケーションを誤ってレイヤーに分割したコードを書いたため、いくつかの問題が発生しました。 この記事では、Vaughn Vernonの著書「Implementing Domain-Driven Design」（以下のリンク）で説明されているレイヤーの最高のセットであると思うものについて説明します。 レイヤーにはDDDへの厳密なバインドがありませんが、開発者が希望する場合はクリーンなドメインモデルを作成できます。

ディレクトリと名前空間の構造

src/



内には、各コンテキスト（ Bounded Context ）のディレクトリがあります。たとえば、アプリケーションで強調表示しています。 それらはそれぞれ、そのクラスのルート名前空間としても機能します。

各コンテキスト内で、各レイヤーのディレクトリを作成します。

• ドメイン
• 申込み
• インフラ

 src/ {BoundedContext}/ Domain/ Model/ Application/ Infrastructure/
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それぞれについて簡単に説明します。

レイヤー1-ドメイン（モデル/コア）

ドメイン層には、既知のDDDタイプ/パターンのクラスが含まれています。

• エンティティ
• 値オブジェクト
• ドメインイベント
• リポジトリ
• ドメインサービス
• 工場
• ...

Domainフォルダー内に、サブフォルダーモデルを作成します。その中に、各アグリゲート（アグリゲートルート）のディレクトリを作成します。 集約フォルダーには、それに関連付けられたすべての部分（値オブジェクト、ドメインイベント、リポジトリインターフェイスなど）が含まれます。

ドメイン層からのコードは現実世界と接触しないことに注意してください。 そして、テスト用でない場合、誰も彼のオブジェクトに直接アクセスできませんでした（これは上位層を通して行われます）。 ドメインモデルのテストは、非常にモジュール化されている必要があります。 ドメイン層はファイルシステム、ネットワーク、データベースなどと直接対話しないため、安定した独立したクリーンで高速なテストを取得できます。

レイヤー2-（ドメインのラッパー）：アプリケーションレイヤー

アプリケーション層（アプリケーション層）には、 コマンドのクラスとそのハンドラーが含まれています 。 このコマンドは、実行する必要があるものを示すものであり、プリミティブ値のみを含む通常のDTO（データ転送オブジェクト）です。 特定のコマンドの実行方法を知っているコマンドハンドラーが常に存在する必要があります。 通常、コマンドハンドラー（ アプリケーションサービスとも呼ばれます ）は、必要なすべての対話を行います-コマンドからのデータを使用して集計を作成（またはデータベースから取得）し、その上でいくつかの操作を実行し、その後集計を保存できます。

この層のコードは単体テストでカバーすることもできますが、この段階で、記述と受け入れを開始できます。 Konstantin Kudryashovによる 、このトピックの例によるモデリングに関する優れた記事を次に示します。

レイヤー3（アプリケーションのラッパー）-インフラストラクチャ

前の層で書かれたコードは、テスト以外からも呼び出されません。 そして、インフラストラクチャ層を追加した後にのみ、アプリケーションは完全に使用可能になります。

インフラストラクチャ層には、アプリケーションが実世界（ユーザーおよび外部サービス）と対話するために必要なコードが含まれています。 たとえば、レイヤーには次のコードが含まれる場合があります。

• HTTPは動作します
• データベースとの通信
• メール送信
• 押す
• 時間を取得する
• 乱数生成
• などなど

この層のコードは、統合テストでカバーする必要があります（ FreemanおよびPryceの用語）。 ここでは、実際のベース、実際のベンダーコード、実際の外部サービスなど、すべてを実際にテストします。 これにより、管理下にないがアプリケーションで使用されているもののパフォーマンスを検証できます。

フレームワークとライブラリ

外の世界（ファイルシステム、ネットワーク、またはデータベース）とやり取りするすべてのフレームワークとライブラリは、インフラストラクチャレイヤーで呼び出す必要があります。 もちろん、ドメインおよびアプリケーション層のコードには、多くの場合、ORM、HTTPクライアントなどの機能が必要です。 しかし、彼はより抽象的な依存関係を通してのみそれを使うべきです。 依存関係の規則で要求されるとおり。

依存関係ルール

依存性ルール（ The Clean ArchitectureでRobert C. Martinが策定）では、各アプリケーション層では、現在の層またはより深い層のコードのみに依存する必要があると規定されています。 つまり、ドメインコードはそれ自身にのみ依存し、アプリケーション層のコードは独自のコードまたはドメインに依存し、インフラストラクチャ層のコードはすべてに依存する可能性があります。 この規則に従って、ドメイン層のインフラストラクチャからコードに依存することはできません。

しかし、ルールの盲目的なルールに従うことは、その真の意味が何であるかを理解するのではなく、かなり愚かな仕事です。 では、なぜ依存関係ルールを使用する必要があるのでしょうか？ このルールに従うことにより、アプリケーションレイヤーとドメインレイヤーのクリーンコードが「ダーティ」で不安定で予測不可能なインフラストラクチャコードに結び付けられないことを保証します。 また、依存関係ルールを適用すると、より深いレイヤーのコードに触れたり変更したりすることなく、インフラストラクチャレイヤー内のすべてのものを置き換えることができます。これにより、コンポーネントのローテーションと移植性の豊富な機会が得られます。

モジュールの接続性を減らすこの方法は、ロバート・マーティンによって定式化されたSOLIDの文字「D」である「 依存性反転の原理 」として長い間知られています。 ほとんどのOOP言語での実用的な実装は、依存できるすべてのものにパブリックインターフェイスを割り当て（インターフェイスは抽象化されます）、このインターフェイスを実装するクラスを作成することです。 このクラスには、インターフェースにとって重要ではない詳細が含まれます。したがって、このクラスは、反転の原則で言及されている実装になります。

アーキテクチャ：遅延技術ソリューション

提案された一連のレイヤーと依存関係ルールを適用すると、開発時に多くの利点を得ることができます。

• たとえば、「使用済みDBMS」などの重要な決定を行う前に、多くのことを試すことができます。 また、同じモデルで作業する一環として、さまざまなケースでさまざまなデータベースを安全に使用できます。
• 使用するフレームワークに関する決定を延期できます。 これにより、開発の初期段階で「Symfonyアプリケーション」または「Laravelプロジェクト」になることはできません。
• フレームワークとライブラリは、モデルコードから安全な距離に配置されます。 これは、これらのフレームワークとライブラリのメジャーバージョンを更新するときに非常に役立ちます。 たとえば、Zend Framework 1の代わりにSymfony 3を使用する場合、コードの変更と労力を最小限に抑えるのにも役立ちます。

これはすべて非常に魅力的です：私はアプリケーションコンポーネントをシームレスに置き換える機能が好きです+プロジェクトの開始前（過去の経験と推測に基づいて）ではなく、アプリケーションのさまざまな部分を使用する実際のケースが明らかになり、重要なアーキテクチャ上の決定をするのが好きで、既存のニーズに基づいて適切なソリューションを選択する機能。

おわりに

前述のように、このアプリケーションバンドルオプションは、インフラストラクチャレイヤーで明確に定義されているため、どのフレームワークともうまく調和します。

一部の人々は、私のバージョンでは「レイヤーが多すぎる」と考えています。 3つのレイヤーが大きすぎると考えられる理由はわかりませんが、気になる場合は適用されたレイヤーを削除できます。 受け入れテストを書く能力を失い（システムテストと多少似たものになります-遅くて壊れやすくなります）、コードを複製せずにWebインターフェイスやコンソールコマンドなどから呼び出される同じ機能をテストすることはできません。 いずれにせよ、ビジネスロジックとインフラストラクチャの分離により、プロジェクトのアーキテクチャが大幅に改善されます。

インフラストラクチャ層をさらに詳細に検討する必要があります。 そこで、六角形のアーキテクチャ（ポートとアダプター）のトピックにスムーズに進みます。 しかし、このすべては、次の部分で。

さらに読む

• Steve FreemanとNat Pryce によるテストに導かれたオブジェクト指向ソフトウェアの成長
• ロバートC.マーティンによるスクリーミングアーキテクチャ
• ロバートC.マーティンによるクリーンアーキテクチャ
• ドメイン駆動設計の実装 、第4章：「アーキテクチャ」および第9章：「モジュール」、Vaughn Vernon著

また、レイヤーと依存関係を使用するためのルールに従うのに役立つツールであるDeptracも確認できます。