この記事では、DDD、ミドルプラットフォーム、マイクロサービスの関係についてお話しましょう。
DDD とマイクロサービスは西洋で生まれましたが、Zhongtai は中国のアリババで生まれました。DDD は 20 年以上前に提案されて以来、黙々と進められてきましたが、ミドルプラットフォームやマイクロサービスという概念は近年登場し、提案されてから非常に普及しました。この3つは一見無関係に見えますが、実は密接に関係しています。ミドルプラットフォームは抽象化されたビジネスモデルであり、マイクロサービスはビジネスモデルをシステムで実現するものであり、方法論としては、DDD はミドルプラットフォームのビジネスモデリングとマイクロサービス構築を同時に導くことができ、この 3 つは相互に補完し合います。完璧に組み合わされています。
なぜ DDD がミドルエンドおよびマイクロサービスの構築を導くことができるのか、また DDD はどのような役割を果たしているのかと疑問に思う人もいるかもしれません。
DDD には、戦略設計手法と戦術設計手法という 2 つの鋭い武器があります。
ミドル オフィスは、エンタープライズ アーキテクチャの観点からビジネス モデルに偏っており、ミドル オフィスの形成プロセスは、実際にはビジネス分野の継続的な細分化のプロセスです。このプロセスでは、同じ種類の一般的なビジネス機能を集約して再構築し、限定されたコンテキストとビジネスの結合の原則に基づいてドメイン モデルを構築します。そして DDD の戦略設計で最も優れているのはドメイン モデリングです。
ミドルプラットフォームでのドメインモデリングが完了したら、マイクロサービスによるシステム構築を完了する必要があります。現時点では、DDD の戦術的設計はマイクロサービスの設計と完全に組み合わせることができます。ミドルプラットフォームとマイクロサービスはDDD実戦に最適なシナリオと言えるでしょう。
DDDの本質
後で使用する DDD ドメイン、サブドメイン、コア ドメイン、一般ドメイン、およびサポート ドメインの概念を簡単に確認してみましょう。
DDDは、ビジネス上の問題を調査・解決する際に、一定のルールに従ってビジネスドメインを細分化し、ドメインがある程度細分化された後、問題の範囲を特定の境界に限定し、その境界内でドメインモデルを確立します。次に、コードを使用してドメイン モデルを実装し、対応するビジネス上の問題を解決します。
ドメインをモデル化するのに適していると判断できるまで、ドメインをサブドメインに分割したり、サブドメインをさらにサブサブドメインに細分したりすることができます。また、サブドメインは、その重要性や機能特性に応じて、コアドメイン、サポートドメイン、一般ドメインの3種類に分類されます。これら 3 種類のサブドメインの詳細については、「ドメイン、サブドメイン、コア ドメイン、一般ドメイン、およびサポート ドメイン: 愚かな混乱」を参照してください。
次に、上の図を一緒に見てみましょう. 保険の重要な領域をいくつか選択し、高レベルのドメイン分割を実行しました。もちろん、各企業の分野の位置づけや責任は多少異なりますので、中核領域の分け方にも多少の違いは必ず出てきます。したがって、ドメイン分割を行う場合は、DDD ドメイン モデリングの重要性を反映する企業戦略と必ず組み合わせてください。
ドメイン分割とさらにサブドメイン分割を通じて、企業内のさまざまなサブドメインの機能的属性と重要性を区別し、エンタープライズ IT システムの構築プロセスにおいて非常に重要な、さまざまなリソース投資と構築戦略を採用することができます。このような部門は、企業が中間段階で設計するのにも役立ちます。
中台の本質
Zhongtai は、Ali の Zhongtai 戦略に由来します (Zhong Hua 編『Enterprise IT Architecture Transformation: Alibaba's Zhongtai Strategic Thought and Architecture Actual Combat』を参照)。2015年末、アリババグループは、デジタル時代に合わせて「大・中・小のフロントデスク」のより革新的で柔軟な組織メカニズムとビジネスメカニズムを構築するための中台戦略の包括的な立ち上げを発表した。ミドルオフィスは、グループ全体の業務データ機能と製品技術力を統合し、各フロントエンドビジネスを強力にサポートします。
実際、Zhongtai の本質は、さまざまなビジネス部門の共通のニーズ、抽象的なビジネスとシステムを洗練し、共通で再利用可能なビジネス モデルを形成し、フロントエンド部門が使用できるコンポーネント化された製品を作成することです。フロントデスクはどのようなビジネスを望んでいて、どのようなリソースが必要ですか? ミドルデスクに直接行くことができ、毎回最下層を変更する必要はありません。
DDD、ミドルプラットフォーム、マイクロサービスの連携モデル
私たちは[Zhongtai: デジタル変革後に何を共有する必要がありますか?]にいます。】伝統的企業とアリの中国・台湾戦略の違いについてはすでに述べましたが、実際には、より多くの企業が依然として伝統的企業の中国・台湾構築モデル、つまり、さまざまなニーズを満たすためにすべての一般的および中核的能力を集中化することに焦点を当てるでしょう。チャネルのコアビジネス機能を再利用し、引き続き従来の企業に焦点を当てます。
従来の企業は、共有する必要があるパブリック機能をモデル化し、共有可能な共通プラットフォームを構築できます。さらに、従来型の企業は、コア機能のドメイン モデリングを実施し、さまざまなチャネル向けに再利用可能なコア ミドル プラットフォームを構築します。
ここでいう一般ミドルプラットフォームとコアミドルプラットフォームは、いずれも前回の記事で述べたビジネスミドルプラットフォームの範疇に属します。
DDD のサブドメインは、コア ドメイン、一般ドメイン、サポート ドメインに分かれています。これらのサブドメインを分割する主な目的は、戦略的リソースの投資を決定することですが、一般に、戦略的投資の焦点はコアドメインであるため、サポートドメインと一般ドメインを一時的に厳密に区別することはできません。
ドメイン、ミドルプラットフォーム、マイクロサービスは異なるレベルに属しますが、これらを分解して比較することで、それらの間の関係を整理することができます。下の図を見てください、私は同じ企業のビジネス アーキテクチャを DDD ドメイン モデリングとミドル プラットフォーム構築という 2 つの異なる観点から分析しています。
企業内の業務ドメイン全体を問題ドメインとすると、企業内のすべての業務がドメインとなる。ドメインを細分する場合、DDD の観点から、サブドメインはコア ドメイン、一般ドメイン、およびサポート ドメインに分割できます。ミドルプラットフォーム構築の観点から、事業ドメイン分割後のビジネスミドルプラットフォームは、コアミドルプラットフォームと一般ミドルプラットフォームに分けることができます。
ドメイン機能の属性と重要性の比較から、一般ミドルプラットフォームは DDD の一般ドメインとサポートドメインに対応し、コアミドルプラットフォームは DDD のコアドメインに対応します。ドメインの機能範囲から見ると、サブドメインはミドル オフィスと一致します。ドメイン モデルが存在する境界付きコンテキストは、マイクロサービスに対応します。このマッピング関係を確立したら、DDD を使用してミドルエンド ビジネスをモデル化できます。
ここでも保険分野を例に挙げます。保険領域のビジネス センターは 2 つのカテゴリに分かれています。
- 1 つ目のカテゴリは、保険の中核的なビジネス機能 (マーケティング、引受業務、保険金請求など) を提供する中核的なミドル オフィスです。
- 2 番目のカテゴリは、保険プロセス全体 (注文、支払い、顧客とユーザーなど) を完了するためのコア ビジネス プロセスをサポートする一般的なミドル プラットフォームです。
ここで思い出していただきたいのですが、DDD はまず共通言語を確立しなければならないという原則に従って、ミドル プラットフォームの設計に DDD 手法を導入する場合、まずミドル プラットフォームと DDD の間に共通言語を確立する必要があります。ここでのサブドメインはミドル プラットフォームと一致しているため、サブドメインをミドル プラットフォームとして統合できます。
ミドル オフィスはイベント ストームを通じてさらに細分化され、最終的にビジネス ドメインのモデリングが完了します。ミドルエンド ビジネス ドメインの機能は異なり、境界コンテキストの数とサイズが異なり、ドメイン モデルも異なります。
ビジネス モデリングが完了したら、DDD 戦術設計を使用して、集約、エンティティ、ドメイン イベント、ドメイン サービス、アプリケーション サービスなどのドメイン オブジェクトを設計し、次に階層化アーキテクチャ モデルを使用してマイクロサービスの設計を完了できます。
上記は、アプリケーションプロセスにおける DDD、ミドルプラットフォーム、マイクロサービスの連携モードです。
中間プラットフォームをモデル化するにはどうすればよいですか?
3 つの連携モードを読んだ後、上記のトピックに従い、次にミドル プラットフォーム モデルがどのように作成されるかについて話しましょう。
ミドルオフィスにおけるビジネス抽象化のプロセスはビジネスモデリングのプロセスであり、DDDの戦略設計に相当します。システム抽象化のプロセスはマイクロサービスの構築プロセスであり、DDDの戦術設計に相当します。
次に、DDD ドメイン モデリング手法を組み合わせて、ミドルエンド ビジネス モデリングのプロセスについて説明します。
- ステップ 1: ビジネス プロセス (通常はコア ドメインに適用) または機能属性とコレクション (通常は一般ドメインまたはサポート ドメインに適用) に従って、ビジネス ドメインを複数の中間ステーションに再分割し、機能属性またはサポート ドメインに従って分類します。重要性 コアミドルプラットフォームまたは一般ミドルプラットフォームに移動します。コアミドルプラットフォームの設計ではコア競争力を考慮する必要があり、一般ミドルプラットフォームでは企業の観点から共有および再利用機能を考慮する必要があります。
- ステップ 2: 中間プラットフォームを選択し、ユースケース、ビジネス シナリオ、またはユーザー ジャーニーに従ってイベント ストームを完了し、エンティティ、集約、および限定されたコンテキストを見つけます。ドメインを順番に分解し、ドメイン モデルを確立します。異なる中間プラットフォームの独立したモデリングにより、一部のドメイン オブジェクトまたは関数が他のドメイン モデルで繰り返し出現したり、同じ集約されたドメイン オブジェクトまたは関数が他の中間プラットフォームに分散したりする可能性があり、その結果、ドメイン モデルが不完全であるか、ビジネスがまとまっていない。ここでは心配しないでください。このステップでは、最初にメイン ドメイン モデルを決定するだけで済みます。3 番目のステップでは、これらのドメイン オブジェクトを調整し、再編成します。
- ステップ 3: メイン ドメイン モデルに基づいて、他の中間段階のドメイン モデルをスキャンし、重複または再構築されたドメイン オブジェクトと機能が存在するかどうかを確認して判断し、メイン ドメイン モデルを調整して再構築し、最終的なドメイン モデルの設計を完了します。
- ステップ 4: 他のメイン ドメイン モデルを選択し、すべてのメイン ドメイン モデルが比較および再構築されるまでステップ 3 を繰り返します。
- ステップ 5: ドメイン モデルに基づいてマイクロサービスの設計を完了し、システムの実装を完了します。
上の図と組み合わせると、DDD中間局の設計プロセスが大まかに理解できます。DDD 戦略設計には、上記の第 1 ステップから第 4 ステップが含まれます。主に、ビジネスドメインをミドルオフィスに分解し、ミドルオフィスを分類し、ドメインモデリングを完了し、ミドルオフィスのビジネスモデルを確立します。DDD 戦術設計は 5 番目のステップで、ドメイン モデルをマイクロサービスにマッピングして、中間プラットフォームの構築を完了します。
したがって、保険フィールドを例にとると、ドメイン モデリングが完了した後、そこにデータを入力できます。ここでは一般的なミドルプラットフォームのうち、ユーザー、顧客、注文の3つのミドルプラットフォームを例として挙げます。カスタマー センターでは、顧客情報モデルと顧客ビュー モデルという 2 つのドメイン モデルが抽出されます。ユーザー センターでは、ユーザー管理、ログイン認証、権限モデルの 3 つのドメイン モデルが抽出されます。注文モデルは注文センターで抽出されます。
これが中期モデリングの全プロセスですが、もちろん、一見単純そうに見えて、複雑なビジネスに遭遇すると、常にさまざまな問題が発生しますが、そうでなければ、適用することはそれほど難しくありません。
要約する
今日は主に従来型企業のミドルプラットフォーム構築のアイデアについて議論し、DDD、ミドルプラットフォーム、マイクロサービスの関係を整理しました。DDD の戦略的設計はミドル オフィスのビジネス モデリングに使用でき、戦術的設計はミドル オフィスのマイクロサービスの設計をガイドできます。DDD と中国・台湾の完璧な組み合わせにより、貴社の中国・台湾建設がさらに強力になると私は信じています。