13 | コード モデル (パート 1): DDD を使用してマイクロサービス コード モデルを設計する方法は?

目次

DDD 階層化アーキテクチャとマイクロサービス コード モデル

マイクロサービスコードモデル

マイクロサービスの第 1 レベルのディレクトリ構造

ディレクトリ構造の層

1. ユーザーインターフェイス層

2. アプリケーション層

3. ドメイン層

4.ベースレイヤー

コードモデルの一般的なディレクトリ構造

要約する


前回の記事でドメインモデルの設計が完了したので、マイクロサービスの設計と実装を開始します。マイクロサービスを実装するときに最初に決定するのは、マイクロサービスのコード構造です。これが、今日説明するマイクロサービス コード モデルです。

標準のマイクロサービス コード モデルとコード仕様が確立された後でのみ、ドメイン オブジェクトに対応するコード オブジェクトを適切なソフトウェア パッケージのディレクトリ構造に配置できます。標準コード モデルを使用すると、プロジェクト チームのメンバーがコードをより深く理解し、コード仕様に従ってチームのコラボレーションを実現できます。また、マイクロサービスの各層のロジックが相互に干渉せず、分業して協力することもできます。必要なコードの難読化。さらに、標準コード モデルを使用すると、マイクロサービス アーキテクチャが進化したときにコードのリファクタリングを簡単に完了することもできます。

では、DDD では、マイクロサービスのコード構造はどのようなものになるのでしょうか? マイクロサービス コード モデルは何に基づいて構築するのでしょうか? 今日はこの 2 つの問題に焦点を当てます。

DDD 階層化アーキテクチャとマイクロサービス コード モデル

マイクロサービス コード モデルを設計するために、DDD 階層化アーキテクチャ モデルを参照します。それは正しい!マイクロサービス コード モデルは、DDD 階層化アーキテクチャ モデルに基づいて設計されています。では、なぜ DDD 階層型アーキテクチャ モデルなのでしょうか?

以前に紹介した DDD 階層化アーキテクチャ モデルに関する記事を簡単に振り返ってみましょうこれには、ユーザー インターフェイス層、アプリケーション層、ドメイン層、ベース層が含まれており、階層化アーキテクチャの各層の責任の境界は非常に明確であり、秩序だった方法で連携できます。

  • ユーザー インターフェイス層: フロント エンドにサービス アダプテーションを提供し、リソース層にリソース アダプテーションを提供します。この層は、インターフェイス適応に関連する機能を集めます。
  • アプリケーション層の責任: サービスの構成とオーケストレーションを実現し、急速に変化するビジネス プロセスのニーズに適応します。この層は、アプリケーション サービスとイベント関連の機能を集約します。
  • ドメイン層: ドメインの中核となるビジネス ロジックを実装します。この層は、ドメイン モデルの集約、集約ルート、エンティティ、値オブジェクト、ドメイン サービス、イベントなどのドメイン オブジェクトと、それらの組み合わせによって形成されるビジネス機能を収集します。
  • 基本レイヤー: すべてのレイヤーを実行し、各レイヤーに基本的なリソース サービスを提供します。この層は、基盤となるさまざまなリソースに関連するサービスと機能を収集します。

ビジネスロジックはドメイン層、アプリケーション層、ユーザーインターフェース層に至るまで各層ごとにカプセル化され連携し、柔軟なサービスを外部に提供することで、各層の分業だけでなく各層の連携も実現します。したがって、DDD 階層化アーキテクチャ モデルがマイクロサービス コード モデルを設計するための最良の基礎であることは疑いの余地がありません。

マイクロサービスコードモデル

ここで、DDD 階層化アーキテクチャ モデルに従って設計されたマイクロサービス コード モデルがどのようなものかを見てみましょう。

実際、DDD には標準のコード モデルが用意されておらず、人によって理解が異なる場合があります。以下で説明するマイクロサービス コード モデルは、主にマイクロサービスの境界、レイヤー、アーキテクチャの進化を考慮した私の思考と実践の後に確立されました。

マイクロサービスの第 1 レベルのディレクトリ構造

マイクロサービスの第 1 レベルのディレクトリは、DDD 階層化アーキテクチャの階層的責任に従って定義されます。下の図から、コード モデルでは、インターフェイス、アプリケーション、ドメイン、インフラストラクチャの 4 つの第 1 レベルのコード ディレクトリが、ユーザー インターフェイス層、アプリケーション層、ドメイン層、およびベース層に対して確立されていることがわかります。 

各ディレクトリの機能とコード形式は以下のとおりです。

  • インターフェイス (ユーザー インターフェイス層):主に、ユーザー インターフェイス層とフロントエンドおよび表示データの間の対話に関連するコードが格納されます。フロントエンドアプリケーションは、この層のインターフェースを介してアプリケーションサービスから表示に必要なデータを取得します。この層は主に、ユーザーが送信した Restful リクエストを処理し、ユーザーが入力した構成ファイルを解析し、データをアプリケーション層に渡すために使用されます。データアセンブリ、データ送信フォーマット、Facadeインターフェースなどのコードはこのディレクトリに配置されます。
  • アプリケーション (アプリケーション層):主にアプリケーション層のサービス構成とオーケストレーションに関連するコードが格納されます。アプリケーションサービスは、マイクロサービス内のドメインサービスや外部マイクロサービスのアプリケーションサービスを基に下位にサービスを整理・結合し、上流のユーザーインターフェース層に対して各種アプリケーションデータ表示支援サービスを提供します。アプリケーション サービスやイベントなどのコードは、このディレクトリに配置されます。
  • ドメイン (ドメイン層):主にドメイン層のコアビジネスロジックに関連するコードが格納されます。ドメイン層には、ドメイン モデルのコア ビジネス ロジックを一緒に実装する複数の集約されたコード パッケージを含めることができます。集約やエンティティ、メソッド、ドメイン サービス、集約内のイベントなどのコードは、このレベルのディレクトリに配置されます。
  • インフラストラクチャ (基本層):主に基本的なリソース サービスに関連するコードが格納されます。一般的な技術機能、サードパーティ ソフトウェア パッケージ、データベース サービス、構成、および他の層に提供される基本的なリソース サービスのコードは、この層ディレクトリに配置されます。

ディレクトリ構造の層

1. ユーザーインターフェイス層

インターフェイスのコード ディレクトリ構造には、アセンブラー、DTO、ファサードの 3 つのカテゴリがあります。

  • アセンブラ: DTO とドメイン オブジェクト間の相互変換とデータ交換を実現します。一般に、アセンブラーと DTO は常に一緒に表示されます。
  • Dto:データ伝送のキャリアです。内部にはビジネス ロジックはありません。DTO を通じて内部ドメイン オブジェクトを外部の世界から隔離できます。
  • ファサード:より粗い呼び出しインターフェイスを提供し、ユーザー要求を 1 つ以上のアプリケーション サービスに委任して処理します。

2. アプリケーション層

アプリケーションのコード ディレクトリ構造は、イベントとサービスです。 

イベント (event):このディレクトリには主にイベント関連のコードが格納されます。これには、publish と subscribe という 2 つのサブディレクトリが含まれています。前者には主にイベント発行に関連するコードが格納され、後者には主にイベント サブスクリプションに関連するコードが格納されます (イベント処理に関連するコア ビジネス ロジックはドメイン層に実装されます)。

ここで注意してください: アプリケーション層とドメイン層の両方でイベントを発行および処理できますが、イベントの統合管理を実現するには、すべてのイベントの発行およびサブスクリプション処理をアプリケーション層のマイクロサービスに配置することをお勧めします。関連するコア ビジネス ロジックの実装はドメイン層に配置されます。完全なイベント発行およびサブスクリプションのプロセスは、アプリケーション層を介してドメイン層サービスを呼び出すことによって実現されます。

サービス (アプリケーション サービス):この層のサービスはアプリケーション サービスです。アプリケーション サービスは、複数のドメイン サービスまたは外部アプリケーション サービスをカプセル化、調整、結合して、粒度の粗いサービスを外部に提供します。アプリケーション サービスは主にサービスの構成とオーケストレーションを実装し、独立したビジネス ロジックです。すべてのアプリケーション サービスを 1 つのアプリケーション サービス クラスに含めることも、アプリケーション サービス クラスのコード サイズが大きくなりすぎないように、アプリケーション サービスをアプリケーション サービス クラスとして設計することもできます。

3. ドメイン層

ドメインは 1 つ以上の集約パッケージで構成され、これらが共同してドメイン モデルのコア ビジネス ロジックを実現します。集約内のコード モデルは標準的で統一されており、エンティティ、イベント、リポジトリ、サービスの 4 つのサブディレクトリが含まれます。 

ドメイン層集合体内のコードディレクトリ構造はこんな感じです。

集約 (集約):集約パッケージのルート ディレクトリであり、実際のプロジェクトの集約名 (権限集約など) に従って名前を付けることができます。集約ルート、エンティティおよび値オブジェクト、集約内のドメイン サービス間の関係と境界を定義します。凝集性の高いビジネス ロジックがアグリゲーション内に実装されており、そのコードは独立してマイクロサービスに分割できます。

集約されたコードを 1 つのパッケージに入れる主な目的はビジネスの結合であり、より大きな目的は将来のマイクロサービス間の集約の再編成です。集約間の明確なコード境界により、集約に基づいてマイクロサービスを簡単に再構築できます。これは、マイクロサービス アーキテクチャの進化において重要な役割を果たします。

エンティティ:集約ルート、エンティティ、値オブジェクト、およびファクトリ パターン (Factory) 関連のコードが格納されます。エンティティクラスは充血モデルを採用しており、同じエンティティに関連するビジネスロジックはエンティティクラスのコードに実装されています。エンティティ全体のビジネス ロジック コードはドメイン サービスに実装されます。

イベント (event):イベント アクティビティに関連するイベント エンティティとビジネス ロジック コードを格納します。

サービス(ドメインサービス):ドメインサービスコードを格納します。ドメイン サービスは、複数のエンティティで構成されるビジネス ロジックの一部です。集約内のすべてのドメイン サービスをドメイン サービス クラスに入れることも、各ドメイン サービスをクラスとして設計することもできます。ドメイン サービスのビジネス ロジックが比較的複雑な場合は、すべてのドメイン サービス コードがドメイン サービス クラスに配置されるため、コードの肥大化の問題を回避するために、ドメイン サービスをドメイン サービス クラスとして設計することをお勧めします。ドメイン サービスは、複数のエンティティまたはメソッドをカプセル化した後、上位層にアプリケーション サービス呼び出しを提供します。

リポジトリ (ウェアハウス):通常、ウェアハウス インターフェイスとウェアハウス実装メソッドを含む、集約されたクエリまたは永続ドメイン オブジェクトのコードが保存されます。アグリゲーションの分割と結合を容易にするために、1 つのアグリゲーションが 1 つのストレージに対応するという原則を設定しました。

特記事項: DDD 階層化アーキテクチャによれば、ストレージ実装はベース層コードに属する必要がありますが、マイクロサービス アーキテクチャが進化する際のコード分割と再編成の利便性を確保するために、集約ストレージ実装のコードをベース層コードに配置しました。集約パッケージ。これにより、要件や設計が変更され、集合体の分割や再編成が必要になった場合でも、コアとなるビジネスロジックやウェアハウスコードを含む集合体パッケージを丸ごと移行することができ、マイクロサービスアーキテクチャの進化を容易に実現できます。

4.ベースレイヤー

インフラストラクチャのコード ディレクトリ構造には、config と util の 2 つのサブディレクトリがあります。 

  • Config:主に構成関連のコードを保存します。
  • 用途:主に、プラットフォーム、開発フレームワーク、メッセージ、データベース、キャッシュ、ファイル、バス、ゲートウェイ、サードパーティ ライブラリ、一般的なアルゴリズムなどの基本コードを保存します。リソースの種類ごとに異なるサブディレクトリを作成できます。

コードモデルの一般的なディレクトリ構造

第 1 レベルと第 2 レベルのコード モデルの設計が完了すると、次の図に示すように、マイクロサービス コード モデルの一般的なディレクトリ構造が表示されます。 

要約する

現在、私たちは DDD 階層化アーキテクチャ モデルに基づいた標準的なマイクロサービス コード モデルを確立しました。コード モデルでは、各コード オブジェクトが独自の位置を持ち、独自の役割を果たし、それらが連携してマイクロサービスのビジネス ロジックを完成させます。

コード モデルについては、さらに 2 つ強調する必要があります。

最初のポイント:集計間のコード境界は明確でなければなりません。アグリゲート間のサービス呼び出しとデータの関連付けは、可能な限り疎結合かつ低関連である必要があります。アグリゲート間のサービス呼び出しは、上位層のアプリケーション層の組み合わせによって実装される必要があります。原則として、ドメイン サービスを直接呼び出すことはできません。集合体の間。このような疎結合コードの関連付けは、将来のビジネス開発や要件が変化した場合でも、ビジネス機能と集約コードの再編成を容易に実現でき、マイクロサービス アーキテクチャの進化において非常に重要な役割を果たします。

2 番目のポイント:コード階層化の概念が必要です。コードを記述する場合は必ずコードの責任を明確にし、責任に応じたコードディレクトリにコードを配置してください。アプリケーション層のコードは、主にサービスの構成とオーケストレーション、およびアグリゲーション間の連携を完了します。これは非常に薄い層であり、コア ドメイン ロジック コードを含めるべきではありません。ドメイン層はビジネスの中核であり、ドメイン モデルのコア ロジック コードはドメイン層に実装する必要があります。コア ドメイン ロジック コードをアプリケーション層に配置すると、DDD 階層化アーキテクチャ モデルに基づくマイクロサービスは、徐々に従来の 3 層アーキテクチャ モデルに進化します。 

おすすめ

転載: blog.csdn.net/zgz15515397650/article/details/131489200