この記事は、ソフトウェアアーキテクチャに関する一連の記事であるChronicle of Software Architectureの一部です。それらには、ソフトウェアアーキテクチャについて学んだこと、それについてどう思うか、知識をどのように使うかについて書いています。この記事の内容は、シリーズの以前の記事を読んだ方が意味があります。

大学を卒業後、高校の教師として働き始めましたが、数年前に辞めてフルタイムのソフトウェア開発者に行きました。

それ以来、「失われた」時間を回復し、できるだけ早く、できるだけ早く見つける必要があると常に感じていました。したがって、私はソフトウェアの設計とアーキテクチャに特に注意を払いながら、少し実験に関与し始め、たくさんの読み書きをしました。それが、私が研究に役立つようにこれらの記事を書いている理由です。

前回の記事では、私が学んだ多くの概念と原則について、そしてそれらについてどのように推論するかについて少し話しました。しかし、私はそれらを1つの大きなパズルの断片と考えています。

この記事では、これらすべてのフラグメントをどのようにまとめるかについて説明します。それらに名前を付ける必要があるようですので、 明示的なアーキテクチャと呼びます。さらに、これらの概念はすべて「戦闘テスト済み」であり、信頼性の高いプラットフォームで実稼働で使用されています。それらの1つは、世界中に数千のオンラインストアを持つSaaS eコマースプラットフォームであり、もう1つは、2か国で動作し、1か月あたり2,000万を超えるメッセージを処理するメッセージバスを備えた取引プラットフォームです。

システムの基本ブロック

まず、EBIとポートとアダプターのアーキテクチャーを思い出してみましょう。どちらも、アプリケーションの内部コードと外部コード、および内部コードと外部コードを接続するためのアダプターを明確に分離しています。

さらに、 Ports＆Adaptersアーキテクチャは、システム内の3つの基本的なコードブロックを明示的に定義します。

これにより、タイプに関係なく、 ユーザーインターフェイスを実行できます。
システムビジネスロジックまたはアプリケーションコア 。 UIが実際のトランザクションを行うために使用します。
アプリケーションのコアをデータベース、検索エンジン、サードパーティAPIなどのツールに接続するインフラストラクチャコード。

アプリケーションの中核は、考える最も重要なことです。このコードにより、システムで実際のアクションを実行できます。つまり、これがアプリケーションです。複数のユーザーインターフェイス（プログレッシブWebアプリケーション、モバイルアプリケーション、CLI、APIなど）を使用でき、すべてが1つのコアで実行されます。

ご想像のとおり、一般的な実行フローはUIのコードからアプリケーションコアを経由してインフラストラクチャコードに進み、アプリケーションコアに戻り、最後に応答がUIに配信されます。

ツール

最も重要なカーネルコードとはほど遠い、アプリケーションが使用するツールはまだあります。たとえば、データベースエンジン、検索エンジン、Webサーバー、CLIコンソール（後者2つは配信メカニズムでもあります）。

CLIコンソールをDBMSと同じテーマセクションに配置するのは、目的が異なるため、奇妙に思えます。しかし実際には、両方ともアプリケーションで使用されるツールです。主な違いは、CLIコンソールとWebサーバーがアプリケーションに何かを行うように指示することです 。逆に、DBMSカーネルはアプリケーションからコマンドを受け取ります 。これは、これらのツールをアプリケーションコアに接続するコードの記述方法に大きく影響するため、非常に重要な違いです。

ツールと配信メカニズムをアプリケーションコアに接続する

ツールをアプリケーションコアに接続するコードのブロックは、アダプター（ポートとアダプターアーキテクチャ）と呼ばれます。これらは、ビジネスロジックが特定のツールと相互作用することを可能にし、その逆も可能です。

アプリケーションに何かを行うように指示するアダプターは、 プライマリーまたは制御アダプターと呼ばれ、アプリケーションが何かを行うように指示するアダプターは、 セカンダリーまたは管理対象アダプターと呼ばれます。

ポート

ただし、これらのアダプタは偶然作成されたものではなく、アプリケーションコアの特定のエントリポイントportに対応するためのものです。ポートは、ツールがアプリケーションコアを使用する方法、またはその逆の方法の仕様にすぎません 。ほとんどの言語および最も単純な形式では、このポートはインターフェースになりますが、実際にはいくつかのインターフェースとDTOで構成できます。

ポート（インターフェース）はビジネスロジック内にあり、アダプターは外部にあることに注意することが重要です。このテンプレートが適切に機能するためには、ツールAPIを模倣するだけでなく、アプリケーションコアのニーズに応じてポートを作成することが非常に重要です。

プライマリまたは制御アダプター

プライマリまたは制御アダプターはポートをラップし、それを使用してアプリケーションカーネルに何をするかを指示します。 これらは、配信メカニズムからのすべてのデータをアプリケーションコアのメソッド呼び出しに変換します。

つまり、コントロールアダプターはコントローラーまたはコンソールコマンドであり、コントローラーまたはコンソールコマンドが必要とするインターフェイス（ポート）を実装するクラスを持つオブジェクトを持つコンストラクターに埋め込まれます。

より具体的な例では、ポートは、コントローラーが必要とするサービスインターフェイスまたはリポジトリインターフェイスである場合があります。その後、サービス、リポジトリ、またはリクエストの特定の実装が実装され、コントローラーで使用されます。

さらに、ポートはコマンドバスまたはクエリバスインターフェイスにすることができます。この場合、コマンドまたは要求バスの特定の実装がコントローラーに入力され、コントローラーはコマンドまたは要求を作成して、対応するバスに渡します。

セカンダリまたはマネージアダプター

ポートをラップするコントロールアダプターとは異なり、 マネージアダプターはポートとインターフェイスを実装し、ポートが必要なアプリケーションカーネルに入ります（タイプ付き）。

たとえば、データを保存する必要があるネイティブアプリケーションがあります。データ配列を保存するメソッドと、IDによってテーブル内の行を削除するメソッドを使用して、永続性インターフェイスを作成します。これ以降、アプリケーションがデータを保存または削除する必要がある場合は、コンストラクターで、定義した永続化インターフェイスを実装するオブジェクトが必要になります。

次に、このインターフェイスを実装するMySQL専用のアダプターを作成します。配列を保存し、テーブル内の行を削除するためのメソッドがあり、永続化インターフェイスが必要な場所にそれを導入します。

ある時点でデータベースプロバイダーを、たとえばPostgreSQLやMongoDBに変更する場合、PostgreSQLに固有の永続性インターフェイスを実装する新しいアダプターを作成し、古いアダプターの代わりに新しいアダプターを導入するだけです。

反転を制御する

このテンプレートの特徴的な機能は、アダプターが特定のツールと特定のポートに依存することです（インターフェースを実装することにより）。ただし、ビジネスロジックは、ビジネスロジックのニーズを満たすように設計されたポート（インターフェイス）のみに依存し、特定のアダプターやツールに依存しません。

これは、依存関係が中心に向けられていることを意味します。 つまり、アーキテクチャレベルでの制御原理の反転があります 。

ただし、 ツールAPIを模倣するだけでなく、アプリケーションコアのニーズに応じてポートを作成することが不可欠です 。

アプリケーションコアの構成

Onionアーキテクチャは、DDDレイヤーを選択し、それらをポートおよびアダプターアーキテクチャに組み込みます。これらのレベルは、ポートとアダプターの「六角形」の内部であるビジネスロジックに何らかの秩序をもたらすように設計されています。前と同様に、依存関係の方向は中心に向かっています。

アプリケーションレベル（アプリケーションレベル）

ユースケースは、1つ以上のユーザーインターフェイスによってカーネルで実行できるプロセスです。たとえば、CMSには、通常のユーザー用の1つのUI、CMS管理者用の別の独立したUI、別のCLIおよびWeb APIがあります。これらのUI（アプリケーション）は、固有または一般的なユースケースをトリガーできます。

ユースケースは、アプリケーションレベル（DDDの最初のレベルとOnionアーキテクチャ）で定義されます。

このレイヤーには、アプリケーションサービス（およびそのインターフェイス）がファーストクラスオブジェクトとして含まれ、ORMインターフェイス、検索エンジンインターフェイス、メッセージングインターフェイスなどを含むポートおよびアダプター（ポート）も含まれます。このレベルでのコマンドバスおよび/またはリクエストバスは、対応するコマンドおよびリクエストハンドラです。

アプリケーションサービスやコマンドハンドラには、ユースケース、ビジネスプロセスのデプロイメントロジックが含まれています。原則として、それらの役割は次のとおりです。

リポジトリを使用して、1つ以上のエンティティを検索します。
これらのエンティティにドメインロジックの実行を依頼します。
ストレージを使用してエンティティを再保存し、データの変更を効果的に保存します。

コマンドハンドラは、次の2つの方法で使用できます。

ユースケースを実行するためのロジックを含めることができます。
これらは、コマンドを受信し、アプリケーションサービスに存在するロジックを単純に呼び出す、アーキテクチャの接続の単純な部分として使用できます。

どのアプローチを使用するかは、コンテキストによって異なります。たとえば、次のとおりです。

すでにアプリケーションサービスがあり、コマンドバスが追加されていますか？
コマンドバスでは、クラス/メソッドをハンドラーとして指定できますか、または既存のクラスまたはインターフェースを拡張または実装する必要がありますか？

このレイヤーには、ユースケースの結果であるアプリケーションイベントの開始も含まれます。これらのイベントは、電子メールの送信、サードパーティAPIへの通知、プッシュ通知の送信、アプリケーションの別のコンポーネントに属する別のユースケースの起動など、ユースケースの副作用であるロジックをトリガーします。

ドメインレベル

さらに内部にはドメインレベルがあります。このレベルのオブジェクトには、このデータを管理するためのデータとロジックが含まれています。これらはドメイン自体に固有であり、このロジックをトリガーするビジネスプロセスとは無関係です。これらは独立しており、アプリケーションレベルを完全に認識していません。

ドメインサービス

前述したように、アプリケーションサービスの役割は次のとおりです。

リポジトリを使用して、1つ以上のエンティティを検索します。
これらのエンティティにドメインロジックの実行を依頼します。
ストレージを使用してエンティティを再保存し、データの変更を効果的に保存します。

しかし、同じまたは異なるタイプのさまざまなエンティティを含むいくつかのドメインロジックに出くわすことがあります。このドメインロジックはエンティティ自体には属しません。つまり、ロジックは直接的な責任ではありません。

したがって、最初の反応は、アプリケーションサービスのエンティティの外部にこのロジックを配置することです。ただし、これは、他の場合にはドメインロジックが再利用されないことを意味します。ドメインロジックはアプリケーションレベルの外側に留まる必要があります。

解決策は、ドメインサービスを作成することです。その役割は、一連のエンティティを取得し、それらに対していくつかのビジネスロジックを実行することです。ドメインサービスはドメインレベルに属しているため、アプリケーションサービスやリポジトリなど、アプリケーションレベルのクラスについては何も知りません。一方、他のドメインサービスと、もちろんドメインモデルオブジェクトを使用できます。

ドメインモデル

まさにその中心にあるのがドメインモデルです。この円の外側には依存せず、ドメイン内の何かを表すビジネスオブジェクトが含まれています。そのようなオブジェクトの例は、まず、エンティティ、値オブジェクト、列挙、およびドメインモデルで使用されるオブジェクトです。

ドメインイベントは、ドメインモデルにも存在します。特定のデータセットが変更されると、これらのイベントがトリガーされ、変更されたプロパティの新しい値が含まれます。これらのイベントは、たとえば、イベントソーシングモジュールでの使用に最適です。

コンポーネント

これまでのところ、レイヤーでコードを分離しましたが、これはあまりにも詳細なコード分離です。同様に、より一般的な外観で写真を見ることが重要です。私たちは、ロバート・マーティンが叫ぶアーキテクチャで表現されたアイデアに従って、コードをサブドメインと関連コンテキストに分割することについて話している[つまり、アーキテクチャは、使用するフレームワークについてではなく、アプリケーション自体について「叫ぶ」べきです。トランス。]。レイヤーではなく、機能またはコンポーネントごとにパッケージを整理することについて話します。SimonBrownは、ブログの記事「コンポーネントパッケージとアーキテクチャのテスト」でそれを非常によく説明しています。

私はコンポーネントパッケージを整理することを支持しており、Simon Brownの図を次のように恥知らずに変更したいと考えています。

コードのこれらのセクションは、前述のすべてのレイヤーを横断するものであり、これらはアプリケーションのコンポーネントです。コンポーネントの例は、請求、ユーザー、確認、またはアカウントですが、それらは常にドメインに関連付けられています。許可や認証などの制限されたコンテキストは、アダプターを作成してポートの後ろに隠す外部ツールと見なされる必要があります。

コンポーネントの切断

細かいコード単位（クラス、インターフェイス、特性、ミックスインなど）の場合と同様に、大きな単位（コンポーネント）は弱い結合と緊密な接続の恩恵を受けます。

クラスを分離するには、クラス内で依存関係を作成するのではなく、クラスに依存関係を導入し、特定のクラスの代わりに抽象化（インターフェイスおよび/または抽象クラス）に依存するように依存関係を反転させます。これは、依存クラスが使用する特定のクラスについて何も知らず、依存するクラスのフルネームへの参照を持たないことを意味します。

同様に、完全に切断されたコンポーネントでは、各コンポーネントは他のコンポーネントについて何も知りません。言い換えると、他のコンポーネントからの細かなコードブロック、さらにはインターフェイスへのリンクはありません！これは、依存関係の注入と依存関係の反転だけではコンポーネントを分離するのに十分ではないことを意味し、何らかのアーキテクチャの構築が必要になります。イベント、共通コア、結果整合性、さらにはディスカバリーサービスが必要になる場合があります。

他のコンポーネントのトリガーロジック

コンポーネント（コンポーネントB）の1つが別のコンポーネント（コンポーネントA）で何か他のことが起こるたびに何かをする必要がある場合、コンポーネントAからコンポーネントBのクラス/メソッドへの直接呼び出しを行うことはできません。その後、AはBに関連付けられます。

ただし、イベントマネージャーを使用してアプリケーションイベントをディスパッチできます。アプリケーションイベントは、Bを含むそれをリッスンするすべてのコンポーネントに配信され、Bのイベントリスナーが目的のアクションをトリガーします。つまり、コンポーネントAはイベントマネージャーに依存しますが、コンポーネントBとは別のものになります。

それでも、イベント自体がAで「生きている」場合、これはBがAの存在を認識し、それに関連付けられていることを意味します。この依存関係を削除するために、すべてのコンポーネントで共有されるアプリケーションコアの機能セット（共通コア）を備えたライブラリを作成できます。これは、両方のコンポーネントが共通のコアに依存するが、互いに分離されることを意味します。共通のコアには、アプリケーションイベントやドメインイベントなどの機能が含まれていますが、仕様オブジェクトや共有する意味のあるものを含めることもできます。同時に、共通カーネルの変更はすべてのアプリケーションコンポーネントに影響するため、最小サイズにする必要があります。さらに、多言語システム、たとえば異なる言語のマイクロサービスのエコシステムがある場合、すべてのコンポーネントが理解できるように、共通のコアは言語に依存するべきではありません。たとえば、イベントクラスを持つ一般的なカーネルの代わりに、すべてのコンポーネント/マイクロサービスがそれを解釈できるように、JSONのような汎用言語でイベントの説明（つまり、名前、プロパティ、おそらくメソッドでさえも、仕様オブジェクトではより便利ですが）が含まれますおそらく、独自の実装を自動的に生成することもあります。

このアプローチは、マイクロサービスエコシステムなどのモノリシックアプリケーションと分散アプリケーションの両方で機能します。ただし、イベントを非同期でのみ配信できる場合、このアプローチは、他のコンポーネントのトリガーロジックがすぐに動作するコンテキストでは不十分です！ここで、コンポーネントAはコンポーネントBに直接HTTP呼び出しを行う必要があります。この場合、コンポーネントを切断するには、ディスカバリサービスが必要です。コンポーネントAは、希望するアクションを開始するためのリクエストの送信先を彼女に尋ねます。または、ディスカバリサービスに要求を行います。ディスカバリサービスは、それを適切なサービスに転送し、最終的に要求者に応答を返します。このアプローチでは、コンポーネントをディスカバリサービスに関連付けますが、コンポーネントを相互に関連付けません。

他のコンポーネントからデータを取得する

ご覧のとおり、コンポーネントは「所有」していないデータを変更することはできませんが、データを要求して使用することはできます。

コンポーネントの共有データストレージ

コンポーネントが別のコンポーネントに属するデータを使用する必要がある場合（たとえば、課金コンポーネントがアカウントコンポーネントに属するクライアントの名前を使用する必要がある場合）、データストレージへのリクエストオブジェクトが含まれます。つまり、課金コンポーネントは任意のデータセットを認識できますが、他の国からの読み取り専用データを使用する必要があります。

コンポーネントの個別のデータストレージ

この場合、同じテンプレートが適用されますが、データストレージレベルはより複雑になります。独自のデータウェアハウスを備えたコンポーネントが存在するということは、各データウェアハウスに以下が含まれることを意味します。

コンポーネントが所有し、変更できるデータのセット。これが唯一の真実のソースになります。
独自に変更することはできませんが、コンポーネントの機能に必要な他のコンポーネントのデータのコピーであるデータセット。このデータは、所有者コンポーネントで変更されるたびに更新する必要があります。

各コンポーネントは、他のコンポーネントから必要なデータのローカルコピーを作成し、必要に応じて使用します。所属するコンポーネントでデータが変更されると、この所有者コンポーネントは、データの変更を伝達するドメインイベントをトリガーします。このデータのコピーを含むコンポーネントは、このドメインイベントをリッスンし、それに応じてローカルコピーを更新します。

制御フロー

上で述べたように、制御フローはユーザーからアプリケーションコア、インフラストラクチャツール、そして再びアプリケーションコア、そしてユーザーに戻ります。しかし、クラスはどのように連携しますか？誰が誰に依存していますか？それらをどのように構成しますか？

ボブおじさんのように、クリーンアーキテクチャに関する私の記事では、UMLishスキーマ管理の流れを説明しようとします...

コマンド/リクエストバスなし

コマンドバスを使用しない場合、コントローラーはアプリケーションサービスまたはクエリオブジェクトに依存します。

^{[2017/11/18追補]リクエストからデータを返すために使用するDTOを完全に見落としていたため、ここで追加しました。} ^{MorphineAdministeredに感謝します。これはスペースを示しています。}

上の図では、アプリケーションサービスのインターフェイスを使用していますが、アプリケーションサービスはアプリケーションコードの一部であるため、実際には必要ではないと言えます。ただし、完全なリファクタリングを行うことはできますが、実装を変更することは望みません。

Queryオブジェクトには、ユーザーに表示される生データを返すだけの最適化されたクエリが含まれています。このデータは、ViewModelに組み込まれているDTOに返されます。このViewModelには、何らかの種類のビューロジックが含まれている場合があり、ビューの作成に使用されます。

一方、アプリケーションサービスには、データを表示するだけでなく、システム上で何かを実行したいときに起動するユースケースロジックが含まれています。アプリケーションサービスは、開始する必要のあるロジックを含むエンティティを返すリポジトリに依存します。また、複数のエンティティ間でドメインプロセスを調整するためにドメインサービスに依存する場合がありますが、これはまれなケースです。

ユースケースの解析後、アプリケーションサービスは、ユースケースが発生したことをシステム全体に通知できます。その後、イベントをトリガーするのはイベントディスパッチャーに依存します。

持続性エンジンとリポジトリの両方でインターフェースをホストしていることに注意するのは興味深いことです。これは冗長に見えるかもしれませんが、それらは異なる目的を果たします：

PersistenceインターフェースはORMの抽象化レイヤーであるため、アプリケーションコアを変更せずにORMを交換できます。
リポジトリインターフェイスは、永続化エンジン自体の抽象化です。 MySQLからMongoDBに切り替えたいとします。この場合、永続性インターフェイスは同じままである可能性があり、同じORMを引き続き使用したい場合、永続性アダプタも同じままです。ただし、クエリ言語はまったく異なるため、同じ保存メカニズムを使用する新しいリポジトリを作成し、同じリポジトリインターフェイスを実装し、SQLの代わりにMongoDBクエリ言語を使用してクエリを作成できます。

コマンド/リクエストバス付き

アプリケーションがコマンド/リクエストバスを使用している場合、コントローラーはコマンドやリクエストだけでなくバスにも依存することを除いて、図はほぼ同じままです。ここで、コマンドまたはリクエストのインスタンスが作成され、バスに渡されます。バスは、コマンドを受信および処理するための適切なハンドラーを見つけます。

次の図では、コマンドハンドラーはアプリケーションサービスを使用しています。ただし、ほとんどの場合、ハンドラーにはユースケースのすべてのロジックが含まれるため、これは必ずしも必要ではありません。別のハンドラーで同じロジックを再利用する必要がある場合は、ハンドラーからロジックを別のアプリケーションサービスに抽出するだけです。

^{[2017/11/18追補]リクエストからデータを返すために使用するDTOを完全に見落としていたため、ここで追加しました。} ^{MorphineAdministeredに感謝します。これはスペースを示しています。}

バス、コマンド、リクエスト、ハンドラーの間に依存関係がないことに気づいたかもしれません。事実、彼らは適切な分離を確保するためにお互いについて知る必要はありません。コマンドまたはリクエストを処理するための特定のハンドラーにバスを誘導する方法は、単純な構成で構成されます。

どちらの場合も、すべての矢印（アプリケーションカーネルの境界を越える依存関係）は内側を指します。前に説明したように、これはPorts＆Adaptersアーキテクチャ、Onionアーキテクチャ、およびCleanアーキテクチャの基本的なルールです。

おわりに

いつものように、目標は、接続性の高い切断されたコードベースを取得することです。この場合、変更を簡単、迅速、安全に行うことができます。

計画は無意味ですが、計画がすべてです。 - アイゼンハワー

このインフォグラフィックはコンセプトマップです。これらの概念をすべて理解して理解することは、健全なアーキテクチャと実行可能なアプリケーションを計画するのに役立ちます。

ただし：

地図は領土ではありません。 - アルフレッド・コルジブスキー

言い換えれば、 これらは単なる推奨事項です！ アプリケーションは、私たちの知識を適用する必要がある領域、現実、特定のユースケースであり、実際のアーキテクチャがどのように見えるかを決定します！

これらすべてのパターンを理解する必要がありますが、アプリケーションが正確に必要とするもの、分離と接続性のためにどこまで行けるかを常に考えて理解する必要があります。この決定は、プロジェクトの機能要件から、アプリケーション開発のタイミング、その耐用年数、開発チームの経験など、多くの要因に依存します。

それが、私自身がこのすべてを想像する方法です。

これらのアイデアについては、次の記事で詳しく説明します。「同心円状のレイヤー以上のもの。」

DDD、六角形、タマネギ、クリーン、CQRS ...すべてをどのようにまとめるか