前回の記事では、 DDD の階層型アーキテクチャに焦点を当てましたが、同時にマイクロサービス アーキテクチャのモデルには実はさまざまな種類があることにも触れましたが、お気づきいただけたでしょうか。
これらのアーキテクチャモデルは、実際のアプリケーションにおいて高い参考価値があります。そこで今日は、DDD レイヤード アーキテクチャ (詳細を忘れた場合)、ニート アーキテクチャ、およびヘキサゴナル アーキテクチャの 3 つのアーキテクチャ モデルをまとめ、比較および分析し、それらを有効に活用する方法を確認し、高凝集性と低凝集性の設計に役立てます。ミドルプラットフォームとマイクロサービスアーキテクチャを結合します。
クリーンなアーキテクチャ
クリーン アーキテクチャは「オニオン アーキテクチャ」とも呼ばれます。なぜオニオンアーキテクチャと呼ばれるのでしょうか? 下の写真を見ていただければ理解していただけると思います。すっきりとした建築の層は玉ねぎのスライスのようなもので、層状のデザインのアイデアを体現しています。
クリーンなアーキテクチャでは、同心円はアプリケーション ソフトウェアのさまざまな部分を表します。内側から外側に向かって、ドメイン モデル、ドメイン サービス、アプリケーション サービス、およびユーザー インターフェイスやインフラストラクチャなどの変更が容易な最も周辺のコンテンツが含まれます。
クリーン アーキテクチャの最も重要な原則は、各レイヤーの依存関係を定義する依存関係の原則です。依存関係が低いほど、コード レベルは高く、コア機能が多くなります。外側の円のコード依存関係は内側の円のみを指すことができ、内側の円は外側の円について何も知る必要はありません。
オニオン アーキテクチャでは、各層の機能は次のように分割されます。
- ドメイン モデルは、ドメイン内のコア ビジネス ロジックを実現し、エンタープライズ レベルのビジネス ルールをカプセル化します。ドメイン モデルの本体はエンティティであり、エンティティはメソッドを備えたオブジェクト、またはデータ構造とメソッドのコレクションにすることができます。
- ドメイン サービスは、複数のエンティティが関与する複雑なビジネス ロジックを実装します。
- アプリケーション サービスは、アプリケーション固有のビジネス プロセス ルールを含むユーザー操作に関連するサービスの構成とオーケストレーションを実装し、システムのすべてのユース ケースをカプセル化して実装します。
- 最外層は主に適応能力を提供し、適応能力は能動的適応と受動的適応に分けられる。アクティブな適応は主に、外部ユーザー、Web ページ、バッチ処理、自動テストの内部ビジネス ロジック アクセスへの適応を実現します。受動的適応は主に、データベース、キャッシュ、ファイル システム、メッセージ ミドルウェアなどの基本リソースにアクセスするためのコア ビジネス ロジックの適応を実現することです。
- 赤丸内のドメイン モデル、ドメイン サービス、アプリケーション サービスは、ソフトウェアの中核となるビジネス機能を形成します。
六角形の建築
ヘキサゴナル アーキテクチャは、「ポート アダプタ アーキテクチャ」とも呼ばれます。マイクロサービス アーキテクチャの起源をたどると、一般にヘキサゴナル アーキテクチャが関係します。
ヘキサゴナル アーキテクチャの中心的なアイデアは、アプリケーションがポートを通じて外部と対話するということです。これが、マイクロサービス アーキテクチャで API ゲートウェイが普及した主な理由でもあると思います。
つまり、下図のヘキサゴナル アーキテクチャにおいて、赤丸で囲んだコア ビジネス ロジック (アプリケーションおよびドメイン モデル) が外部リソース (APP、Web アプリケーション、データベース リソースなど) から完全に分離されており、アダプターを介してのみ対話します。ビジネス ロジックとユーザー インターフェイス間のコード インターリーブの問題を解決し、フロント エンドとバック エンドの適切な分離を実現します。六角形アーキテクチャの各層の依存関係は、外側から内側に依存するニート アーキテクチャと同じです。
六角形アーキテクチャでは、システムが内側の六角形と外側の六角形の 2 つの層に分割され、これら 2 つの層の機能は次のように分割されます。
- 赤い円内の六角形は、アプリケーションのコア ビジネス ロジックを実装します。
- 外側の六角形は、外部アプリケーション、ドライバー、基本リソースの対話とアクセスを完了し、API アクティブ アダプテーションの形式でフロントエンド アプリケーションにサービスを提供し、依存関係反転パッシブ アダプテーションの形式で基本リソースへのリソース アクセスを実装します。
ヘキサゴナル アーキテクチャの 1 つのポートは複数の外部システムに対応することができ、異なる外部システムは異なるアダプタを使用することができ、アダプタはプロトコル変換を担当します。
これにより、ユーザー、プログラム、自動テスト、バッチ スクリプトがアプリケーションを一貫した方法で使用できるようになります。
3 つのマイクロサービス アーキテクチャ モデルの比較と分析
DDD 階層化アーキテクチャ、整列アーキテクチャ、および六角形アーキテクチャのアーキテクチャ モデルは異なる表現を持っていますが、その外観に混同しないでください。これら 3 つのアーキテクチャ モデルの設計思想は、まさにマイクロサービス アーキテクチャにおける高凝集性と低結合性の原理です。それらを見事に具現化したものであり、そこに光るのがドメインモデルを中心とした設計思想です。
上の図を見て、図と組み合わせて 3 つのアーキテクチャ モデルを分析してみましょう。
図の赤いワイヤーフレームに注目してください。これらは 3 つのアーキテクチャすべてに存在する非常に重要な境界線です。その機能は、コア ビジネス ロジックを外部アプリケーションや基本リソースから分離することです。
コア ビジネス ロジックは主に赤いボックス内に実装されていますが、コア ビジネス ロジックも異なり、ドメイン モデル機能に属するビジネス ロジックもあれば、ユーザー指向のユース ケースおよびプロセス オーケストレーション機能に属するビジネス ロジックもあります。この機能の違いに応じて、これら 3 つのアーキテクチャでアプリケーション層とドメイン層を分割し、異なるビジネス ロジックを実行します。
ドメイン層は、ドメイン モデルを実装し、ドメイン モデルの中核となるビジネス ロジックを実装します。アトミック モデルに属します。ドメイン モデルとビジネス ロジックの安定性を維持し、安定したきめ細かいドメイン サービスを外部に提供する必要があります。したがって、それはアーキテクチャの中核です。
アプリケーション層はユーザー操作に関わるユースケースやプロセスを実装し、粒度の粗いAPIサービスを外部に提供します。これは、フォアグラウンド アプリケーションとドメイン層を適応させ、フォアグラウンド要件を受け取り、いつでも応答して調整し、フォアグラウンド要件がドメイン層に送信されるのを回避しようとする歯車のようなものです。アプリケーション層は歯車として、フォアグラウンド アプリケーションとドメイン層の間に位置します。
これら 3 つのアーキテクチャは、フロントエンド要件の変化とドメイン モデルの不変性を考慮していると言えます。需要は常に変化しますが、従うべきルールは常に存在します。ユーザー エクスペリエンス、操作習慣、市場環境、管理プロセスの変化により、インターフェイスのロジックやプロセスも変更されることがよくあります。しかし、一般に、フロントエンドがどのように変化しても、企業内に大きな変化がない限り、コアドメインのロジックは基本的に大きく変わらないため、ドメインモデルは比較的安定しており、ユースケースやプロセスは随時調整されます。外部アプリケーションの要件に応じていつでも。この法則をよく理解すると、アプリケーション層とドメイン層の設計方法がわかります。
アーキテクチャモデルは、システムの外部から内部への需要変化の影響を階層的に制御し、外部から内部への需要の影響を段階的に軽減します。ユーザー指向のフロントエンドは外部の調整やリリースのニーズに迅速に対応し、柔軟かつ変更可能、アプリケーション層はサービスの構成とオーケストレーションによりビジネスプロセスの迅速な適応と起動を実現し、ドメインへの送信の必要性を削減します層を形成し、ドメイン層の長期安定性を維持します。
この設計の利点は明らかです。つまり、ドメイン層のコア ビジネス ロジックが外部の要件やプロセスの変更によって調整されないようにすることができ、柔軟なフロントエンドと安定したシステムを確立するのに非常に役立ちます。ミドルエンドのアーキテクチャ。
これを見て、ミドルプラットフォームとマイクロサービスの設計の鍵はもうわかりましたか? 私の答えは、「ドメイン モデルとマイクロサービスの合理的な階層設計」です。それで、あなたの答えは何ですか？
3 つのアーキテクチャ モデルからミドル プラットフォームとマイクロサービスの設計を見る
これら 3 つのマイクロサービス アーキテクチャ モデルの共通点を組み合わせて、ミドル プラットフォームとマイクロサービスの設計に関する経験についてお話します。
中間プラットフォームは本質的にドメインのサブドメインであり、コア ドメイン、一般ドメイン、サポート ドメインの場合があります。一般に、Ali の中間プラットフォームは DDD の一般的な領域に対応し、一般的な共有サービスを外部に提供するための一般公開機能が中間プラットフォームに組み込まれていると考えられています。
中間ステーションはサブドメインとしてさらにサブサブドメインに分解でき、サブドメインが適切なサイズに分解され、イベント ストームを通じて境界コンテキストが分割された後、マイクロサービスを定義でき、マイクロサービスを使用して機能を実現します。中間駅の。表面上、DDD、ミドル プラットフォーム、マイクロサービスの間には何のつながりもないように見えますが、実際にはそれらの関係は非常に密接であり、これらを組み合わせて、ミドル プラットフォームとマイクロサービスの設計のための理論システムとして使用できます。
1. 中国と台湾の建設はドメインモデルに焦点を当てる必要がある
ミドルオフィスは、企業全体の観点から機能の共有と再利用を考慮する必要があります。
ミドルプラットフォームを設計する際には、ミドルプラットフォーム内のすべての境界付きコンテキストのドメインモデルを確立する必要があり、アーキテクチャの進化と機能の再結合は、DDD モデリングプロセス中に考慮されます。ドメイン モデルを確立するプロセスでは、ビジネスとアプリケーションの論理的および物理的境界 (マイクロサービス) が明確に分割されます。ドメイン モデルの結果は、その後のシステム モデル、アーキテクチャ モデル、コード モデルに影響を与え、最終的にはマイクロサービスの分割とプロジェクトの実装に影響を与えます。
したがって、中期設計では、まずドメイン モデルに焦点を当て、それを中心に置く必要があります。
2. マイクロサービスには合理的なアーキテクチャの階層化が必要です
マイクロサービスの設計には階層化された設計アイデアが必要で、各層がその役割を実行し、層間に疎結合の関係を確立する必要があります。
ドメイン層の純度とドメイン ロジックの安定性を確保し、ドメイン モデルの汚染を避けるために、ドメインに依存しないロジックをドメイン層に配置しないでください。ドメイン モデルのビジネス ロジックをアプリケーション層に配置しないでください。アプリケーション層が大きくなりすぎて、最終的にドメイン モデルが焦点を失うことになります。どうしても避けられない場合は、防食層を導入して新旧システムを適応・変換し、移行期間終了後は直接防食層コードを廃棄することも可能です。
マイクロサービス内の階層化方法についてはすでに理解しましたが、マイクロサービス間に階層的な依存関係はあるのでしょうか? マイクロサービス間のサービス統合を実現するにはどうすればよいでしょうか?
一部のマイクロサービスは、フロントエンド アプリケーションと統合して、特定のビジネスを一緒に完了できます。これらはプロジェクト レベルのマイクロサービスです。エンタープライズ レベルのビジネス プロセスを完了するには、そのような複数のマイクロサービスを組み合わせる必要があります。これは、エンタープライズ レベルのミッドステージ マイクロサービスです。2 種類のマイクロサービスは複雑さが異なるため、統合方法も異なります。
プロジェクトレベルのマイクロサービス
プロジェクト レベルのマイクロサービスの内部は、階層化アーキテクチャ モデルに従います。ドメイン モデルのコア ロジックはドメイン層で実装され、サービスの組み合わせとオーケストレーションはアプリケーション層で実装され、フロントエンドとバックエンドの分離を実現するために、API ゲートウェイを通じてフロントエンド アプリケーションにサービスが提供されます。 。ただし、プロジェクト レベルのマイクロサービスは他のマイクロサービスを呼び出す場合があります。下の図では、たとえば、プロジェクト レベルのマイクロサービス B が認証マイクロサービス A を呼び出して、ログインと認可の認証を完了していることがわかります。
通常、プロジェクト レベルのマイクロサービス間の統合はマイクロサービスのアプリケーション層で行われ、アプリケーション サービスは API ゲートウェイ上の他のマイクロサービスによって公開されたアプリケーション サービスを呼び出します。以下の図のマイクロサービス B の赤枠内のアプリケーション サービス B に注目すると、独自のドメイン サービスを組み合わせてオーケストレーションするだけでなく、外部マイクロサービスのアプリケーション サービスを組み合わせてオーケストレーションすることもできます。フロントエンドが呼び出す API ゲートウェイにオーケストレーションされたサービスを公開するだけで、フロントエンドは独自のマイクロサービスに直接アクセスできるようになります。
エンタープライズレベルの中段階のマイクロサービス
エンタープライズ レベルのビジネス プロセスは、多くの場合、複数の中間段階のマイクロサービスの連携を通じて完了します。
エンタープライズ レベルの中間段階のマイクロサービスを統合しても、プロジェクト レベルのマイクロサービスのような、特定のマイクロサービス内でクロス マイクロサービス サービスの構成やオーケストレーションを完了することはできません。
ミドルエンド マイクロサービスの上にレイヤーを追加できます。下の図を見てください。追加されたレイヤーは赤いボックス内にあります。その主な機能は、ミドルエンド マイクロサービス全体にわたるサービスの構成とオーケストレーション、および調整を処理することです。サービス間で、異なるチャネルのフロントエンド アプリケーションの適応を完了することもできます。事業範囲を拡大すれば、さまざまな業界やチャネル向けのサービスプラットフォームにすることができます。
BFF (Backend for Frontends) という用語を借りて、当面は BFF マイクロサービスと呼ぶこともできます。BFF マイクロサービスと他のマイクロサービスの間には大きな違いがあります。つまり、BFF マイクロサービスにはドメイン モデルがないため、このマイクロサービスにはドメイン層はありません。BFF マイクロサービスは、アプリケーション層とユーザー インターフェイス層の主要な機能を引き受け、さまざまなミドルエンド マイクロサービスのサービスの組み合わせとオーケストレーションを完了し、さまざまなフロントエンドとチャネルの要件に適応できます。
3. アプリケーションとリソースの分離と適応
従来のデータ中心の設計パターンでは、アプリケーションはデータベース、キャッシュ、ファイル システムなどの基本リソースに大きく依存します。
依存関係が強いからこそ、基本的なリソースを置き換えるとアプリケーションに大きな影響を与えるため、アプリケーションとリソースを切り離す必要があります。
マイクロサービス アーキテクチャでは、アプリケーション層、ドメイン層、ベース層の分離は、ウェアハウス モデルと依存関係逆転の設計手法によって実現されます。アプリケーション設計では、基本リソースのコード適応も同時に検討し、データベースの変更などインフラリソースの変更があった場合でも、リソース変更によるビジネスコードへの影響を遮断し、ビジネスの依存関係を断ち切ることができます。基本的なリソースのロジックを強化し、リソース変更によるアプリケーションへの影響を最終的に軽減します。
要約する
今日は、ニート アーキテクチャとヘキサゴナル アーキテクチャについて詳しく説明し、DDD 階層型アーキテクチャを含む 3 つのマイクロサービス アーキテクチャ モデルを比較分析し、それらの共通の特徴を要約し、プラットフォーム モデリングとマイクロサービス アーキテクチャ設計のいくつかの重要なポイントを整理しました。設計の実装については後ほど詳しく説明します。
今日の内容から理解するのは難しくありません。DDDレイヤード アーキテクチャ、ニート アーキテクチャ、およびヘキサゴナル アーキテクチャはすべてドメイン モデルを中心としており、レイヤード アーキテクチャを実装しており、内部のコア ビジネス ロジックは外部のアプリケーションやリソースから分離および切り離されています。このデザインアイデアは将来的に非常に役立ちますので、必ず覚えておいてください。