DDD とマイクロサービスの関係

DDDの台頭

近年の機器や技術の発展に伴い、初期のスタンドアロン (BS/CS) アーキテクチャから、その後の集中型アーキテクチャ、そして今日のマイクロサービス アーキテクチャに至るまで、ソフトウェア アーキテクチャが多くの変化を遂げたことは誰もが知っています。基本的には、マイクロサービス アーキテクチャの普及時代に、DDD は 2004 年には Eric Evans によって提案されましたが、Martin Fowler の「マイクロサービス」が注目を集めるまで、つまり普及後は停滞していました。 (マイクロサービスの最初の提案者は Martin Fowler ではなく Fred George であることに注意してください)、DDD が再び人々の視野に戻ってきました。なぜでしょうか?

まず、3 つの技術アーキテクチャの進化と主な違いを見てみましょう。

最初の段階はスタンドアロン アーキテクチャで、データベースを中心とした開発全体の設計と開発を特徴としています。

第2段階はオブジェクト指向設計手法を採用した3層集中型アーキテクチャで、ビジネスロジックはビジネス層、ロジック層、データアクセス層に分かれており、単層または複数層で肥大化しやすいが、さらに、ムーアの法則は無効であり、単一のマシンのパフォーマンスには限界があります。

第三段階はマイクロサービスアーキテクチャですが、集中型アーキテクチャではシステムの分析、設計、開発が独立して行われることが多く、各段階の担当者が異なる場合があるため、通信情報の損失が問題となります。プロジェクトは分析から始まる 開発プロセスが非常に長く、最終的な開発設計が要件と異なることが起こりやすい マイクロサービスは主に第2段階でこれらのペインポイントを解決し、アプリケーション間のデカップリングを実現し、単一アプリケーションのスケーラビリティの問題。

マイクロサービスの問題

マイクロサービスの参入後、集中型アーキテクチャのモノリシックアプリケーションの多くの問題は解決されましたが、時代の要求に応じて新たな問題も発生しています。マイクロサービスを設計するにはどうすればよいですか? マイクロサービスを分割するにはどうすればよいですか? マイクロサービスの境界はどこにあるのでしょうか?

この問題は長い間解決されておらず、Martin Fowler でさえ、マイクロサービス アーキテクチャを提案したときにマイクロサービスを分割する方法を教えてくれませんでした。

長い間、人々はマイクロサービスの分割についていくつかの誤解を持っていました。「マイクロサービスは非常に単純です。つまり、以前のモノリシック アプリケーションを複数のデプロイメント パッケージに分割するか、元のモノリシック アプリケーション アーキテクチャを分割するだけです。それを置き換えるだけです」と考える人もいます。マイクロサービスをサポートする技術アーキテクチャを備えており、それがマイクロサービスなのです。」 マイクロサービスは可能な限り小さく分割されるべきだと考える人もいます。

上記の状況を考慮すると、多くのプロジェクトは初期段階での過度の分割により複雑になりすぎ、後の段階での運用維持やオンライン化さえ困難になります。

マイクロサービス分割のジレンマの根本原因は、ビジネスまたはマイクロサービスの境界がどこにあるのかわからないことにあると結論付けることができます。つまり、ビジネス境界とアプリケーション境界が決まれば、このジレンマは解決されるのです。

DDD はビジネス境界を決定する問題を解決します。DDD は技術的なアーキテクチャではなく、ビジネス ドメインの範囲を分割するための方法論であることがわかります。DDD の台頭は、ドメイン駆動モデリング (DDD) に精通している多くのエンジニアが、マイクロサービスを設計する際に、ビジネス仕分けに DDD のアイデアを使用すると、サービス境界を適切に計画し、内部および外部の高度なマイクロサービスを実現できることに気づいたという事実によるものです。ローカップリング。そのため、DDD を事業部門の指導的なイデオロギーとみなす人が増えています。

DDD の概要

DDD は、ビジネスを解体し、ビジネスを分割し、ビジネス境界を決定する手法です。これは非常に複雑なドメイン設計のアイデアです。問題をドメインに分割し、技術的な実装の複雑さを分離しようとします。主な解決策は、ソフトウェアが解決する問題です。理解するのが難しく、進化するのが難しいです。DDD はアーキテクチャではなく、アーキテクチャの方法論です。その目的は、複雑な問題領域を単純化し、技術的なアーキテクチャの進化をうまく実現できる明確な領域と境界を設計するのに役立つことです。

1. ドメイン駆動設計は、データ モデリングではなくドメイン モデリングに基づいています。
上記の例では、コード リファクタリングの前、アクティビティ エンティティには基本的な属性と get/set メソッド、つまり「失血モデル」しかありません。アクティビティ ドメイン オブジェクトはデータ オブジェクトに縮退し、orm コンポーネントのクラッドとしてのみ使用され、プロジェクト コードのあらゆる場所で出血モデルが見られます。その理由は、オブジェクト リレーショナル マッピング (休止状態などの ORM) 永続化メカニズムの人気に直接関係しています。ORM を使用して、各クラスをデータ テーブルにマップし、エンティティ オブジェクトを通じて完全なクラッドを作成します。時間の経過とともに、エンティティは orm の用語になります。ドメイン機能を失うフレームワーク。プロジェクトを設計するときは、データベースの観点からではなく、ビジネス ドメインの観点から考える必要があります。これについては、戦略設計セクションで詳しく説明します。

2. 六角形アーキテクチャの設計との出会い
六角形アーキテクチャについては後で詳しく紹介しますが、オニオン アーキテクチャとクリーン アーキテクチャは六角形アーキテクチャに似ています。
上記の 2 つの点が満たされ、DDD のいくつかの概念がマッピングされて実践されている場合、システムはすでに DDD に準拠しています。要約すると、DDD は真新しい特殊なアーキテクチャではなく、高い保守性、高いスケーラビリティ、高いテスト容易性、および明確なコード構造を満たすために、プロジェクト コードがリファクタリング後に到達するエンドポイントです。

DDD は戦略設計パートと戦術設計パートの 2 つのパートで構成されます。

戦略設計は主にビジネスの観点から始まり、ビジネス ドメイン モデルを確立し、ドメイン境界を分割し、共通言語の境界コンテキストを確立します。境界コンテキストは、マイクロサービス設計の参照境界として使用できます。

戦術的設計は技術的な観点から始まり、ドメイン モデルの技術的な実現に焦点を当て、集約ルート、エンティティ、値オブジェクト、ドメイン サービス、アプリケーション サービス、リソースのコード ロジックの設計と実装を含むソフトウェア開発と実装を完了します。図書館。

DDD の戦略設計では、マイクロサービスの設計と分割をガイドするために使用されるドメイン モデルを確立します。DDD の最初のステップは、ビジネスの理解を一緒に議論することとして理解できるブレインストーミングを行うことです。省略、先ほどの桃の木と同じように、まずは各ドメインに着目できるようにできる限り分析することです 実際にはユースケース分析やシナリオ分析がよく使われます そしてユーザージャーニー分析、これは分岐プロセスです。ブレーンストーミング段階では、エンティティ、コマンド、イベントなどの多くのドメイン オブジェクトが生成されます。それらをさまざまな次元からクラスタリングして、集約や境界付きコンテキストなどの境界を形成し、ドメイン モデルを確立します。収束プロセス。

具体的には、ドメイン モデルとマイクロサービスの境界を 3 つのステップで決定できます。

ステップ 1: イベント ストームにおけるユーザー操作、イベント、ビジネス プロセス内の外部依存関係を整理し、これらの要素に基づいてドメイン エンティティなどのドメイン オブジェクトを整理します。

ステップ 2: ドメイン エンティティ間のビジネス相関に従って、ビジネスに密接に関連するエンティティを組み合わせて集計を形成し、集計ルート、値オブジェクト、および集計内のエンティティを決定します。この図では、アグリゲート間の境界は第 1 層の境界であり、これらは同じマイクロサービス インスタンス内で実行され、この境界は論理境界であるため、点線で表されています。

ステップ 3: ビジネス境界やセマンティック境界などの要素に従って、境界付きコンテキストで 1 つ以上の集約を定義して、ドメイン モデルを形成します。この図では、境界付きコンテキスト間の境界は第 2 層の境界であり、将来のマイクロサービスの境界になる可能性があります。異なる境界付きコンテキストのドメイン ロジックは分離され、異なるマイクロサービス インスタンスで実行され、物理的に相互作用します。は物理的な境界であり、境界は実線で表されます。

上記では、フィールド、集計、エンティティのほか、集計ルート、値オブジェクトなどの単語が登場し、さらに統一モデリング言語、サブドメイン、コアドメイン、一般ドメイン、サポートドメインなどがありますが、これらは実際には紙です前述したように、その後、ある分野の議論を容易にするために、いくつかの概念が形成されることがよくあり、それらの概念はいくつかの名詞によって要約されます。これが上記の名詞の由来です。これを統一モデリング言語と呼びます. Hahaha, ok, no nonsense, I これらの言葉の意味については次の記事で説明しますが、ここでは主に DDD が解決する問題について説明します。

DDD とマイクロサービスの関係を整理すると、 DDD はアーキテクチャ設計手法であり、マイクロサービスはアーキテクチャスタイルであり、どちらも本質的には高い応答性を追求するためのものであり、アプリケーションシステム構築の複雑さをビジネスの観点から分離することを意味します。どちらもビジネスから始めることを重視しており、その核心は、ビジネスの発展に応じてドメイン境界を合理的に分割することを重視し、既存のアーキテクチャを継続的に調整し、既存のコードを最適化してアーキテクチャとコードの活力を維持することです。進化的アーキテクチャと呼ばれることがよくあります。DDD は主に、ビジネス ドメインの観点からドメイン境界を分割し、効率的なコミュニケーションのための共通言語を構築し、ビジネス抽象化によるドメイン モデルを確立し、ビジネスとコード間の論理的一貫性を維持することに重点を置いています。マイクロサービスは主に、プロセス間通信、フォールト トレランス、実行時の障害分離、分散データ管理と分散サービス ガバナンスの実現、マイクロサービスの独立した開発、テスト、構築、展開に重点を置いています。

DDD戦略設計

戦略的設計は主にビジネスの観点から始まり、ビジネス ドメイン モデルを確立し、ドメイン境界を分割し、共通言語の境界コンテキストを確立します。境界コンテキストは、マイクロサービス設計の参照境界として使用できます。
ドメイン: 大まかに言えば、ドメインとは、組織が行うこととその組織内のすべてのことです。企業や組織にはそれぞれ独自の事業範囲ややり方があり、その事業範囲やその中で行われる活動がドメインとなります。会社のためにソフトウェアを開発するときは、その会社のドメインに対して作業することになります。あなたはこの分野で働いているので、この分野については明確に理解しているはずです。
投げ銭のビジネスにとって、投げ銭自体がフィールド、つまり投げ銭の分野です。投げ銭の対象がホスト、映画、ブログ投稿であっても、投げ銭の対象が人民元、仮想通貨、ロケットなどであっても、投げ銭はこの分野の中核です。
サブドメイン: 「ドメイン」という単語を含むドメイン モデルの場合、ビジネス システム全体が、単一の結合した完全に機能するモデルを作成していると考えることができます。それでは、これは DDD の目標ではありません。これに対して、DDD では、ドメインがいくつかの小さなドメインに分割され、これらの小さなドメインがサブドメインになります。実際、ドメイン モデルを開発するときは、通常、ビジネス システムの特定の側面にのみ焦点を当てており、ドメインを分割することが成功に役立ちます。
境界付きコンテキスト: 表示境界によって境界付けられる特別な責任。ドメイン モデルは境界内に存在し、境界内では、属性や操作を含むすべてのモデルの概念が特別な意味を持ちます。

アーキテクチャの階層化:階層化アーキテクチャの重要な原則は、各レイヤーはその下のレイヤーとのみ集約できるということです。

インターフェイス定義と実装の分離を実現するために、インターフェイス定義はドメイン層にあり、実装定義はインフラストラクチャ層にあります。しかし、これは上から下への単一依存の原則に違反します。この問題を解決するために、ここでは依存関係逆転の原則を採用します。依存関係逆転の原則の内容は、高レベルのモジュールが低レベルのモジュールに依存すべきではなく、両方とも抽象化に依存する必要があります。抽象化は詳細に依存すべきではなく、詳細は抽象化に依存する必要があります。この原則によれば、構造調整は次のようになります。

インフラストラクチャ層をすべての層の最上位に置き、他のすべての層で定義されたインターフェイスを実装します。

階層化されたアーキテクチャで依存関係逆転の原則を採用すると、実際には階層化の概念がもはや存在しないことに気づくかもしれません。高レベルであっても低レベルであっても、レイヤー全体をフラットに押し上げるかのように、抽象化のみに依存します。フラット化後、クライアントは「同等の」方法でシステムと対話します。新しい顧客の追加は、入力、出力、およびプレゼンテーション形式が異なるだけであり、これは私たちが理解しようとしているもう 1 つのアーキテクチャ、つまりヘキサゴナル アーキテクチャです。

六角形の建築

私たちのコードには、直接の外部依存関係と実装の詳細が多数あります。mybatisのマッパークラス、httpclientインジェクション、rocketmqモニタリング、キャッシュの直接操作など。この種の実装には 2 つの明らかな問題があります。1 つは、基礎となるコンポーネントが置き換えられると、ビジネス ロジックに直接影響を及ぼし、コード変更の量とテスト範囲が大幅に増加することです。2つ目は、機能の再利用が難しく、他の企業が同様のロジックを持っている場合、そのまま移植して再利用することができません。
2005 年に、Alistair Cockburn は、ポートおよびアダプター アーキテクチャとも呼ばれるヘキサゴナル アーキテクチャを提案しました。上の図を観察すると、コア アプリケーションとドメイン モデルでは、他の基礎となる依存関係または実装が入力と出力の 2 つのタイプに抽象化できることがわかりました。組織関係はトップダウン構造ではなく、社内と社外の二次元的な関係になっています。各 IO とアプリケーションの前に、分離作業を完了するためのアダプターがあり、各最外側のエッジがポートです。ヘキサゴナルアーキテクチャに基づいて設計されたシステムは、DDDが追求した最終形態です。ヘキサゴナル アーキテクチャの実践については、「DDD の利点」セクションで説明されています。
最初に六角形のアーキテクチャに基づいて演習を行った後、プロジェクトのモジュール構造は次のようになります。

DDD戦術デザイン

戦術的設計は技術的な観点から始まり、ドメイン モデルの技術的な実現に焦点を当て、集約ルート、エンティティ、値オブジェクト、ドメイン サービス、アプリケーション サービス、リソースのコード ロジックの設計と実装を含むソフトウェア開発と実装を完了します。ライブラリ。

エンティティ: 属性と動作で構成され、一意の識別子を持ちます。
システムを設計するとき、私たちはドメインではなくデータに焦点を当てる傾向があります。同じことが DDD 開発者にも当てはまります。ソフトウェア開発においては、データベースが依然として主要な位置を占めているからです。最初に考慮すべきことは、動作が豊富なドメインの概念ではなく、データの属性と関連性です。この結果、データ モデルがオブジェクト モデルに直接反映され、get/set メソッドのみを含むエンティティが生成されますが、これは DDD アプローチではありません。
サービスと組み合わせて使用​​する必要があるのは get/set エンティティのみであり、凝集性、保守性、および再利用の移行コストは DDD アプローチよりも大幅に高くなります。

値オブジェクト: 一意のアイデンティティを持たず、測定可能または記述的で、不変性を満たすオブジェクト。
エンティティと比較して、値オブジェクトは非常に簡単に作成、テスト、使用、最適化、維持できるため、エンティティ オブジェクトの代わりに値オブジェクトを使用してモデル化するようにしてください。

ドメイン サービス: ドメイン サービスは、ドメイン固有のタスクを実装するために使用されるステートレスな操作を表します。
操作が集計オブジェクトや値オブジェクトに適していない場合、最善の方法はドメイン サービスを使用することです。
たとえば、「ユーザー認証」の 1 つの方法は、エンティティに認証操作を単純に適用できることです。この設計には 2 つの問題があります。第一に、ユーザー クラスは特定の認証の詳細を知る必要があります。第二に、このアプローチでは共通言語を明示的に表現できません。ここでは、「認証」のプロセスを表現せずに、ユーザーが「認証」されたかどうかを尋ねています。可能であれば、コミュニケーション言語をモデリング用語で直接表現するように努めるべきです。

ドメイン イベント: ドメイン専門家が関心を持つドメイン内で発生するいくつかのイベント。通常、イベントの一貫性を維持するためにドメイン イベントを使用します。これにより、2 フェーズ コミット (グローバル トランザクション) を排除できます。

集約: 集約は、外部の世界から全体としてアクセスされる関連オブジェクトのグループの組み合わせであり、集約ルートはこの集約のルート ノードです。
集約は非常に重要な概念であり、コア領域は集約という観点から表現されることがよくあります。次に、集約には技術的にも非常に高い価値があり、詳細な設計を導くことができます。集計はルートエンティティ、エンティティ、値オブジェクトで構成されます。

ファクトリ: ファクトリは、オブジェクト作成の複雑な操作プロセスをすべてカプセル化したオブジェクト作成用のインターフェイスを提供します。同時に、顧客は実際に作成されたオブジェクトを参照する必要がありません。

DDDの利点

DDD を適用したシステムはヘキサゴナル アーキテクチャに準拠しており、次の目標を達成します。

フレームワークからの独立性: アーキテクチャは外部のライブラリやフレームワークに依存すべきではなく、フレームワークの構造に束縛されるべきではありません。

UI から独立: 前景に表示されるスタイルはいつでも変更される可能性がありますが、基礎となるアーキテクチャはそれに応じて変更されるべきではありません。

基礎となるデータ ソースからの独立性: ソフトウェア アーキテクチャは、基礎となるデータ ストアの違いによって大幅に変更されるべきではありません。

外部依存関係からの独立性: 外部依存関係がどのように変更またはアップグレードされても、それに応じてビジネスのコア ロジックが大幅に変更されるべきではありません。

参考文献 https://mp.weixin.qq.com/s/g_kvMHAkqiHyv1O5ZHADKQ
https://juejin.cn/post/7050738599649607694