目次
DDD には、戦略設計と戦術設計の 2 つの部分が含まれます。
3 つのステップを使用して、ドメイン モデルとマイクロサービスの間の境界を明確にすることができます。
マイクロサービスの設計プロセスでは、境界をどのように区切るかという問題に直面することがよくありますが、プロジェクト チームが小さなマイクロサービスをどのように解体すべきかについて議論しているのをよく見かけます。マイクロサービスに対する各自の理解に応じて、さまざまな人々が異なるマイクロサービスを分割するため、誰もが自分の意見を主張し、誰も説得できず、誰もが自分の意見が非常に合理的であると感じています。
実際の導入プロセスでは、このようなマイクロサービス設計の混乱に直面しながら、頭を撫でながら完了するプロジェクトも多く見てきましたが、オンライン化後の運用保守のプレッシャーは想像に難くありません。マイクロサービスの設計をガイドする適切な理論や設計方法はありますか? この講義のタイトルを見たら、もう答えはわかっていると思います。
そうです、DDDです。そこで今回は、「なぜマイクロサービス設計にドメイン駆動設計を選択する必要があるのか？」について詳しく解説していきます。
ソフトウェア アーキテクチャ パターンの進化
長年にわたり、機器や新しいテクノロジーの発展に伴い、ソフトウェアのアーキテクチャ モデルは大きく変化してきました。一般的に、ソフトウェア アーキテクチャ パターンは、スタンドアロン、集中型から分散型マイクロサービス アーキテクチャまで 3 段階の進化を経験しました。分散テクノロジーの急速な台頭により、マイクロサービス アーキテクチャの時代に入りました。
まず、ソフトウェア アーキテクチャ パターンの進化の 3 つの段階を分析してみましょう。
最初の段階はスタンドアロン アーキテクチャです。プロセス指向の設計手法を使用し、システムにはクライアント UI レイヤーとデータベースの 2 つのレイヤーが含まれ、C/S アーキテクチャ モードを使用します。システム全体はデータベース ドライバーを中心に設計および開発され、常に起動します。データベースとフィールドの設計から。
第 2 段階は集中型アーキテクチャです。オブジェクト指向設計手法を採用し、システムには古典的な 3 層アーキテクチャを使用したビジネス アクセス層、ビジネス ロジック層、データベース層が含まれ、一部のアプリケーションは従来の SOA アーキテクチャを採用しています。このアーキテクチャでは、システムが肥大化する傾向があり、スケーラビリティや柔軟な拡張性が低くなります。
第 3 段階は分散マイクロサービス アーキテクチャです。マイクロサービス アーキテクチャの概念の導入により、集中型アーキテクチャは分散型マイクロサービス アーキテクチャに向かって進化しています。マイクロサービス アーキテクチャは、アプリケーション間の分離を適切に実現し、単一アプリケーションの不十分なスケーラビリティと柔軟なスケーラビリティの問題を解決できます。
スタンドアロンで集中型のアーキテクチャの時代では、システムの分析、設計、開発が独立して段階的に実行されることが多いことがわかっています。
例えば、システム構築の過程において、Aが要件提案を担当し、Bが要件分析を担当し、Cがシステム設計を担当し、Dがコード実装を担当する、といった状況をよく見かけます。情報損失の原因となります。結局、要件、設計、コード実装の間に齟齬が生じやすく、ソフトウェアを立ち上げた後に、多くの機能が私たちが望んでいたものではなかったり、自分たちが作った機能が自分たちの要件から大きく逸脱しすぎていたりすることがよくあります。
さらに、スタンドアロン アーキテクチャと集中型アーキテクチャの 2 つのモードでは、ソフトウェアは需要やビジネスの急速な変化に迅速に対応できず、最終的には開発の機会を逃してしまいます。現時点では、分散マイクロサービスの出現はまさに適切な時期に来ています。
マイクロサービスの設計と分離のジレンマ
マイクロサービス アーキテクチャの時代に入った後、マイクロサービスは、スケーラビリティ、弾力的なスケーラビリティ、小規模チームのアジャイル開発など、集中型アーキテクチャによる元の単一アプリケーションの多くの問題を実際に解決しました。
しかし、これらの利点が見られる一方で、マイクロサービスの実践においては多くの議論や疑問もありました。つまり、マイクロサービスの粒度はどのくらいの大きさにすべきでしょうか? マイクロサービスはどのように分割して設計すべきでしょうか? マイクロサービスの境界はどこにあるべきでしょうか?
マイクロサービス アーキテクチャ モデルの提案者である Martin Fowler も含め、マイクロサービスの分割を導く一連の体系的な理論と手法は長い間存在していないと言えます。彼はマイクロサービス アーキテクチャを提案したときに、次のように述べていませんでした。マイクロサービスを分割する方法を教えてください。
したがって、この長い間、多くの人がマイクロサービスについての理解を誤解してきました。「マイクロサービスは非常にシンプルですが、それは元の単一のパッケージを複数のデプロイメント パッケージに分割するか、元の単一のアプリケーション アーキテクチャを、たとえそれがマイクロサービスであっても、マイクロサービス アーキテクチャをサポートする一連の技術フレームワークに置き換えるだけである」と考える人もいます。 「マイクロサービス、つまりマイクロサービス、小規模である必要がある。取り壊しが小さければ小さいほど、効果は大きくなる。」と言う人もいます。
しかし、過去 2 年間に、初期段階でマイクロサービスが過度に分割され、プロジェクトが複雑になりすぎてオンライン化や運用保守ができなくなったために、技術界でいくつかのプロジェクトの話を聞いたことがあると思います。
全体として、マイクロサービスの分割のジレンマの根本原因は、ビジネスとマイクロサービスの境界がどこにあるのかわからないことにあると思います。つまり、ビジネス境界とアプリケーション境界が決まれば、このジレンマは解決されるのです。
では、関連する理論や知識システムのサポートがあるかどうかをどのように判断するのでしょうか? これらの質問に答える前に、ドメイン駆動設計とマイクロサービスの過去と現在を見てみましょう。
2004 年に、Eric Evans (エリック エヴァンス) は「ドメイン駆動設計 - ソフトウェアの中心部の複雑さに取り組む」という本を出版し、そこからドメイン駆動設計 (略して DDD) が生まれました。DDD の中心的な考え方は、ドメイン駆動設計手法を通じてドメイン モデルを定義し、ビジネスとアプリケーションの境界を決定し、ビジネス モデルとコード モデルの間の一貫性を確保することです。
しかし、DDD が提案されて以来、ソフトウェア開発の分野では常に「雷が鳴るが、雨が降る」状態が続いています。DDD が実際に独自の時代を迎えたのは、Martin Fowler がマイクロサービス アーキテクチャを提案したときでした。
DDD 設計手法に精通している一部のソフトウェア エンジニアは、マイクロサービスの設計時に DDD 設計手法を使用してドメイン モデルを確立し、ドメイン境界を分割し、その後、これらのドメイン境界に基づいてビジネスの観点からマイクロサービス境界を分割できることに気づきました。ただし、DDD 手法に従って設計されたマイクロサービスのビジネスとアプリケーションの境界は非常に合理的であり、マイクロサービスの内外で「高い結合性と低い結合性」を十分に実現できます。そのため、マイクロサービス設計の指針となるイデオロギーとして DDD を使用する人がますます増えています。
現在、多くの大手インターネット企業は DDD 設計手法をマイクロサービスの主流の設計手法として採用しています。DDDもこれまでの「大雷小雨」から本格的に暑くなってきました。
DDD がマイクロサービスに適しているのはなぜですか?
「人混みの中で何千回も彼を探しました。ふと振り返ると、その男は薄暗い場所にいました。」 何年もの混乱と論争の後、マイクロサービスはついに恋人を見つけました。
それでは、DDD はどこが神聖で、どのようなアーティファクトがあるのでしょうか?
DDD は、非常に複雑な分野に対処するための設計思想であり、技術実装の複雑さを分離し、ビジネス概念を中心にドメイン モデルを構築してビジネスの複雑さを制御し、ソフトウェアが理解しにくいという問題を解決します。そして進化するのが難しい。DDD はアーキテクチャではなくアーキテクチャ設計方法論であり、境界分割を通じて複雑なビジネス ドメインを簡素化し、明確なドメインとアプリケーションの境界を設計するのに役立ち、アーキテクチャの進化を容易に実現できます。
DDD には、戦略設計と戦術設計の 2 つの部分が含まれます。
戦略設計は主にビジネスの観点から始まり、ビジネス ドメイン モデルを確立し、ドメイン境界を分割し、共通言語の境界コンテキストを確立します。境界コンテキストは、マイクロサービス設計の参照境界として使用できます。
戦術的設計は技術的な観点から始まり、ドメイン モデルの技術的な実現に焦点を当て、集約ルート、エンティティ、値オブジェクト、ドメイン サービス、アプリケーション サービス、リソースのコード ロジックの設計と実装を含むソフトウェア開発と実装を完了します。図書館。
DDD がどのように戦略設計を行うかを見てみましょう。
DDD の戦略的設計では、マイクロサービスの設計と分割のガイドとして使用できるドメイン モデルを確立します。イベント ストームはドメイン モデルを構築する主な方法であり、発散から収束までのプロセスです。通常、ユースケース分析、シナリオ分析、ユーザージャーニー分析を使用して、ビジネスドメインを可能な限り包括的に分解し、ドメインオブジェクト間の関係を整理します。これは多岐にわたるプロセスです。イベント ストーム プロセスでは、エンティティ、コマンド、イベントなどの多くのドメイン オブジェクトが生成されます。これらのドメイン オブジェクトをさまざまな次元からクラスタリングして、集約や限定されたコンテキストなどの境界を形成し、ドメイン モデルを確立します。これは収束プロセスです。
3 つのステップを使用して、ドメイン モデルとマイクロサービスの間の境界を明確にすることができます。
ステップ 1: イベント ストームにおけるユーザー操作、イベント、ビジネス プロセス内の外部依存関係を整理し、これらの要素に基づいてドメイン エンティティなどのドメイン オブジェクトを整理します。
ステップ 2: ドメイン エンティティ間のビジネス相関に従って、ビジネスに密接に関連するエンティティを組み合わせて集計を形成し、集計ルート、値オブジェクト、および集計内のエンティティを決定します。この図では、アグリゲート間の境界は第 1 層の境界であり、これらは同じマイクロサービス インスタンス内で実行され、この境界は論理境界であるため、点線で表されています。
ステップ 3: ビジネス境界やセマンティック境界などの要素に従って、境界付きコンテキストで 1 つ以上の集約を定義して、ドメイン モデルを形成します。この図では、境界付きコンテキスト間の境界は第 2 層の境界であり、将来のマイクロサービスの境界になる可能性があります。異なる境界付きコンテキストのドメイン ロジックは分離され、異なるマイクロサービス インスタンスで実行され、物理的に相互作用します。は物理的な境界であり、境界は実線で表されます。
これら 2 つの境界層があるため、マイクロサービスの設計は難しくありません。
戦略設計では、ドメイン モデルを確立し、ビジネス ドメインの境界を明確にし、共通言語と限定されたコンテキストを確立し、ドメイン モデル内のさまざまなドメイン オブジェクト間の関係を決定しました。この時点で、ビジネス側のドメイン モデルの設計は基本的に完了し、このプロセスによってアプリケーション側のマイクロサービス境界も基本的に決定されます。ビジネスモデルからマイクロサービスへ、つまり戦略設計から戦術設計へ移行する過程で、ドメインモデル内のドメインオブジェクトとコードモデル内のコードオブジェクト間のマッピング関係を確立し、ビジネスアーキテクチャとコードモデルを統合します。 system スキーマはバインドされています。ビジネスの変化に応じてビジネス アーキテクチャとドメイン モデルを調整すると、システム アーキテクチャも同時に調整され、新しいマッピング関係が同時に確立されます。
DDD とマイクロサービスの関係は次のとおりです。
上記の説明を踏まえて、DDD とマイクロサービスの関係をもう一度まとめてみます。
DDDはアーキテクチャ設計手法、マイクロサービスはアーキテクチャスタイルであり、どちらも本質的には高い応答性を追求し、アプリケーションシステム構築の複雑さをビジネス観点から分離するための手段です。どちらもビジネスから始めることを重視しており、その核心は、ビジネスの発展に応じてドメイン境界を合理的に分割することを重視し、既存のアーキテクチャを継続的に調整し、既存のコードを最適化してアーキテクチャとコードの活力を維持することです。進化的アーキテクチャと呼ばれることがよくあります。
DDD は主に、ビジネス ドメインの観点からドメイン境界を分割し、効率的なコミュニケーションのための共通言語を構築し、ビジネス抽象化によるドメイン モデルを確立し、ビジネスとコード間の論理的一貫性を維持することに重点を置いています。
マイクロサービスは主に、プロセス間通信、実行時のフォールトトレランスとフォールト分離に焦点を当て、分散データ管理と分散サービスガバナンスを実現し、マイクロサービスの独立した開発、テスト、構築、展開に焦点を当てています。ビジネスとコードの論理的一貫性を維持するためにドメイン モデルを確立します。マイクロサービスは主に、プロセス間通信、実行時のフォールトトレランスとフォールト分離に焦点を当て、分散データ管理と分散サービスガバナンスを実現し、マイクロサービスの独立した開発、テスト、構築、展開に焦点を当てています。
要約する
全体として、DDD は次の利点をもたらします。
1. DDD は完全かつ体系的な設計手法であり、戦略設計から戦術設計までの標準設計プロセスを実現し、設計アイデアをより明確にし、設計プロセスをより標準化します。
2. DDDは、ビジネスが複雑化するドメイン関連の製品開発を得意とし、中核となる安定したドメインモデルを確立し、ドメイン知識の継承・継承に貢献します。
3. DDD は、チームとドメイン専門家間の協力を重視します。これにより、チームが良好なコミュニケーション雰囲気を確立し、一貫したアーキテクチャ システムを構築することができます。
4. DDD の設計アイデア、原則、パターンは、アーキテクチャ設計能力の向上に役立ちます。
5. 新しいプロジェクトでマイクロサービスを設計している場合でも、システムを単一のアーキテクチャからマイクロサービスに進化させている場合でも、DDD のアーキテクチャ原則に従うことができます。
6. DDD はマイクロサービスだけでなく、従来のモノリシック アプリケーションにも適用できます。