PHPでビジネスロジックを整理する際の問題を解決するか、独自の方法で解決する

こんにちは、Habr！ この記事を執筆しようとするのはこれが初めてではありませんが、長い間、経験を共有したいという要望があり、人々は尋ねます。

Habréには、さまざまなテクノロジー、言語、APIなどに関する記事がたくさんありますが、開発の最中にいるプログラマーは、これらの目的を忘れてしまうことがよくあります。以下では、開発中に最も重要なことを忘れない方法を説明します。

この記事では、さまざまなアプローチを組み合わせて、PHPでビジネスロジックを使用して作業を編成する方法について説明します。

ここでは、コントローラーレイヤーに沿ったサブジェクトロジックの拡散に関連するPHPフレームワークの問題を回避する方法について説明します。

概説したソリューションが何らかの特効薬であることを保証するものではありません。以下のすべては、一般的な問題を解決するためのオプションの1つにすぎません。 長所と短所の両方があり、このアプローチはその主なタスクに対処します。

一般的なPHPフレームワークでビジネスロジックを操作する方法について少し

通常の状況

最も人気のあるフレームワークを見ると、MVCアーキテクチャパターンに基づいています。 そのようなビジネスロジックを整理するためのツールはありませんが、すべてが単純な粗悪品を作成するためにあります。

ほとんどの場合に見られる標準的な状況は貧弱なモデルです。たとえば、UserModelクラスは単なる属性のセットであり、ロジックが含まれていません。 ビジネスロジックはコントローラーレイヤーに含まれています。

コントローラは、ドメインモデルのトランザクションスクリプトとサービス層の間の何かに変わります。 入力データを検証し、データベースからモデルエンティティを取得し、これらのエンティティのビジネスロジックを実装します。

これが間違っていると言っているのではなく、場合によっては実行可能なアプローチです。 ビジネスロジックの複雑なアーキテクチャなしで開発する場合：

1. シンプルなビジネスロジック
2. mvpを作成するには
3. プロトタイプを作成するとき

このような状況がない場合は、アーキテクチャと、このアーキテクチャのビジネスロジックの場所について考える必要があります。

洗練されたビジネスロジック

ビジネスロジックが十分に複雑な場合、2つの標準ソリューションがあります。

トランザクションスクリプト

フレームワークからビジネスロジックを分離するには、それを個別のエンティティにする価値があります。 トランザクションスクリプトを使用して、特定のユーザーリクエストを処理する多数のスクリプトセットを作成できます。

たとえば、写真をアップロードする必要がある場合は、写真をアップロードするスクリプトを作成できます。 プログラムで、別のクラスに割り当てることができます。


このアプローチの詳細については、「企業向けソフトウェアアプリケーションのアーキテクチャ」という本を参照してください。すべての長所と短所について説明しています。

ドメインモデル

ドメインモデルを実装すると、事態はさらに複雑になります。 ビジネスロジックを検討し、明確に分けられた責任を持つエンティティを区別する必要があります。 多くの落とし穴があります。これは、サブジェクトエリアのファサードを整理する方法と、ビジネスエンティティ間の接続が絡み合ったアプリケーションの作成を回避する方法などです。

「エンタープライズソフトウェアアプリケーションのアーキテクチャ」という本では、ビジネスロジックのインターフェイスとして機能し、共通の機能（UserService、OrderServiceなど）でグループ化された複数のサービスで構成されるサービスレイヤーレイヤーを導入することが提案されています。

このアプローチは、書籍「企業向けソフトウェアアプリケーションのアーキテクチャ」および私が個人的に読むことを強くお勧めする書籍「Subject-Oriented Design（DDD）」で詳細に検討されています。

私たちの物語

それがすべて始まった方法

2014年にプロジェクトを開始することが決定され、言語、技術、ライブラリなどを選択することで疑問が生じました。

選択はPHPに委ねられましたが、既存のフレームワークの使用を放棄することが決定されました。 その根拠は昔からあり、新しい装いで彼女に新しい命を与えることにしました。

私たちの組織では、テスト、ビジネスロジック、デザインパターンなどの重要性を理解しているため、私たちが管理するツールを作成し、PHPでビジネスロジックを操作できるようにすることにしました。

建築、辞書

基礎は多層アーキテクチャを採用しました。 非常に一般的で拡大されたスキームを考慮すると、3つのレイヤーを区別できます。



DDDの「Big Blue Book」、「Architecture of Corporate Software Applications」の一部を取り上げ、必要に応じてこれらすべてを処理しました。

インターフェース

インターフェースは、私たちの場合、外界から主題領域へのアクセスを担当する層です。
現在、2種類のインターフェイスがあります。

APIは、ViewとControllerで構成されるRESTful APIです。

CLI-コマンドラインからビジネスロジックを呼び出すためのインターフェイス（タスククラウン、キューのワーカーなど）。

表示する

インターフェースレイヤーのこの部分は非常に単純です。PHPプロジェクトはAPIのみであり、ユーザーインターフェースを持たないためです。

したがって、テンプレートエンジンでの作業を含める必要はなく、jsonとしてのビューを提供します。

必要に応じて、この機能を拡張し、テンプレートエンジンのサポートを追加し、さまざまな応答形式（xmlなど）を導入できますが、まだそのようなニーズはありません。 この単純化により、アーキテクチャのより重要な部分により多くの時間を割くことができました。

コントローラー

コントローラにはドメインロジックを含めないでください。 コントローラーは、単にルーターから要求を受信し、要求パラメーターを使用して適切なモデルインターフェイスを呼び出します。 彼はいくつかの小さな変換を行ってモデルと通信できますが、ビジネスロジックはありません。

モデル

モデルレイヤーでは、アーキテクチャの他の部分からの分離に違反することなく、ほぼすべてのサブジェクトエリアを展開できるエンティティの基本セットが選択されました。

モデルの3つの主な一般化要素が特定されました。

エンティティは、パラメータのリストの形式で一連の特性を持ち、関数の形式で動作するエンティティです。
コンテキストは、エンティティが相互作用するシナリオです。
リポジトリは、エンティティを格納するための抽象化です。

保管

ストレージレイヤーには、モデルのどのエンティティをデータベースに保存するか、データベースからロードする方法を知っている一連のマッパーがいます。

詳細理論

ビューコントローラー

プラットフォームのこの部分は、外部からビジネスロジック用のAPIを編成します。 これは多くの要素で構成されていますが、理解するためにいくつかを説明できます。

ルーター -適切なコントローラーメソッドへのhttp要求のルーター（すべてが標準です）。

Viewは、本質的にValueObjetとして渡されたモデル（ここでもビジネスロジックに関する多くの知識をビューに提供しません）からjsonに渡されたモデルの応答のコンバーターです。 従来のMVCビューでは、モデルから直接更新を受け取りますが、コントローラーを介して更新を受け取ります。

コントローラーは、モデルインターフェイスを隠すレイヤーです。 コントローラーは、http要求をモデルの入力パラメーターに変換し、モデルスクリプトを呼び出し、実行結果を受け取り、表示用にビューを返します。

この部分にはビジネスロジックは含まれておらず、新しいAPIを作成する必要がない限り、プロジェクト中に変更されることはありません。 コントローラー層を膨張させず、コンパクトでシンプルなままにします。

モデル

次に、ビジネスロジックを具体化する最も重要で価値のある要素について説明しましょう。
モデルの主要な要素であるエンティティ、コンテキスト、およびリポジトリをさらに詳しく考えてみましょう。

エンティティ

エンティティは、ドメインのエンティティです。たとえば、ユーザー、注文、車などです。 このようなエンティティはすべて、識別子、登録時間、価格、速度などのパラメーターを持つことができます。 基本クラスEntityのパラメーターを使用して作業を提供します。動作は、開発者によって継承クラスで既に決定されています。

Entityをデータベースに保存するにはパラメーターのリストも必要ですが、モデルはこの保存について何も知りません。 インフラストラクチャレベルでは、モデルエンティティをデータベースに保存する方法を知っているマッパーがいます。

プラットフォームのEntityの識別子は基本的なパラメーターであり、同じオブジェクトクラス内の異なるエンティティを一意に識別することができます。

より詳細には、私たちのエンティティは、エリック・エヴァンスの本で説明されているエンティティに非常に似ていると言えます。

Evansによると、ソフトウェアシステム内のオブジェクトの識別は最も重要なタスクの1つです。 Evansは、オブジェクトの属性だけで識別が達成されるわけでもないことも明確にしています。

ソフトウェアシステム内のオブジェクトを識別することができる特性と見なすことができるもの：属性、オブジェクトのクラス、動作。 エンティティを開発するとき、これらの特性から始めました。

属性はエンティティによって異なる場合がありますが、ほとんどすべての人に固有のデータベース内の識別子を識別しています。 OOPと開発言語によって提供される継承のおかげで、オブジェクトクラスを設定します。 動作は、各クラスのメソッドによって指定されます。

コンテキスト


コンテキストは、エンティティが相互作用するシナリオです。 たとえば、「ユーザー登録」には個別のコンテキストがあり、このコンテキストの動作は次のようになります。

1. コンテキストを実行し、登録用のパラメーターを渡します。 入力時に、コンテキストは単純なパラメーター（int、string、textなど）のリストを受け取ります。
2. パラメータの正確性の検証が行われます。 検証はサブジェクトエリア専用です。httpリクエストはここではチェックしません。
3. ユーザーの作成。
4. ユーザーを保存しています。 これもサブジェクト領域の一部です。主なことは、このユーザーをどこからどのように保存するかを抽象化することです。 ここでは、リポジトリを使用して保存を抽象化します。
5. メール通知を送信します。
6. コンテキスト実行の結果を返します。 結果を返すために、特別なクラスContextResultがあります。これには、コンテキストの正常な実行のサインと、結果を含むデータまたはエラーのリストが含まれます。 （View-Controllerレベルでは、モデルエラーはhttpエラーに変換されます）

コンテキストはほとんど純粋なトランザクションスクリプトですが、いくつかの例外があります。 Fowlerは、トランザクションスクリプトまたはドメインモデルを通じてビジネスロジックを実装する例を提供します。 ドメインモデルを使用する場合、共通の機能（UserService、MoneyServiceなど）に基づいてサービスが作成されるサービスレイヤーを使用することをお勧めします。 この場合、モデルエンティティを貧弱にしない場合、トランザクションスクリプトは同じサービスレイヤーとして機能できます。

たとえば、非貧弱なユーザーのユーザー関連コンテキスト（UserRegContext、UserGetContext、UserChangePasswordContextなど）のセットは、UserService（サービスレイヤー）とほぼ同等です。 多くのビジネスロジックを取り、トランザクションスクリプトと見なすことができるコンテキストがありますが、一部のエンティティ機能を呼び出すだけのコンテキストがあり、すべてのビジネスロジックがコンテキストから隠されており、ここではそれらはサービス層に近くなっています。

ここから、複雑なビジネスロジックの場合、DDDシステムアーキテクチャを純粋な形にするか、ビジネスロジックがそれほど複雑ではなく、作成、クエリ、更新などの標準スクリプトで構成される場合は、トランザクションスクリプトを使用してロジックを整理できます。

リポジトリ


リポジトリは、データベース内のエンティティのストレージ/削除/更新/検索を整理するためのビジネスロジックの抽象化です。 具体的なリポジトリは具体的なエンティティと連携します。たとえば、UserRepositoryはユーザーと連携します。

データ保存

データストレージは、マッパーを使用して行われます。 エンティティを操作するための基本的な機能を含む一般化されたマッパークラスがあります。


特定のエンティティに対して、このエンティティをデータベースに保存する方法、データベースからロードする方法、削除する方法を知っている独自の特定のマッパーが作成されます（ただし、実際にデータベースから何かを削除するのは悪い習慣なので、ほとんどの場合、削除済みとマークするだけです）変更する。

したがって、モデルにUserクラスがある場合、それに応じてUserMapperクラスが作成されます。 データベースを操作するロジックは別のレイヤーに配置され、必要に応じて簡単に置き換えることができます。

モデルエンティティはマッパーについては何も知りませんが、逆に、マッパーはすべて、モデルエンティティについて知っています。

一般化されたスキーム

ここでは、プラットフォームの非常に一般的なクラス構造について説明しますが、重要度の低い小さなクラスの多くは省略されています。

すでにおわかりのように、この基本構造のみに多くの要素が含まれています。 特定のプロジェクトでは、特定のビジネスタスクを実装するコンテキストクラス、エンティティ、リポジトリ、マッパーのホスト全体がこれらすべてに追加されます。

図のConfigとPropertyListは、誰もが使用するユーティリティエンティティです。

少し練習（ほんの少し）

理論は優れていますが、これをすべて実践する方法を見てみましょう。 財務の個人会計の申請書を作成するタスクがあるとします。 用語集のサンプル用語集（定義はペイントしません。今のところはすべてシンプルです）：お金、予算、ユーザー、製品、サービス、カレンダー

次に、明確にするために、いくつかのユーザーシナリオを作成し、非標準のものを使用します。 商品の購入-私たちの購入は、単にお金を一気に取り消すという事実であると考えます。 カレンダーに従ってサービスの支払いを設定します-これは、説明付きの定期的なお金の償却です。

エンティティを選択します：Money、Budget、User、Product、Service、Calendar。
ユーザーシナリオには3つのコンテキストがあります。

最初のコンテキストは、単に製品を購入することです。

BuyOrderContex

1. 入力（たとえば、トークン）によってデータベースからユーザーを取得します
2. 新しい製品を取得または作成します
3. 指定した金額の製品購入をセットアップするようにBudgetに指示します。

残りはより複雑で、2番目のユーザーシナリオは2つのコンテキストに分割されます。最初のシナリオではお金をいつ償却するかを設定し、2番目のシナリオでは償却を行います。

SetSchedulePayForServiceContext

1. 入力（たとえば、トークン）によってデータベースからユーザーを取得します
2. 新しいサービスを取得または作成します
3. 指定された日付のサービスサービスのお金を引き落とすカレンダーにインストールします

SchedulePayForServiceContext

1. 現在サービスに料金があるかどうかをカレンダーで確認します
2. お金を償却する必要があるサービスをロードします
3. サービス料金を請求します

すでにこの小さな例では、このアプローチの長所と短所もいくつか見られます（たとえば、異なるコンテキストでのロジックの複製。これは、本「企業ソフトウェアアプリケーションのアーキテクチャ」によく書かれています）。

おわりに

私たちの実践

機能分離

アプリケーション全体をコンテキストに分割すると、異なるサーバーに簡単に配布できます。
たとえば、ユーザー登録に関連付けられたコンテキストがあるため、このグループ全体を簡単に取得して、他のアプリケーションを中断することなく別のサーバーに転送できます。

コンテキストがコンテキストを呼び出します

コンテキストはコンテキストを引き起こす可能性があるため、複雑なチェーンを構築できます。 この手法はほとんど使用されません。 また、このアプローチには多くの落とし穴があり、そのような使用を禁止する計画があります。

クラウンタスク

実行の単位としてのコンテキストにより、どこからでも呼び出すことができます。 タスクの冠としてコンテキストを起動するロジックは、これに基づいています。

SPA

私たちのプロジェクトの1つは、クライアント部分がJavaScriptで完全に記述され、RESTfull APIを介してPHPのサーバー部分とやり取りするサイトです。 開発を開始したとき、これを計画することさえしませんでしたが、サーバーとしてのプラットフォームでSPAアプリケーションを構築するこの機会は非常に便利であることが判明しました。

テスト中

すべてのコードはテストでカバーされます。 次の2種類のテストを使用します。

1. Configなどのクラスのユニットテスト
2. APIへのリクエストに対する受け入れテスト。

計画

1. 私たちは、開発のより広範な普及を非常に欠いています。 すべては内部使用専用に書かれており、これには欠点があります。
2. 負荷の高いプロジェクトには十分な侵入がありません。 すでにいくつかの実用的な商用プロジェクトがありますが、それらを高負荷と呼ぶことはできません。
3. これまでのトランザクションを処理するロジックは、あまり考慮されていません。 この時点で、現在、カプセル化モデルにわずかな違反があります。 将来的には、データベーストランザクションから抽象化する作業単位を導入する予定です。
4. テストは主にAPI、コンテキストテストを行う計画をカバーしています。 これにより、サブジェクト領域を個別にテストできます。

結果として何を得たのか

1. インフラストラクチャからビジネスロジックを明確に分離して、アプリケーションを作成するための柔軟なプラットフォーム。
2. 私たちの開発によって完全に制御され、これは論争の的となっている問題の技術的問題を解決する上で多くの利点をもたらします。
3. 新しい開発者がプロ​​ジェクトにすばやく参加できるようにする、よく知られたデザインパターンに基づくアーキテクチャ。
4. 新しいプロジェクトでは忘れられがちで、既存のプロジェクトでの使用を模索しない、実証済みの設計アプローチを適用した豊富な経験。

結論

一般的に、完了した作業の結果に満足しています。 書かれたプラットフォームは私たちの問題を解決します。 これにより、ビジネスロジックを柔軟に実装でき、開発が大幅に簡素化されます。 改善と拡張のための多くの計画があります。

PS：PHPフレームワークのサブジェクト領域の問題を解決するためのこのようなアプローチがコミュニティにとって興味深いものである場合、オープンソースを準備して準備することができます。

PSS：すぐにすべてがすでにあるのに、なぜ自転車が必要なのかというフレーズを予見します。 これについて議論する理由はないと思います。これが私たちのアプローチであり、うまくいきました。

PSS：近親相姦のトランザクションスクリプトとドメインモデル、そしてなぜビジネス上の問題を解決するための柔軟なツールを作って入手しないのかという疑問も予見します。