yiiフレームワークに基づく階層化アーキテクチャ

外部ユーザーと内部ユーザーの両方のために、自社製品を多数販売している会社を想像してください。 ほとんどの場合、各製品は、真空中の球形の馬のように個別に存在することはできず、ある程度他のものと統合されます。 その結果、それらのすべてが一緒になって相互接続された特定の層を形成し、同時に独立して発達する生物体を形成します。 そして、おそらく、それらの開発は完全に異なるチームによって実行されます。



このような環境の良い例は、Yandex（検索、ダイレクト、マップ、メール、垂直および内部サービス）またはGoogleです。 リストされた巨人が各製品にテクノロジーを持っていることは明らかですが、中小企業を取り上げてより狭い分野で作業する場合、Web製品は同じテクノロジー（プログラミング言語、フレームワークなど）で実行されると想定できます。



私が伝えたいのは、そのような会社の製品ライン全体のアーキテクチャを整理した経験です。



当社の外部Web製品は、 オンラインバージョン 、オープンリファレンスAPI 、地図作成、フィードバックサービスです。 内部：CRM、請求、アルゴリズム計算、統計システム、

データのエクスポートとインポート。



2つの概念を導き出します。



Webインフラストラクチャ -相互接続され、関連するサブジェクトエリアで機能する、会社の一連のWeb製品。



技術基盤 -会社のWebインフラストラクチャの単一コードベース。 高レベルと低レベルの抽象化を備えたソフトウェアブロックのセットが含まれています。 高レベルブロックは、会社のサブジェクトエリアの開発者チームによって既に開発されたエンティティです。 低レベルブロックは、たとえば、ライブラリまたはフレームワークのセットです。



確かにあなたはそれぞれ複数のプロジェクトに取り組み、モジュールを実装し、次のプロジェクトで再利用しました。 これは常にスムーズに進むとは限りません。モジュールの完全に別個のバージョンが別個のSVNブランチに形成され、3番目のプロジェクトでは、モジュールの最初の2つのバージョンなどの間に何かを適用する必要があります。 言い換えると、すべての問題をリストアップしていない場合、これらは技術的基盤の品質基準です。 それらを示しましょう：

• プロジェクト間でのモジュールとコンポーネントの再利用。
• システム全体を書き換えることなく、すでに書き込まれたモジュールの機能の拡張性。
• 統一された製品展開スキーム。
• 負荷のスケーラビリティ。

私たちの目標は、このようなWebインフラストラクチャを作成することでした。 最初に始めたのは、技術基盤の準備です。 次のフレームワークとテクノロジーを選択しました。

• PHP
• アプリケーションフレームワーク-yii;
• 展開およびアプリケーション展開のフレームワーク-phing;
• 単体テストを記述するためのフレームワーク-phpUnit;
• 継続的インテグレーションシステム-Jenkins;
• 機能およびUIテスト-Selenium;
• DBMS Postgres;
• キーバリューストレージmemcached、redis;
• nginx Webサーバー。

（これらのシステムを選択した理由については説明しません。これは別の出版物のトピックです。）



技術基盤の品質基準を確保するために、階層化されたアーキテクチャを作成することにしました。

階層化アーキテクチャは、システムがレイヤと呼ばれるソフトウェアサブシステムのいくつかの順序付けられたセットで構成されるようなシステムアーキテクチャであり、次のようなものです。

• 各レイヤーでは、後続の（上位の）レイヤーのプロパティ（および存在）については何もわかりません。
• 各層は、前のすべての層の内部構造について何も知らずに、所定のインターフェースを介して直前の（下の）層と制御（アクセスコンポーネント）するために対話できます。
• 各レイヤーには特定のリソースがあり、それらは他のレイヤーから隠されているか、または抽象化の一部を次のレイヤーに直接提供します（指定されたインターフェースを介して）。

したがって、階層化されたソフトウェアシステムでは、各層は何らかのデータ抽象化を実装できます。 レイヤー間の関係は、各レイヤーの反転のパラメーターの値を下から隣接するレイヤーに送信し、この反転の結果の出力を下のレイヤーから上に送信することによって制限されます。 複数のレイヤーでグローバルデータを使用することは許可されていません。 より完全な定義は、ファウラーの作品にあります。



ネットワークとサーバーを考慮することなく、これらはそれ自体が別個のレイヤーであるため、デバイスの技術的プラットフォームを考慮します。 3つの層を区別できます。





図 1.テクノロジープラットフォームアーキテクチャのレイヤー



図 1、3つのレイヤーが強調表示されます。

• コア層 -コア層。 一般的な低レベルのライブラリとフレームワークをホストします。 たとえば、yii。
• 共有層 -複数のプロジェクトで使用できる何らかのシステム機能を実装するモジュールの層。
• アプリケーション層 -アプリケーション層。 このレベルには、特定のモジュールを持つすべてのアプリケーションがあります。

同時に、重要な点は、モジュールがアプリケーション層から共通モジュールのレベルに簡単に移動できることです。 説明は非常に簡単です。新しいプロジェクトが開始されると、通常、最も必要な機能が実装されます。 プロジェクトが発展するにつれて、他の製品とのつながりに成長し始めます（たとえば、あるプロジェクトから他のプロジェクトのカフェにレビューをプルすることを決定しました）。おそらく、他のプロジェクトにはいくつかのモジュールが必要になる場合があります。 または、プロジェクトは部分に分割され、モジュールはいくつかのアプリケーションに分割されます。



yiiの詳細を考慮して、アプリケーション層のアプリケーションのファイル構成をより詳細に検討してみましょう。

 申込み
 	フレームワーク-フレームワークはここにデプロイされます
 	 lib-コアおよび共有のコンポーネント。  Yii configのこのフォルダーの別名		
		部品
		拡張機能
		 ...
	保護された
		部品
		拡張機能
		 ...
	公開
	テーマ
	 config

図2.ファイル構成yiiアプリケーション



ご覧のとおり、アプリケーションレベルと一般レベル（共有）の両方にコンポーネントと拡張機能があります。 リポジトリからすでにアセンブルされているアプリケーションの構造は次のとおりです。 もちろん、バージョン管理システムではすべてを別々に編成できます。 たとえば、すべてがアプリケーションフォルダーに注がれるときと、拡張ライブラリへのシンボリックリンクが作成されるときの2つのビルドモードがあります。 1つは、すべてのアプリケーションを更新せずに拡張機能を個別にアップグレードできない場合、および同じマシンに複数のインスタンスを展開する場合に、異なるアプリケーションを分離するために必要です。 または、同じサーバーに異なるブランチを展開します。 2つ目は、開発者がコードを操作するときに便利です。



そこで、Webインフラストラクチャに柔軟な基盤を設定しましたが、それで十分ですか？ いや 2つの重要なものが欠落しています。

• アプリケーションアーキテクチャは、弱くメッシュ化し、共有する必要があります。
• 展開システムと製品アセンブリ。

次に、各項目について詳しく説明します。

アプリケーションアーキテクチャ

アプリケーションのアーキテクチャもレイヤーに基づいています。 次のレベルを区別します。



図3. yiiアプリケーションのレイヤー



シンコントローラーのレイヤーには最小限のロジックが含まれ、拡張APIで動作します。 ビジネスロジック層は、拡張層とデータモデル層で構成されます。 Yii拡張の層とデータモデルは非常に強力な接続性を持っています。これは図の太い矢印で示されています。



アプリケーションとシンコントローラーの間に最大の接続性が存在します。 再利用の可能性は最小限です。 ただし、他のアプリケーションでビジネスロジックを再利用できるため、再利用する必要があるため、「薄い」コントローラのレイヤーとビジネスロジックのレイヤーとの接続は、できる限り少なくする必要があります。 そして、これをYiiとその設定の柔軟性で実現できます。



構成は、必要なコンポーネントと拡張機能のセットを接続します。 拡張機能を接続する例：

'geoip' => 配列 （ 'class' => 'application.extensions.GeoIP.CGeoIP' ） 、

アプリケーションの初期化された拡張機能には、geoipキーを使用してアクセスできます。 例：

Yii :: $ app- > geoip ;

コンポーネントに初めてアクセスすると、CGeoIPクラスが初期化されます。 柔軟性はキーの存在にあります:-)いつでも設定を介して実装を置き換えることができ、アプリケーションは引き続きgeoipキーで動作します。



この柔軟性に基づいて、アプリケーションとビジネスロジックのレイヤーとの間の接続を簡単に管理できます。



特定のアプリケーションの本質を扱うロジックを拡張機能にグループ化することで、分離可能にします。 したがって、すべてのモデルは拡張機能にカプセル化され、アプリケーションコントローラーは拡張機能APIを介してデータを処理します。



拡張機能は抽象化の追加レベルであり、その背後にさまざまな拡張機能APIメソッドの内部作業に必要なデータソースを隠すことができます。



少し空想して、アプリケーションを考えてみましょう。





図4. yiiアプリケーションアーキテクチャの例



このアプリケーションはいくつかの拡張機能で動作します。 拡張機能はデータセットに対して機能し、モデルレイヤーと密接に関連しています。 重要なポイント：蜂蜜の層間の結合の程度は上から下に向かって増加します。 データモデルは最も密接に関連しています。



ここで、すべての製品に対して単一のユーザー認証サービスを作成する必要があると想像してみましょう。 このようなプロジェクトは、個別のアプリケーションとして簡単に実装できます。 新しいアプリケーションを使用するために、拡張機能-残りのクライアントUserServiceRestClientを作成します。 クライアントはUserExtension APIと同じAPIを持ちます。 明確にするために写真を見てください：





図 5



UserServiceRestClientを共有レベルに配置し、アプリケーション構成で使用されるクラスを変更します。 APIは同じであるため、コードを変更せずに実装が変更されました。 非常に柔軟です！ 他のすべてのアプリケーションも、UserServiceRestClientを使用してユーザーサービスと連携します。



そのため、アーキテクチャを把握しましたが、このアプローチではアプリケーション構成がかなり大きくなります。 手を使ってアプリケーションのすべての依存関係を登録することは、Jediにはまったくありません。 特に、プロジェクトが存続し、データベースの移行も発生する場合。 これらの問題はすべて、ビルドシステムと製品展開の助けを借りて解決できます。

展開および組み立てシステム

展開システムは何をすべきか：

• サーバー上の指定されたディレクトリにコードを配信します。
• すべてのアプリケーションの依存関係（共有レベルの拡張機能とフレームワーク）を引き出します。
• アプリケーション構成を生成します。
• SQLデータベースの移行を実行します。

また、ユニットテストの実行、プロジェクトのデバッグバージョンの作成などのタスクもすべて記載しているわけではありません。趣味の問題であり、インターネット上のこれらすべての操作にはかなりの注意が払われています。 たとえば、当社の展開システムは、nginx、Sphinx、RabbitMQなどの関連ソフトウェアを構成し、ドキュメントを作成します。 便利に！



一般に、タスクは普通です：ファイル操作、バージョン管理システムの操作、サードパーティのユーティリティ（PHPUnit、またはDoxygenなど）の起動など。設定の生成には注意が必要です。 メタ構成ファイルを使用して、テンプレートに従って作成しました。

 申込み
	保護された
		 config
		 main.php.template-yii設定テンプレート
	公開
	テーマ
	 build.prop-メタ構成ファイル
	 build.xml-phing config 

図 6



構成を生成する際、Phingはテンプレートを解析し、すべてのプレースホルダーをメタ構成ファイルで指定された適切なパラメーターに置き換えます。 とても便利でした。 すべてのアプリケーションの依存関係は、meta-configで設定されます。

##拡張機能、コンポーネントなどのリスト ##をインストールする

拡張機能= myExt、myExt2

コンポーネント= component1、component2

HELPERS = myHeper、myTextHelper

コマンド=

また、データベース、パス、ホストはmeta-configに登録されます-一般的にはそれだけです。 自動化の追加の便利さは、これらすべてのパラメーターをPhingコマンドラインに渡して再定義できることです。 そして、将来的には、たとえば、* nix OSのパッケージのアセンブリを整理するために。



したがって、メタ構成ファイルは、アプリケーション内の構成の形式と数からの抽象化レイヤーです。



その結果、Yii構成の柔軟性+ビルドシステム=簡単に構成および組み立てられた製品。

まとめ

それで、そのような作業計画をこの年に使用した経験は私たちに何を示しましたか？

• いくつかの拡張機能を再利用する必要が生じた場合、これは問題にはなりません。継続的な統合のプロセスも特別な問題なく構築されています。
• アプリケーションの機能を簡単に開発および拡張できる柔軟性が必要です。 ファンクションブロックは、コードのパフォーマンスと品質を考慮することなく、非常に迅速に実行できます。
• インターフェースを考えれば、いつでも大胆に機能を完了し、パフォーマンスを向上させ、データウェアハウスを変更し、リファクタリングを実行できます。
• アプリケーションの綿密な展開システムにより、テスト用にシステムを迅速に展開し、人間の不注意に関連する戦闘サーバーに展開する際のエラーを最小限に抑えることができます。
• 個々の機能モジュールが分離されているため、いつでも個別の開発グループを選択して作業できます。 これにより、開発部門の成長の問題を解決することができ、誰もがすべてに取り組んで、互いに干渉するだけの大きな制御されていない集合農場に変わることはありません。

PSそして、はい、ノボシビルスクとキエフでyii開発者を探しています。 一緒に来て！ :-)