マイクロサービスとDDDドメイン駆動型設計モデル
DDDドメイン駆動型設計とは
ドメイン駆動型設計を最初に紹介したのは、2004年にプログラマーEric Evansによって発行された本「ドメイン駆動型設計：複雑なソフトウェアコアの複雑なソリューション」です。ドメイン駆動型設計は、ドメイン概念の拡張と適用です。そしてそれをソフトウェア開発に適用します。その目標は、ソフトウェアの関連部分を進化するモデルに接続し、複雑なアプリケーションの作成を容易にすることです。
DDDの実装事例については、次の記事を参照してください。
「「[インターネットビジネス開発におけるドメインドリブンデザインの実践]
https://tech.meituan.com/2017/12/22/ddd-in-practice.html
」
DDDについて知っておくべきこと
貧血モデル
「「貧血の標的
Anemic Domain Object（Anemic Domain Object）は、動作やアクションなしでデータキャリアとしてのみ使用されるドメインオブジェクトを指します。
」
簡単に言えば、それはゲッター/セッターメソッドのみを持つエンティティです。貧血領域にオブジェクトがあるので、混雑領域にもオブジェクトがあります。
「「輻輳ドメインオブジェクト
Getter / Setterメソッドに加えて、エンティティにはエンティティの動作とアクションを記述するためのメソッドもあります
」
例を見てみましょうOrder。これが注文エンティティです。
上記のエンティティにはエンティティの動作を説明する方法がないため、エンティティは貧血モデルです。
配達の注文を変更するための特別な方法が必要な場合は、次のように書くことができます
高血症モデルで書くとどうなりますか？
注文ステータスの動作を説明するメソッドを追加しましたbuildDeliveryStatus()。
注文の配送方法が次のように変更されます
ここではorder.buildDeliveryStatus()、出荷ステータスの動作を取得するために直接呼び出し、特定の動作がどのように生成されるかを非表示にします。
実際、通常の考え方では貧血モデルは問題ありませんが、ビジネスロジックが複雑になると、ビジネスロジックと状態がさまざまな方法で分散し、元のコードの意図が徐々に不明確になります。
「「輻輳モデルを使用する開発者は、動作の特定の詳細を気にする必要はなく、オブジェクト指向のパッケージングの設計原則に準拠するこの動作を使用するだけでよいと思います。
」
集約ルート
Aggregateは、外部から全体としてアクセスされる関連オブジェクトのコレクションです。AggregateRootは、この集約のルートノードです。
エンティティ
オブジェクトが（属性ではなく）そのIDによって区別される場合、そのようなオブジェクトはエンティティと呼ばれます。
バリューオブジェクト
オブジェクトが一意の識別子なしでトランザクションを記述するために使用される場合、それは値オブジェクトと呼ばれます。
集約ルート
マイクロサービスにDDDドメイン駆動型設計が必要な理由
「マイクロサービスのアーキテクチャと設計パターン」は、サービス分割戦略の第2章で、単一のサービスをマイクロサービスに分割する場合、次の分割方法に従うことができると書いています。
「「」
ビジネス能力による分割
サブドメインモードで分割
この記事では、マイクロサービスとは何かについては説明しません。マイクロサービスの子供用シューズがわからない場合は、この本を読むことができます。
大規模なソフトウェア開発では、組織内のすべてのチームが単一のグローバルモデルと用語について合意することは非常に困難です。組織内の一部のチームは、異なる概念に同じ用語を使用する場合があり、一部のチームは同じ概念を対象とする場合があります。 DDDは、さまざまな用語を使用して、それぞれが独自の明確なスコープを持つ複数のドメインモデルを定義することにより、これらの問題を回避できます。
サービスを分割する前に、まず抽象ドメインモデルを作成する必要があります。各サービスには独自のドメインモデルがあります。抽象ドメインモデルは、サービス分割フェーズで役立ちます。オペレーティングシステムの動作を説明するいくつかの単語を定義します。 。
ドメインモデル
上の図は、システム開発の初期段階におけるドメインモデルの概略図です。
サブドメインモードによる分割は、DDDドメイン駆動型設計のアイデアを採用しています。ドメイン駆動型設計は、複雑なソフトウェアを構築するための非常に効果的な方法です。ドメイン駆動型設計では、ドメインモデルがコアであり、ドメイン駆動型設計には、サブドメインと制限付きコンテキストという2つの重要な概念があります。
ドメインの一部はサブドメインであり、ドメインの境界は制限されたコンテキストです。
境界のあるコンテキスト
上の図に示すように、楕円形の破線は境界のあるコンテキストを示し、破線はサブドメインを囲みます。各サブドメインはドメインモデルをマップします。
「「DDDのサブドメインと制限付きコンテキストの概念は、マイクロサービスアーキテクチャのサービスとよく一致します。マイクロサービスアーキテクチャの自律チームが概念の開発を担当し、DDDの各ドメインモデルは独立したチームによって開発されます。コンセプトは一貫しています。
」
ドメイン駆動型設計の階層化アーキテクチャ
従来のアーキテクチャは3層アーキテクチャです。
「「」
プレゼンテーションレイヤー（コントローラーレイヤー）：ユーザーインターフェイスまたは外部APIを実装するコードが含まれています
ビジネスロジックレイヤー（サービスレイヤー）：ビジネスロジックが含まれています
データ永続層（Dao層）：データベースとの相互作用のロジックを実現します
この階層化されたアーキテクチャは、適切に設計されたアプリケーションの依存関係を誤って表しています。ビジネスロジックは通常、データアクセスメソッドのインターフェイス（追加、削除、変更、およびクエリロジック）を定義します。データ永続性レイヤーは、データベースインターフェイスを実装するDaoクラスを定義します。この依存関係は、階層化アーキテクチャが説明するものとは逆です。
ドメイン駆動型モデルの階層化アーキテクチャ
ドメインの階層化
-
ユーザーインターフェイス-ユーザーインターフェイスレイヤー：コントローラー、安らかなインターフェイス呼び出し、またはWeb UIインターフェイス、モバイルUIインターフェイス、サードパーティサービスなど。
-
アプリケーション-アプリケーション層：外部でプレゼンテーション層にさまざまなアプリケーション機能を提供し、内部でドメイン層（ドメインサービス）を呼び出します。アプリケーション層は、特定のシナリオまたはプロセスオーケストレーションを実装するための戦略に似ています。複数の分野のサービスと連携して、シナリオとビジネスの分離を実現します。
-
ドメイン-ドメインレイヤー：ビジネスコンセプト、ビジネス行動、ビジネス状態、ビジネスルールを表現する責任があります。ドメインモデルはこのレイヤーにあり、ビジネスソフトウェアのコアです。それが提供するのは一連のアトミックサービスです。このレイヤーで豊富なOPENAPIを提供することは、コンポーネント化を実現するための重要なステップです。
-
インフラストラクチャ-基本層：ビジネスとテクノロジーの分離層を実現します。一般的には、ネットワーク通信、データベースの永続性、非同期メッセージサービス、サウスバウンドゲートウェイサービスなどが含まれます。このレイヤーが起動されると、複数のアダプターを実装して、内部、外部、およびマルチクラウドの異種ミドルウェア環境と互換性を持たせることができます。
この階層化について考える
オブジェクト指向のプログラムでは、ユーザーインターフェイス、データベース、およびその他のサポートコードが、ビジネスオブジェクトに直接書き込まれることがよくあります。追加のビジネスロジックは、UIコンポーネントとデータベーススクリプトの動作に組み込まれています。この理由のいくつかは、物事をすばやく簡単に機能させることができるためです。
ただし、ドメイン関連のコードが他のレイヤーに混在していると、それを読んで考えることが非常に困難になります。一見、UIの変更のように見えますが、ビジネスロジックの変更になっています。ビジネスルールを変更するには、ユーザーインターフェイスレイヤーコード、データベースコード、およびその他のプログラム要素を注意深く追跡する必要がある場合があります。実装は互いに接着され、モデル駆動型オブジェクトは実行不可能になります。自動テストを使用することも困難です。各活動に関係する技術と論理については、プログラムを単純に保つ必要があります。そうしないと、理解が難しくなります。
したがって、複雑なアプリケーションをレイヤーに正しく分割し、各レイヤーでまとまりのあるデザインを開発し、ドメインモデルに関連するコードを独自のレイヤーに集中させ、ユーザーインターフェイス、アプリケーション、インフラストラクチャコードから分離する必要があります。分離します。
コードが特定のレイヤーに明確に分離されていない場合、アプリケーションレイヤーのシーケンスコード全体が乱雑に見え、管理が困難になります。ある場所でコードを変更するだけで、他の場所のコードに未知の隠れた危険が生じます。ドメイン層は、ドメイン層の問題を考慮する必要があり、他の層のアクティビティを含むべきではありません。
特定のドメインモデルの階層化されたコードの実際の戦闘
プロジェクト内のパッケージ名は、上の図を参照できます。
私のプロジェクトがDDDドメイン駆動型設計モデルをどのように参照しているかを見てみましょう。
まず、いくつかのパッケージを作成しましたapplication、controller、domain、infrastructure。ここでのcontrollerパッケージは、実際にはユーザーインターフェイスレイヤーです。
応用
applicationそれは主にいくつかのビジネス面を書きますservice。
ドメイン
domainこれは主に、データベースを処理するいくつかのメソッド（基本的な追加、削除、変更、およびチェック）を作成することに関するものです。
インフラ
infrastructure主に、構成クラスconfigure、定数クラスconstant、列挙enum、ユーティリティクラスなどのいくつかのパブリッククラスを記述しますutils。他のレイヤーを使用する場合。
最後に、DDDに興味のある子供用の靴には2冊の本が推奨されます
「ドメイン駆動型設計：ソフトウェアのコアの複雑さに対処する方法」
「ドメインドリブンデザインの実現」
過去に推奨
QRコードをスキャンして、よりエキサイティングになります。または、WeChatでLvshen_9を検索すると、返信してバックグラウンドで情報を取得できます
1.回复"java" 获取java电子书；
2.回复"python"获取python电子书；
3.回复"算法"获取算法电子书；
4.回复"大数据"获取大数据电子书；
5.回复"spring"获取SpringBoot的学习视频。
6.回复"面试"获取一线大厂面试资料
7.回复"进阶之路"获取Java进阶之路的思维导图
8.回复"手册"获取阿里巴巴Java开发手册(嵩山终极版)
9.回复"总结"获取Java后端面试经验总结PDF版
10.回复"Redis"获取Redis命令手册，和Redis专项面试习题（PDF）
11.回复"并发导图"获取Java并发编程思维导图（xmind终极版）もう1つ：[マイベネフィット]をクリックして、さらに驚きを持ってください。