Zend Framework 2/3での大規模プロジェクトの編成

大規模なプロジェクトを小さな部分に分割するというアイデア-いわゆるマイクロサービスアーキテクチャ -は最近、開発者の間で人気を集めています。 これは、コードの整理と一般的な開発に適したアプローチですが、マイクロサービスアーキテクチャの人気がピークになるずっと前からコードベースの開発を始めた人はどうでしょうか。 同じ質問は、1台の強力なサーバーの負荷に慣れている人に起因する可能性があり、コードを書き換える時間はありません。 私たち自身の経験について言えば、今ではマイクロサービスを導入していますが、当初はモノリスは「モジュール式」に設計されていたため、ボリュームに関係なく保守が容易でした。 誰がコードを整理するかを気にします-catへようこそ。



Steve McConnellによる「Perfect Code」という本は、開発者が直面する主な課題はコードの複雑さを管理することであるという明るい哲学的アイデアを説明しています。 複雑さを管理する1つの方法は、分解です。 実際には、大きなコードをより単純なコードと小さなコードに分割する方法について説明します。

モジュール

Zend Frameworkでは、コードをモジュールに分割できます 。 車輪の再発明をせず、フレームワークに沿って進むために、Zend Frameworkの観点からプロジェクトを論理的にモジュールに分割したい部分を許可します。 モジュール間相互作用を最終的に決定するのは 、各モジュールがそれぞれの責任範囲でのみ機能し、他のモジュールについては何も知らないようにするためです。



各モジュールは、 コントローラー、イベントリスナー、イベントハンドラー、コマンドハンドラー、サービス、コマンド、イベント、フィルター、エンティティ、およびリポジトリーという典型的な目的を持つ一連のクラスで構成されています 。 これらのタイプのクラスはすべて、特定の階層に編成され、上位層は下位層を認識しますが、下位層は上位層について何も認識しません（そう、階層化アーキテクチャ、同じです）。



論理階層の最上部には、 コントローラーとイベントリスナーがあります。 前者はhttp-requestsの形式でユーザーからコマンドを受け取り、後者は他のモジュールのイベントに応答します。



コントローラーのすべては明確です。これは、フレームワークによって提供される標準の標準MVCコントローラーです。 イベントのリスナーであるため、すべてのモジュールに1つ作成することにしました。 リスナーアグリゲーターZend \ EventManager \ ListenerAggregateInterfaceのインターフェイスを実装し、イベントハンドラーをイベントにバインドし、各モジュールの構成から説明を取得します。





次に、各モジュールで、このモジュールのリスナーがサブスクライブするイベントのマップが設定されます。

 'events' => [ UserRegisteredEvent::class => [ UserRegisteredHandler::class, ], ]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際、モジュールはコントローラーとイベントを介して排他的に相互に通信します。

別のモジュール（ウィジェット）から何らかのデータ視覚化をプルアップする必要がある場合は、forward（）を介して別のモジュールのコントローラー呼び出しを使用し、結果を現在のビューモデルに追加します。

  $comments = $this->forward()->dispatch( 'Dashboard\Controller\Comment', [ 'action' => 'browse', 'entity' => 'blog_posts', 'entityId' => $post->getId() ] ); $view->addChild($comments, 'comments');
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

他のモジュールに何かが発生したことを通知する必要がある場合、他のモジュールが応答するようにイベントをスローします。

サービスクラス

上記のコントローラーとイベントリスナーを調べました。次に、モジュールの残りのクラス（イベントハンドラー、コマンドハンドラー、サービス、およびリポジトリー）を論理階層で占有する残りのクラスを調べます。



おそらく、後者から始めましょう。 リポジトリ。 概念的には、これは、リモートリポジトリのどこかにデータを保存できる特定の種類のエンティティを操作するためのコレクションです。 私たちの場合、データベース内。 これらは、標準のZendのTableGatewayとQueryBuilderを使用するか、ORMを接続することで実装できます。 Doctrine 2はおそらく、大きなモノリスでデータベースを操作するための最良のツールです。 そして、概念としてのリポジトリーはすでに箱から出しています。



たとえば、Doctrine 2のコンテキストでは、リポジトリは次のようになります。





リポジトリーからエンティティーを取得するには、単純なタイプのパラメーターと、データベースから選択を編成するために必要な一連のパラメーターを格納するDTOオブジェクトの両方を使用できます。 私たちの用語では、これらはフィルターと呼ばれます（呼び出されたため、リポジトリから返されたエンティティをフィルターするためです）。



サービス -アプリケーションロジックのファサードとして機能するクラス、または外部ライブラリとAPIを操作するロジックをカプセル化するクラス。



イベントハンドラーとコマンドハンドラーは、実際には1つのパブリックハンドル（）メソッドを持つサービスであり、他のテンプレートクラスでは実行されないシステムの状態の変更に関与します。 システムの状態を変更するとは、データベース、ファイルシステムに書き込み、サードパーティAPIにコマンドを送信するアクションを意味します。これにより、このAPIによって返されるデータが変更されます。



実装では、イベントハンドラーは、パラメーターとして渡されるDTOがZendイベントから継承されるという点でのみコマンドハンドラーと異なります。 一方、エンティティの形式のコマンドは、コマンドハンドラに送られます。

DTOオブジェクト

アプリケーションのロジックと、アプリケーションと外部APIおよびライブラリとの相互作用を実装する一般的なクラスは、上記で説明されています。 しかし、上記のすべての調整された作業には、「接着剤」が必要です。 このような「接着剤」は、アプリケーションのさまざまな部分間の通信を代表するデータ転送オブジェクトです。



私たちのプロジェクトでは、彼らは分離しています：



-エンティティ-ユーザー、辞書、単語など、システムの基本概念を表すデータ 基本的に、それらはデータベースから選択され、ビュースクリプトで何らかの形式で表示されます。

-イベント-イベントクラスから継承されたDTO。一部のモジュールで変更された内容に関するデータが含まれます。 コマンドハンドラーまたはイベントハンドラーによってスローできます。 そして、イベントハンドラーのみがそれらを受け入れて操作します。

-コマンド-プロセッサに必要なデータを含むDTO。 コントローラーで形成されます。 コマンドハンドラーで使用されます。

-フィルター-データベースからの選択のパラメーターを含むDTO。 誰でも形を作ることができます。 データベースクエリを作成するためにリポジトリで使用されます。

システムの各部の相互作用はどのように行われますか

システムとの相互作用は、データの読み取りとデータの変更に分けられます。 要求されたURLがデータのみを返す場合、対話は次のように構築されます。



1）生の形式のユーザーからのデータは、コントローラーのアクションに入ります。

2）ZendのInputFilterを使用して、フィルタリングして検証します。

3）それらが有効な場合、コントローラーでDTOフィルターを形成します。

4）その場合、結果データが1つのリポジトリから取得されるか、複数のリポジトリからコンパイルされるかによってすべてが異なります。 1つの場合、コントローラからリポジトリを呼び出し、3番目のステップで生成されたオブジェクトを検索メソッドに渡します。 データをコンパイルする必要がある場合は、いくつかのリポジトリのファサードとして機能するサービスを作成し、DTOを既にそこに転送します。 サービスは必要なリポジトリをプルし、そこからデータを作成します。

5）受信したデータをViewModelに渡し、その後、ビュースクリプトがレンダリングされます。

スキームを使用して、データの取得に関連するコンポーネント、およびこのデータの移動を視覚化できます。







要求されたURLがシステムの状態を変更する必要がある場合：



1）生の形式のユーザーからのデータは、コントローラーのアクションに入ります。

2）ZendのInputFilterを使用して、フィルタリングして検証します。

3）それらが有効な場合、コントローラーでDTOコマンドを作成します。

4）コントローラーでコマンドハンドラーを実行し、それにコマンドを渡します。 コマンドをコマンドバスに転送することは正しいと考えられます。 私たちは戦術的なバスとして使用しました。 しかし、最終的に、ハンドラーを直接開始することにしました。 チームバスでは、理論的にはコマンドの一部を非同期的に実行する機会を与えられた追加の抽象化レベルを受け取りましたが、チームの応答をサブスクライブしてその開発結果を見つける必要があることに不便になりました。 そして、分散システムがなく、非同期で何かを実行するため、これはルールではなく例外です。使いやすさのために抽象化を無視することにしました。

5）コマンドハンドラーは、サービスとリポジトリを使用してデータを変更し、イベントを生成して、変更されたデータをそこに渡します。 次に、イベントをイベントバスにスローします。

6）イベントハンドラーはイベントをキャッチし、その変換を実行します。 必要に応じて、行われた変換に関する情報を含むイベントもスローします。

7）すべてのイベントハンドラーの処理後、制御フローはコマンドからコントローラーに戻り、必要に応じて、コマンドハンドラーによって返された結果が取得され、ViewModelに送信されます。



概略的に、要素間の関係、およびコンポーネント間の呼び出しの発生方法を図に示します。

モジュール間相互作用の例

最も簡単で明白な例は、メールアドレスを確認するためにメールを送信するユーザーを登録することです。 このチェーンでは、2つのモジュールがテストされます。ユーザー：ユーザーに関するすべてのことを知っており、ユーザーがエンティティ（登録を含む）で操作できるようにするコードがあります。 送信方法、対象、送信先を把握しているメールモジュールもあります。



ユーザーモジュールは、登録フォームからコントローラーにデータを収集し、ユーザーをデータベースに保存します。その後、UserRegisteredEvent（$ user）イベントを生成し、保存したユーザーをそれに渡します。

 public function handle(RegisterCommand $command) { $user = clone $command->getUser(); $this->validate($user); $this->modify($user); $repo = $this->userRepository; $repo->saveAndRefresh($user); $this->eventManager->triggerEvent(new UserRegisteredEvent($user)); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

0から他のモジュールの複数のリスナーをこのイベントにサブスクライブできます。 この例では、確認ハッシュを生成するEmailモジュールがハッシュをメッセージテンプレートに転送し、生成されたメッセージをユーザーに送信します。 その後、ConfirmationEmailSentEvent（$ user）イベントが再び発生し、確認ハッシュが追加されたユーザーエンティティを置き換えます。

 protected function send(User $user) { $hash = md5($user->getEmail() . '-' . time() . '-' . $user->getName()); $user->setConfirmHash($hash); $this->emailSender->send($user); $this->eventManager->triggerEvent(new ConfirmationEmailSentEvent($user)); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その後、Userモジュールはレターを送信するイベントをキャッチし、確認ハッシュをデータベースに保存する必要があります。



このモジュール間相互作用は完了する必要があります。 はい、多くの場合、近隣のモジュールからコードを直接プルしたい場合がありますが、これはモジュールの接続性につながり、長い目で見ればルートを殺し、各モジュールを個別のプロジェクトに取り込むことができます。

結論の代わりに

したがって、実際には、コードの単純な構造化により、プロジェクトを独立した小さな部分に分離することができます。 同様の部分にカットされたプロジェクトは、ワンピースのプロジェクトよりも維持がはるかに簡単です。



さらに、このアプローチを使用してコードを開発すると、マイクロサービスアプローチへの切り替えがはるかに簡単になります。 なぜなら 1つのプロジェクトのコンテキストではありますが、マイクロサービスはすでに存在します。 独自の個別のプロジェクトで各モジュールを取り出し、Zendイベントバスをその実装に置き換えるだけで十分です。この実装は、HTTPまたはRabbitMQを介してイベントを送信します。 しかし、これは純粋に理論的な推測であり、思考の糧です。

Habrの読者のためのボーナス

オンライン講座



「オンラインコース」の独立した学習のために、英語コースに1年間アクセスできます。

アクセスするには、単にリンクをクリックしてください 。 アクティベーションコードは2017年9月1日まで有効です。



Skypeで個別に



夏期集中英語コース-アプリケーションをここに残します 。

クラスはいつでも開催できます。

35％割引コード ： 6habra25

5月22日まで有効。 支払い時に入力するか、 リンクを使用します。