電話ロボットチームの DDD 演習

はじめに

DDD は、一連の方法論と一連のアイデアです。多種多様なメタモデルと名目上の概念。その本質は指導理念に対応する解決策の「一つ」であり、初心者は見かけに囚われやすい。 「すべての DDD メタモデルは、実際の開発における特定の種類の問題を解決するために作成されている」ということを常に明確に理解しておく必要があります。さまざまなメタモデルに触れる際には、概念的表現に囚われず、問題解決の本質に立ち返って、自社のビジネスが直面する課題に基づいて検証することが大切です。

背景

データ アーキテクチャ チームは、2018 年にビジネス ニーズに基づいて電話ロボットの開発を開始し、それからほぼ 5 年が経過しました。現在、このプラットフォームの下で 100 種類のロボットが構築されており、同社のディーラー、中古車、OEM、金融、その他の BU ビジネスにアウトバウンド コール機能を提供しており、1 日あたり数十万件のアウトバウンド コールが行われています。電話ロボット プロジェクトは具体化し始めましたが、その過程では多くの課題にも直面しました。これらの課題に対処するために、私たちのチームは最終的に再建と開発に DDD の考え方を採用しました。

DDD を適用する過程で、データ アーキテクチャ チームは独自の開発仕様の一部を実装しました。ここでは、いくつかの経験やアイデアを皆さんと共有し、出発点として役立つことを願っています。ここで説明しますが、多くの多変量モデルについてはこの記事では説明しておらず、具体的なケースも示していません。まず、長さの問題を考えてみましょう。 2つ目は、DDDの考え方を理解して、それぞれの事業を組み合わせて実践することですが、私の事業で例を挙げるのはあまり意味がありません。また、そのようなケースは簡単に見つかります。同時に、私たちのチームが直面した問題と解決策、実装プロセス、作成した開発仕様を全員で共有することは、より価値があると感じています。 DDD に興味がある学生、さらに詳しく知りたい学生、この記事について質問がある学生は、ディスカッションのために私に連絡することを歓迎します。

以下、ロボットプロジェクトで遭遇した課題、DDDがDDDである理由、DDD実装の手順、チームの改善点、理論から実践に至るまでの葛藤、今後の改善点とまとめについて、部分からシェアしていきます。 DDD アプリケーションで。

1. 直面する課題

課題 1: ビジネス ロジックは非常に複雑です。さまざまなサービスにアクセスすると、さまざまなシナリオで特定のサービスに対応するための新しいロジックが常に追加されます。

例: プロセス内の意図認識ロジック。

インテント認識には複数の AI モデルの認識が必要です。複数のモデルで認識されたインテントは競合する可能性があり、矛盾するインテント構成ルールの間でトレードオフを行う必要があります。同時に、一部のコールド スタートまたは緊急最適化シナリオでは、リアルタイムで有効になるようにルールを構成することで意図の識別をサポートする必要があります。また、ルールの意図認識では、単語スロットの一致がサポートされる必要があります。ワードスロットには多くの種類があり、優先順位によりシナリオ付きのグローバルワードスロットとプロセス付きのワードスロットに区別されます。データ識別のソースから、AI によって識別されたもの、辞書ルールによって照合されたもの、またはビジネス パーティから渡されたものに分類できます。ビジネスが一定期間実行されると、さまざまな属性がさまざまなタイプのスロットに追加されます。たとえば、自動車シリーズのスロットには、製品、事業範囲、非稼働などが含まれます。

課題 2: コード アーキテクチャの構造が明確ではありません。ビジネス要件が追加されると、コード サイズが増加します。ロジックの複雑さとチーム開発者のさまざまなコードが相まって、さまざまな論理境界が徐々に混乱していきます。

例: 当社の通常の開発手法は、機能モジュールごとに分解し、ビジネス プロセスを直列に接続して各モジュールを調整し、ビジネス要件を共同で完了するというものです。ただし、この種のビジネスの複雑なロジックを扱う場合、このソリューション設計には大きな欠点があり、モジュールの境界を簡単に突破してしまいます。

モジュール間の関係は相互に呼び出します。モジュールの元の分離設計は、実際には実装プロセス中に完全に壊れました。本来理想的な縦分割モジュールが網目状の構造になります。

途中のモジュールマネージャーが開発した属性やメソッドは他の外部モジュールに依存するため、機能が分岐してしまいます。これは、後から要件が変更されたときのリスクの増加につながります。あるいは、自由に変更できるメソッドが変更できず、それを実装するには追加のロジック コードを追加する必要があることが判明する可能性があります。これにより、すでに複雑なコードがさらに複雑になります。

業務要件の分解に無理がある 必要な機能を実装時に近くに開発する 厳密にモジュールに沿った分解ではなく、指針となる統一的な考え方が欠如している

課題 3: 製品には多くの需要があり、それらに本当の価値があるかどうかを区別するのが困難です。

課題 4: ロジックは急速に変化し、多くの要求によりコード ロジックの再設計が必要になります。

課題 5: 多くのビジネスがあり、各ビジネスの説明に一貫性がなく、コミュニケーション コストが高くなります。

垂直方向の境界は破壊され、コードは複雑になり、ビジネス プロセスは頻繁に調整されます。これらの複数の側面が互いに重なり合うため、開発とメンテナンスが飛躍的に困難になります。電話ロボットの第 1 レベルのアプリケーション システムの安定性を保証することは困難です。技術クラスのクラスメートが全員上級エンジニアであっても、自分が理解できるマイクロサービスの考え方に従って設計し、プロジェクトをモジュールごとに分解し、コードロジックが多くの設計パターンを引用して構築・拡張していても、接続されていたとしても社内のさまざまな部分に、プラットフォーム品質ツールを提供し、多くの単体テストを作成しました。しかし、プロジェクトの新しい要件が繰り返されると、依然として多くの「驚き」が現れ、チーム全体の頭痛の種になりました。

2.なぜ DDD なのか

なぜ DDD なのか?毎日、非常に多くのテクノロジースタックやアイデアが存在しますが、それらに対処するために DDD が使用されるのはなぜでしょうか?まず第一に、DDD は「ソフトウェアの核となる複雑さにどう対処するか」を非常にうまく修正しており、多くの人がそれを知りたくなるのです。それでは、プロジェクトで遭遇する課題を DDD がどのように解決するかを見てみましょう。

まず、DDD の複雑さの分類を見て、DDD が対処しなければならない複雑さが私が直面している課題であるかどうかを判断しましょう。 DDD関連教材では、理解力と予測力の2つの側面から複雑さの原因を探り、分析します。

理解力 (つまり、ソフトウェア システムが複雑で開発者にとって理解するのが難しい):

最初のスケール: 理解力に影響を与える最初の要素。コードは数億行あり、各要求ポイント間の関係は相互に影響を及ぼします。 1つの領域を変更すると、体全体に影響します。

2 番目の構造: 不合理または無秩序な構造は、開発者が機能を維持することを困難にします。

予測能力 (つまり、ビジネスの発展を予測するのが難しい):

要件が変化した場合、ソフトウェアの実装の方向性を予測するのが難しく、過剰設計の問題が発生するそしてアンダーデザインが発生します。過剰設計のため、多くのインターフェイスが予約され、コードの実装の複雑さを増すために多くのパターンが構築されましたが、後にそれらが使用されていないことが判明しました。設計が不十分で、要件の実現がその後の開発を考慮していない、変更があれば既存の設計を覆して再開発する必要があるなど、製品の設計能力の低さに不満が出る。

DDD の複雑さの原因は、規模、構造、変化として要約されます。規模と構造は理解の障害を生み出し、変化は予測の障害を生み出し、この 2 つが合計して複雑さの問題を形成します。

次に、DDD は単なるコード設計段階の理論ではなく、要件分析、アーキテクチャ マッピング、モデリング、実装に至るまでのプロセス全体の設計ガイダンスも含まれています。

需要分析の段階では、関連する指導理念を通じてビジネス価値を事前に正確に把握し、将来の変化の方向性を捉えることができます。アーキテクチャ マッピングの段階では、要件からアーキテクチャに至るプロセスの指針となるイデオロギーが与えられ、設計の重みと仕様が追加されます。サブドメインの分割、システムの階層化、および限定されたコンテキストのビジネス分類を通じて、システム アーキテクチャの明確性を確保し、システムの複雑さを軽減するためのガイダンス仕様が提供されます。モデリングと実装の段階では、ドメイン駆動設計に関連したメタモデルが与えられ、各部分の機能分割が明確になり、ビジネスニーズや将来の機能変更に迅速に対応できます。

もう一度、DDD によって与えられる指針となるイデオロギーを見てみましょう:

スケールの問題: 境界の打破。サブドメインと境界付きコンテキストを使用して逆アセンブリを分割および征服します。

分割統治の考え方を考慮して、DDD は、境界付きコンテキストとコンテキスト マッピングという 2 つの重要な設計メタモデルを提供します。

構造的な問題: 階層化されたアーキテクチャと境界のある分離。

階層化は、ビジネス ロジックと技術的な実装の複雑さの問題を分離する役割を果たします。 DDD によって導入された階層化アーキテクチャでは、ビジネス ロジックがドメイン層にカプセル化され、ビジネス ロジックをサポートする技術実装がインフラストラクチャ層に配置されます。ドメイン層の上のアプリケーション層はアプリケーション サービスをカプセル化し、コラボレーションのために 2 つを結合します。

変化の問題: 変化に向けて積極的に設計します。

変化をコントロールすることはできません。私たちができるのは変化を受け入れることだけです。需要分析段階では、5W の考え方を使用して変化パターンを特定し、ビジネスの変化を制御します。 DDD は、モデル駆動設計のメタモデルを使用して、境界付きコンテキストのドメインをモデル化し、分析、設計、実装を組み合わせたドメイン モデルを形成します。

最後に、DDD が提供するソリューションを見てみましょう。これにより、パターンに洗練された一連の設計メタモデルが導入され、ビジネス ソフトウェアが規模を制御し、構造を分割し、変化に積極的に対応できるようになります。

# この写真を 2 つの部分に分けて簡単に紹介します。最初の部分は、以下の点で囲まれた部分であり、特定の技術的な実装は含まれません。問題空間に対処するためのいくつかのメタモデル ソリューションは、要件分析段階で実行されます。残りの部分では、最初の部分に基づいて、具体的なシステム アーキテクチャの階層化、オブジェクトの抽象化と集約、サービスの分解を行い、この段階で対応する設計を実装します。

私の理解は次のとおりです。この一連の設計メタモデルは、需要分析、設計、実装に至るまでの完全なソリューションを提供します。要件分析段階でのシステム解体（図のサブドメインメタモデルに相当）。次に、それを更新粒度の限定されたコンテキストに分割します。そして、各制限の協調関係スキームが与えられます (図のコンテキスト マッピング メタモデルに対応)。設計実装フェーズでは、システムの階層アーキテクチャ、ドメイン サービス、集約などの詳細な設計を通じて、モデル駆動設計の設計要素計画を提供します。完全で理論的にサポートされ、実装可能な標準ソリューションのセットを提供します。

上記の DDD 分析と問題の複雑さの特定は、電話ロボット システムにとって完全に問題点です。提供されたソリューションは、ビジネスが直面するさまざまな課題も完全に解決します。その価値を認識した後、チームはすぐにそれを後続のプロジェクトに実装するという合意に達しました。

3. DDD 実装手順

メタモデルの詳細とビジネス境界については詳しく説明しませんが、私たちのチームの実際の手順と製品を直接示します。

3.1 調査前段階の最初のステップ

この部分での私たちの経験では、チーム内の誰かが先駆者として行動し、まず DDD 関連の概念の徹底的な調査にエネルギーを費やし、その後、それをチーム全体に同期させます。私たちのチームに関する限り、研究フェーズは細分化されており、どのくらいの時間がかかるかを見積もることは困難ですが、チーム科学普及フェーズは 4 回続き、8 時間かかりました。その後、チームの生徒は概念的な指導に基づいて迅速かつ深く学習する能力を身につけます。そして、チームメンバーを組織して互いに議論し、理解を確認します。

3.2 2 番目のステップは、指導的なイデオロギーと実装仕様を導入することです。

3.2.1 需要分析段階では、実際のニーズを特定するのに役立つ 5W モデルの理論的サポートが導入されます。変化の方向を積極的に制御し、無意味な要件を排除します。

この部分は、製品分析のニーズを理論的に裏付けるための 5W 理論であり、実際のニーズを特定し、ビジネスの発展方向をより適切に分析するのに非常に役立ちます。上の図に示すように、無効な要件をソースから削減することもできます。

3.2.2 サービス仕様を導入し、ドキュメントベースのコード ビジネス機能を実装します。これは、開発とその後の要件の分類に役立ち、単体テストのカバレッジの考慮事項としても使用できます。

• 3.2.2.1 チーム メンバー間のコンセンサスは、サービス仕様を最初に作成してから開発する必要があるということです。サービス仕様の作成に費やされる時間は、実際には要件の技術的な理解を整理し、アイデアを明確にすることに費やされるものであり、この部分の時間は、後でコードを書くときに取り戻すことができます。
• 3.2.2.2 サービス仕様と要件 サービス仕様は、単一のテストに対応します。ちなみに、以前は単一テストの標準が存在しなかった（私が理解しているコードとメソッドのカバレッジは標準とは言えません）という問題は解決されます。

私たちのチームが採用したサービス仕様テンプレートは次のとおりです:

番号: ビジネス サービスをマークする一意の番号。

名前: 動詞句の形式のビジネス サービス名。

説明:

として、

がイベントをトリガーするように

が必要です。

ロールによってアクティブにトリガーされるビジネス サービス イベントには、UI コントロールのクリック、特定の戦略、コンパニオン システムによって送信されるメッセージなどがあります。

基本プロセス:

ビジネス サービスの主要なプロセス、つまり正常に実行されるビジネス シナリオを表現するために使用されます。 「主要な成功シナリオ」とも言えます。

代替プロセス:

ビジネス サービス、つまり実行が失敗するビジネス シナリオを表現するために使用される拡張プロセス。

受け入れ基準:

箇条書き形式でリストされた、一連の受け入れ可能な条件またはビジネス ルール。

3.3 3 番目のステップは、アーキテクチャ ソリューションを決定することです。

DDD のモデル駆動設計メタモデルのソリューションを学習します。その主な目的は、責任の境界、つまり境界づけられたコンテキストを分割し、従来のネットワーク構造の関係を垂直の分節関係に変え、相互依存を軽減することです。限られたオンラインテキスト分解とダイヤモンドドライブ設計の全体的な使用が、全体的なイデオロギーの指針を形成します。このシステムは階層化アーキテクチャを採用しています。 COLA 4.0

3.4 ステップ 4: チームのコーディング仕様を形成するコンセンサス命名標準

パッケージ命名、クラス命名、エントリおよびチーム内での終了 メッセージ契約およびその他の仕様を参照してください。ここで言いたいのは、参照基準はないということです。まずは DDD の考え方を理解していただき、業界のコンセンサスが高い命名スキームを参考にしていただければ幸いです。同時に、チーム メンバーのプログラミング スタイルの好みを考慮し、最終的には自分のチームのコーディング標準を策定する必要があります。

入力メッセージと出力メッセージの名前を例として使用してみましょう。関係者全員を考慮した結果、上記のような特に細かい命名方法は採用しませんでした。代わりに、チーム内の単純なコンセンサスは、入力パラメータは *request、出力パラメータは *response という命名標準です。

3.5 5 番目のステップは、ビジネス特性に基づいて限定されたコンテキストを特定することです。

DDD のアイデアに基づいて、ビジネス上でイベント ストーミングを実施し、ガイダンスの下でグローバルな需要分析とアーキテクチャ マッピングの設計を実施します。統一された言語を使用し、ビジネスの限定されたコンテキストを特定します。

技術系学生は自分の業務に基づいて設計しますが、デモ情報を参考にすれば比較的簡単に見つかるのでここでは詳しく説明しません。これは、境界のあるコンテキストを識別するためのガイダンス プロセスである V 字型マッピング プロセスです。

3.6 ついにモデリングの実装段階に入ります

コーディングにはテスト駆動開発を使用すること、つまり赤、緑、黄色を使用することをお勧めしますdrivers;

この方法は 3 つの法則に従っており、要件の過小設計と過剰設計の問題を改善できます。

4. チームにもたらされる改善

4.1 ニーズの受動的受け取りから積極的な対応へ

ニーズ分析段階では、5W 原則を適用します。要求の合理性を分析し、プロジェクトの方向性の変化を積極的に制御できるようになります。 「課題 3」を解決して需要価値を特定し、「課題 4」を改善して事業開発の変化の方向性を制御します。

4.2 コミュニケーション コストの削減

統一された言語とイデオロギーのコミュニケーションを使用して、「チャレンジ 5」のあらゆる側面でコラボレーション コストを削減します。

4.3 アーキテクチャ設計の改善

サブドメイン モデルとメタ モデルの限定されたコンテキストを設計することにより、コード スケールを合理的に解体します。 DDD の階層化された考え方により、ビジネス ロジックの複雑さと技術的側面が分離され、コード構造が明確になります。同時に、このプロジェクトはダイヤモンド型の対称構造を採用し、モジュールのネットワークの発生を避けるために南北ゲートウェイを通じて外部と対話します。 「チャレンジ 2」の問題を解決し、「チャレンジ 1」の複雑さを軽減しました。

4.4 技術的な実装の改善

ビジネス機能を開発するとき、チームは要件の合理的な制限を考慮します。ドメイン層に配置するかビジネスサービス層に配置するか、機能実装時に貧血モデルや輻輳モデルを使用するかなどは実装時に検討していきます。

4.5 ドキュメント仕様の改善

ドキュメント仕様に関しては、サービス仕様メカニズムが導入されています。要件を整理するためのツールとして、また単一のテストの基礎として使用できます。同時に、後で使用できるようにサービス説明ドキュメントも提供されます。

4.6 コード実装の改善

コード実装に関しては、アーキテクチャからコーディング実装、命名まで、一連のマークされた仕様が形成されています。

一般的に、このモデルの下では、チームの考え方が変わりました。さまざまなメタモデルを適用することで、需要分析からシステム アーキテクチャ、コード実装に至るまで、さまざまな側面によってもたらされる課題に対処できます。

5. 理論から実践までの矛盾

5.1 貧血モデル PK 輻輳モデル

貧血モデル: 平たく言えば、ゲッター/セッターのみを持つドメイン オブジェクトです。属性のメソッド。純粋なデータ クラス、ビジネス ロジック、およびアプリケーション ロジックはすべてサービス層に配置されます。このモデルに基づくドメイン オブジェクトは、Martin Fowler によって「貧血ドメイン オブジェクト」と呼ばれています。

輻輳モデル: 逆に、輻輳モデルには、オブジェクトのプロパティだけでなく、ビジネス ロジックを含むオブジェクトの動作も含まれます。

オブジェクト指向の観点からは、オブジェクトには属性や動作が含まれるため、輻輳モデルを使用する必要があり、DDD も原則として輻輳モデルの使用を推奨しています。しかし、具体的な開発状況に関して言えば、貧血モデルには多くの問題があるにもかかわらず、業界では長年存在し、非常に一般的に使用されており、依然として価値があります。さらに、ほとんどの JAVA アプリケーションは Mybatis テクノロジー スタックを使用しており、多くのオブジェクトはプラグインによって自動的に生成される貧血エンティティです。そこで問題は、充血モデルを採用するということは、いくつかの便利なツールを放棄することを意味するということです。この問題に関してはチーム内で大きな意見の相違があります。結局のところ、私たちのアプローチでは、この部分に厳密な基準はありませんが、充血モードを使用することをお勧めします。

5.2 データ変換の制約を厳守する

PK は、外部データを直接利用して効率的かつ効率的に利用します。

DDD の考え方では、ドメイン サービスの信頼性を確保します。ドメイン サービスが依存するデータは、ドメイン内のエンティティおよび集約データである必要があり、外部メッセージ コントラクト データの直接使用は許可されていません。ダイヤモンド対称アーキテクチャに対応する南北ゲートウェイから取得したデータの変換には、追加の作業負荷がかかります。チームメンバーの中には、特定の比較的安定した構造については、この原則に従う必要はない、と提案した人もいましたが、その理由は、開発速度を向上させることができ、データの 90% はデータベースなどの比較的安定した構造を持つリソースである可能性があると考えているからです。しかし最終的には、チームは依然としてこの指導的イデオロギーを遵守することが厳しく要求されました。

5.3 キャッシュ処理により、共有 PK 境界分離が可能になります。

同じシステムの異なる境界でのキャッシュ処理: 共有 PK 境界分離が可能になります。

当時のシナリオから判断すると、共有を許可すると、短期的には作業負荷が軽減され、リソースが節約される可能性があります。しかし、境界線を引く必要がある理由は、関係を解消し、関係が大きくなりすぎないようにするためです。ここでの提案は、データを共有するサービスを 1 つの境界に統合することが合理的かどうかをまず検討することです。マージできない場合は、データを分離する必要があります。

5.4 サービス仕様では、要件のフロントエンド PK とバックエンドを比較しています

理論的な指針となる考え方は非常に美しく、要件分析中は技術的な実装の考え方を保護する必要があります。しかし、結局はテクノロジースタックに実装する必要があり、テクノロジーの実装となると、テクノロジーの実装によって干渉されてしまいます。当時の顕著な問題は、機能の実装がフロントエンドに配置されるか、バックエンド サービスとして実装されるかということでした。

例 1: 要件では「ID 名」の組み合わせ表示が必要ですが、バックエンド インターフェイスから返される ID と名前の 2 つのフィールドは実際のフロントエンド テクノロジ スタックによって結合されるため、サービス仕様はフロントエンドとバックエンドが矛盾しています。

例 2: 要件では、パラメーターが空ではないことの検証が必要です。一部の社内システムでは、当社の技術チームはフロントエンドとバックエンドのフルスタックエンジニアで構成されており、ニーズに応じて作業を分担してモジュールを開発しています。多くの場合、両端を検証するほど厳密ではありません。また、サービス仕様がどちらの目的を指向しているのかという矛盾も生じます。

私たちの最終的な選択: チームはバックエンド サービス層を採用します。ただし同時に、検証やその他の機能をインターフェイス レベルに移動するなど、いくつかの改善も行います。

5.5 サービス仕様書が正しく書かれていることを誰が保証するのか? Product PK Technology

初期段階では、理想的な状態は誰が必要とするかという原則に基づいて、デマンドサイドの製品によって検証されます。それを確認します。ただし、4.4 の違いにより、実際の実装は技術担当者によってレビューされます。

6. DDD アプリケーションの今後の改善点と概要

チームは現在、アーキテクチャと仕様の観点から DDD のアプリケーションを実装しています。ただし、集約クラス、エンティティ、値オブジェクトの設計など、一部の詳細は特に詳しく説明されていません。今後もこうしたきめ細かな改善をさらに進めていきます。同時に、使用中のいくつかの古いプロジェクトは、DDD のアイデアに従って変換および再構築されます。

DDD を適用すると開発効率が低下すると考える人もいますが、これは多くのチームも懸念しています。 DDD を適用するシナリオは、複雑なビジネス上の問題を解決することであり、実際にコードの量は増加します。しかし、それは開発効率を下げることを意味するものではありません。明確なアーキテクチャ構造、集約されたドメイン サービス、および標準化された標準は、その後の要求のアップグレード、コードのメンテナンス、および複雑さの制御への投資よりもはるかに大きなメリットをもたらします。さらに、ソフトウェア業界が提供するデータによると、時間の 80% がオンデマンドの分析と設計に費やされているのに対し、開発時間は 20% のみです。したがって、損失のこの部分は焦点ではありません。

最後に、DDD を使ってみて感じたことを述べておきます。 DDD メタモデルには多くの種類があり、誰もがビジネスが直面する問題点に基づいて目的を持って学習し、導入することができます。実際のビジネス環境では、ドメインモデルには多かれ少なかれ「特殊性」があり、DDD仕様に100%準拠するとコストが割高になる可能性があるため、DDDの考え方を理解し、最終的な仕様を決めることが最も重要です。あなたのビジネスに合ったソリューションを選択してください。

著者について

Li Xiaohua

• ディーラー事業部-ディーラー技術部。
• 2016 年にオートホームに入社し、現在はディーラー データ アーキテクチャ チームで電話ロボット プロジェクトを担当しています。

#法律 1	たまたま失敗するテストを 1 つだけ作成します。新しく追加された機能の説明として。
法律 2	失敗したテストを合格させるだけでない限り、本番コードを作成しないでください。
法 3	すべてのテストに合格した場合にのみ、コードのリファクタリングを実行するか、新しい関数の追加を開始します。

以上が電話ロボットチームの DDD 演習の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。