はじめに

以前の記事では、アプローチの範囲を特定し、ドメイン駆動設計の基本的な方法論の原則を検討しました。

この記事では、企業システムのアーキテクチャを構築するための主な現代的なアプローチ、Supple、Screaming、Cleanの概要を説明し、完全なターンキーソリューションの形で明確な解釈を示します。

将来、各設計パターンを詳細に検討します。スコープを示し、コード例を示し、推奨されるプラクティスを強調します。その結果、既製のマイクロサービスを作成します。

柔軟なアーキテクチャ

前回の記事では、DDDにはモデルを介した実装のプラクティスが含まれているという事実に焦点を当てました。サブジェクト領域は、コードを通じて説明する必要があります。これを行う方法を理解してみましょう。

彼の本で、エリック・エヴァンスは一連の推奨設計パターンを提供し、このアプローチを柔軟であると指定しています。

アーキテクチャの柔軟性の名のもとに、多くの不要な構造がプログラムに積み上げられました。過剰なレベルの抽象化と間接的なリンクは、この問題に役立つよりも干渉する可能性が高くなります。プログラマーにそれを洗練させるように本当に促しているアーキテクチャを見てください。そして、あなたは通常非常に単純な何かを見るでしょう。しかし、シンプルというのは簡単に実行できるという意味ではありません。複雑なシステムに組み立てることができ、同時に理解しやすい要素を作成するには、かなり厳格なスタイルのアーキテクチャに従って、モデルに基づいた設計に「献身」を組み合わせる必要があります。何かを作成するだけでなく、完成したものを使用するためにも、特定の設計スキルが必要です。

Eric Evans、ドメイン駆動設計：ソフトウェアの中心にある複雑さへの取り組み

提示された一連の設計パターンは、厳密なアーキテクチャまたは既製のソリューションではなく、思考の糧です。

派手なアーキテクチャ

同様の考えが、複雑なシステムの多くの開発者や設計者の心に浮かびました。

2011年に、Robert Martin- Screaming Architectureが記事を公開しました。この記事では、コードはサブジェクト領域を記述するだけでなく、好ましくはわいせつであると叫ぶべきであると述べています。

それでは、アプリケーションのアーキテクチャは何を叫んでいますか？最上位のディレクトリ構造と最上位のパッケージのソースファイルを見ると、彼らは悲鳴を上げるか：ヘルスケアシステム、または会計システム、または在庫管理システム？それとも、Rails、Spring / Hibernate、またはASPのように叫びますか？

ロバートC.マーティン、2011年9月30日

Robertは、アプリケーションコードはフレームワークのルールに適応するのではなく、アプリケーションのアクティビティを反映する必要があると言います。フレームワークの構造によってアーキテクチャが制限されることはありません。次に、アプリケーションをデータベースまたはHTTPプロトコルに接続しないでください。これらは単なるストレージおよび配信メカニズムです。境界ボックスはツールです。フレームワークの支持者になるべきではありません。アプリケーションのテストは、その動作のロジックのテストであり、httpプロトコルのテストではありません。

きれいな建築

1年後、ロバート・マーティンによる次の記事-The Clean Architecture 。その中で、著者はコードを叫ぶ方法を教えています。いくつかのアーキテクチャを研究した後、彼は基本原則を特定します。

フレーム独立。アーキテクチャは既存のライブラリに依存しません。これにより、手を縛る制限ではなく、フレームワークをツールとして使用できます。
テスト容易性。ビジネスルールは、ユーザーインターフェイス、データベース、Webサーバー、またはその他の技術的手段なしでテストできます。
UIの独立。ユーザーインターフェイスは、システムの残りの部分を変更せずに簡単に変更できます。たとえば、ビジネスロジックを変更せずに、Webインターフェイスをコンソールインターフェイスに置き換えることができます。
データベースの独立。 OracleまたはSQL ServerをMongo、BigTable、CouchDBなどと交換できます。アプリケーションロジックをデータベースにバインドしないでください。
環境の影響からの独立。実際、ビジネスルールは外の世界について何も知らないだけです。

Habrで、 Delusions of Clean Architectureの非常に良い記事がすでに公開されています。その著者であるJeevuzは、このアプローチを理解する複雑さを非常によく噛みました。それとオリジナルの資料の両方をよく理解することを強くお勧めします。

可変アーキテクチャ

上記のアプローチの説明はそれほど単純ではありません。多数の複雑な企業システムのアーキテクチャの開発の一環として、同僚と私は、以下で説明するアプローチのかなり明確な解釈を開発しました。

コンピューターとプログラミング言語が登場する前は、紙のワークフローを使用して、複雑なビジネスロジックを持つシステムを構築および管理していました。プロセスの結果は、最終的に特定のビジネスオブジェクトを説明するドキュメントになりました。その結果、事務処理は3つの単純なアクションになりました 。

ドキュメント作成
文書処理
文書のアーカイブを操作する
文書提出

ドキュメント-特定の実際のビジネスオブジェクトの経済活動に関する情報を記録します。

ドキュメント自体は実際のビジネスオブジェクトではなく、そのModelのみであることに注意してください。現在、紙の文書は電子文書に置き換えられています。文書は、表の記録、写真、ファイル、送信された手紙、またはその他の情報です。

単語ドキュメントは今後混乱するので、今後は使用しません。DDD用語のエンティティの概念を使用します。しかし、システム全体が4つのシンプルなアクションを実行する電子文書管理システムであると想像できます。

収集
処理中
保管
代表者

アクション-ビジネスモデルの活動の構造単位。意識的な目標の比較的完了した別個の行為、ビジネスオブジェクトの個々のアクティビティの意性と意図性、エンドユーザーによって区別されます。

アクションの良い例は、演劇です。劇場は実生活のイベントをモデル化しています。この行為は劇の重要な部分です。ただし、ストーリーを完成させるには、いくつかのアクトを厳密に指定された順序で演奏する必要があります。アーキテクチャ内のこのような順序をModeと呼びます。

モード（Conduction）-特定の順序でのアクションのセット。完全な意味を持ち、エンドユーザーにとって有益です。

そのような動作モードでは、選択的な導体またはセレクタが発明されました。より正確には、特許US2870278Aが取得された「複数の動作シーケンスの選択された1つを実行するタイミング機構」。この装置は洗濯機の「ねじれ」として知られています。アーキテクチャのねじれについては、記事の冒頭で説明します。

このアーキテクチャでは、4つのモードのいずれかを選択して、不要なアクションを実行しないモードを選択できるという事実に、アプローチのばらつきが現れています。

洗濯機を起動するとき、モードを選択できます：洗濯、すすぎ、または回転。洗濯することを選択した場合、洗濯機は洗濯物をすすぎ、その後絞ることができます。キットをすすぐことで、確実に回転します。スピン-洗浄プロセスの最終アクションであり、最も「シンプル」です。このアーキテクチャでは、最も単純なActionはRepresentationであり、それから始めます。

表現

データベースや外部ソースに頼らずに純粋なビューについて話す場合、いくつかの静的な情報を出力します：HTMLページ、ファイル、jsonの形式のディレクトリ。 Codeレスポンス -200を与えることもできます：

最も単純な「ヘルスチェッカー」を書きましょう

module Health class Endpoints < Sinatra::Base get '/check' do; end end end

最も基本的な形式では、スキームは次のようになります。

代表者

叙情的な余談

Sinatraフレームワークでは、 Endpointsクラスがルーターとコントローラーの両方を1つのクラスに結合していることに注意してください。これは唯一の責任の原則に違反しますか？実際、エンドポイントはクラスではなく、クラスを通じて表現される層であり、その責任範囲はより高いレベルにあります。

OK、 ルーターとコントローラーはどうですか？クラスのセットではなく、関数の名前と実装によって表されます。通常、静的ファイルはファイルです。 1つのクラスが1つの責任を担当しますが、クラスを通じて各責任を表そうとしないでください。独断主義ではなく実用性を使用してください。

ストレージシステムを操作する

ビジネスは、アプリケーションの可用性を要求しています。適切なタイミングで使用できないのに、なぜあなたのサービスが必要なのでしょうか？データの整合性を確保するために、各処理後のビジネスオブジェクトの状態の変化を記録します。

ストレージからオブジェクトを取得するには、ビジネスロジックにアクセスする必要はありません。ホテルチェーンの活動を自動化し、レセプションにゲストマガジンを持っていると想像してください。訪問者に関する情報を表示することにしました。

  module Reception class Endpoints < Sinatra::Base # Show item get '/residents/:id', provides: :json do resident = Repository::Residents.find params[:id] status 200 serialize(resident) end end end

グラフィックダイアグラムの形式でストレージシステムを操作します。

ご覧のとおり、保存を担当するレイヤーとデータを提供する責任を負うレイヤーとの間の通信は、応答モデルを通じて実装されます。このモデルは、これらのレイヤーのいずれにも属していません。実際、これはビジネスオブジェクトであり、ビジネスロジックを担当するレイヤー上にあります。

処理中

新しいデータを導入せずにオブジェクトモデルがそのプロパティに基づいて変化するという事実に至った場合、 Interactorレイヤーに直接目を向けます。 Interactorレイヤーはアプリケーションのキーであり、個別のユースケースの形でビジネスロジック全体を記述し、 エンティティが変化します。

このユースケースを検討してください。訪問者はすでにホテルに登録されていますが、到着または出発を祝います。

  module Reception class Endpoints < Sinatra::Base # Register resident arrival post '/residents/:uid/arrival', provides: :json do result = Interactors::Arrival.call(resident_id: params[:id]) check!(result) do status 201 serialize result.data end end # Register resident departure post '/residents/:uid/departure', provides: :json do result = Interactors::Departure.call(resident_id: params[:id]) check!(result) do status 201 serialize result.data end end end end

少しやめましょう。 status

パラメーターを使用して、実装を単一のメソッドにしないのはなぜですか？ Arrival

とDeparture

インタラクターは根本的に異なります。ゲストが来た場合は、クリーニングが終了したかどうか、新しいメッセージが届いたかどうかなどを確認する必要があります。反対に、彼の出発に伴い、必要に応じてクリーニングを開始する必要があります。順番に、私たちはメッセージについても覚えていません。なぜなら、彼がホテルにいたなら、すぐに彼に電話したからです。 Interactorレイヤーで規定するのは、このすべてのビジネスロジックです。

処理中

しかし、外部からデータがある場合はどうすればよいでしょうか？ここで、 データ収集のアクションが接続されています。

データ収集

ホテルでのゲストの最初の登録中に、彼は登録フォームに記入します。このフォームは確認中です。データが正しい場合、登録ビジネスプロセスが実行されます。プロセスはデータを返します-作成された「テナント」ビジネスモデル。このモデルをゲストに読み取り可能な形式で提示します。

 module Reception class Endpoints < Sinatra::Base # Register new resident post '/residents', provides: [:json] do form = Forms::Registration.new(params) complete! form do check! form.result do status 201 serialize form.result.data end end end end end

概略的には、次のようになります。

ゲームのルール（ルール）

プロセスの観点から、変動システムはアクションに分割されます。
アクションのシーケンスはモードによって決定されます。
モードはインクリメンタルです。
より複雑なモードは、厳密に1つのアクションに対してより単純なモードを補完します。
各アクションは、1つのLayerのフレームワーク内で行われます。
各レイヤーはClassで表されます。
レイヤー内には、 Layer ClassesとResponsibility Classesがあります。
通信は、 レイヤーとIntlayerクラスの間でのみ行われます。
表現モデルは例外です。
エラー処理は、 クラス層レベルで発生する必要があります。

一般的なスキーム

このアプローチには高いエントリーしきい値があります。そのアプリケーションは、解決するタスクを明確に理解するために、設計者からの多大な経験を必要とします。複雑さは、必要なツールのさまざまな選択肢も表します。しかし、構造が複雑であるにもかかわらず、コードレベルでの実装は非常にシンプルで表現力に富んでいます。それは多くの慣習と委任状を含んでいますが。将来的には、各デザインテンプレートを個別に分析し、その作成方法を説明し、テストし、スコープを指定します。そして、それらの多様性を混同しないように、完全なマップが提供されています。