DDD は、一連の方法論と一連のアイデアです。多種多様なメタモデルと名目上の概念。その本質は指導理念に対応する解決策の「一つ」であり、初心者は見かけに囚われやすい。 「すべての DDD メタモデルは、実際の開発における特定の種類の問題を解決するために作成されている」ということを常に明確に理解しておく必要があります。さまざまなメタモデルに触れる際には、概念的表現に囚われず、問題解決の本質に立ち返って、自社のビジネスが直面する課題に基づいて検証することが大切です。
データ アーキテクチャ チームは、2018 年にビジネス ニーズに基づいて電話ロボットの開発を開始し、それからほぼ 5 年が経過しました。現在、このプラットフォームの下で 100 種類のロボットが構築されており、同社のディーラー、中古車、OEM、金融、その他の BU ビジネスにアウトバウンド コール機能を提供しており、1 日あたり数十万件のアウトバウンド コールが行われています。電話ロボット プロジェクトは具体化し始めましたが、その過程では多くの課題にも直面しました。これらの課題に対処するために、私たちのチームは最終的に再建と開発に DDD の考え方を採用しました。
DDD を適用する過程で、データ アーキテクチャ チームは独自の開発仕様の一部を実装しました。ここでは、いくつかの経験やアイデアを皆さんと共有し、出発点として役立つことを願っています。ここで説明しますが、多くの多変量モデルについてはこの記事では説明しておらず、具体的なケースも示していません。まず、長さの問題を考えてみましょう。 2つ目は、DDDの考え方を理解して、それぞれの事業を組み合わせて実践することですが、私の事業で例を挙げるのはあまり意味がありません。また、そのようなケースは簡単に見つかります。同時に、私たちのチームが直面した問題と解決策、実装プロセス、作成した開発仕様を全員で共有することは、より価値があると感じています。 DDD に興味がある学生、さらに詳しく知りたい学生、この記事について質問がある学生は、ディスカッションのために私に連絡することを歓迎します。
以下、ロボットプロジェクトで遭遇した課題、DDDがDDDである理由、DDD実装の手順、チームの改善点、理論から実践に至るまでの葛藤、今後の改善点とまとめについて、部分からシェアしていきます。 DDD アプリケーションで。
課題 1: ビジネス ロジックは非常に複雑です。さまざまなサービスにアクセスすると、さまざまなシナリオで特定のサービスに対応するための新しいロジックが常に追加されます。
例: プロセス内の意図認識ロジック。
インテント認識には複数の AI モデルの認識が必要です。複数のモデルで認識されたインテントは競合する可能性があり、矛盾するインテント構成ルールの間でトレードオフを行う必要があります。同時に、一部のコールド スタートまたは緊急最適化シナリオでは、リアルタイムで有効になるようにルールを構成することで意図の識別をサポートする必要があります。また、ルールの意図認識では、単語スロットの一致がサポートされる必要があります。ワードスロットには多くの種類があり、優先順位によりシナリオ付きのグローバルワードスロットとプロセス付きのワードスロットに区別されます。データ識別のソースから、AI によって識別されたもの、辞書ルールによって照合されたもの、またはビジネス パーティから渡されたものに分類できます。ビジネスが一定期間実行されると、さまざまな属性がさまざまなタイプのスロットに追加されます。たとえば、自動車シリーズのスロットには、製品、事業範囲、非稼働などが含まれます。
課題 2: コード アーキテクチャの構造が明確ではありません。ビジネス要件が追加されると、コード サイズが増加します。ロジックの複雑さとチーム開発者のさまざまなコードが相まって、さまざまな論理境界が徐々に混乱していきます。
例: 当社の通常の開発手法は、機能モジュールごとに分解し、ビジネス プロセスを直列に接続して各モジュールを調整し、ビジネス要件を共同で完了するというものです。ただし、この種のビジネスの複雑なロジックを扱う場合、このソリューション設計には大きな欠点があり、モジュールの境界を簡単に突破してしまいます。
モジュール間の関係は相互に呼び出します。モジュールの元の分離設計は、実際には実装プロセス中に完全に壊れました。本来理想的な縦分割モジュールが網目状の構造になります。
途中のモジュールマネージャーが開発した属性やメソッドは他の外部モジュールに依存するため、機能が分岐してしまいます。これは、後から要件が変更されたときのリスクの増加につながります。あるいは、自由に変更できるメソッドが変更できず、それを実装するには追加のロジック コードを追加する必要があることが判明する可能性があります。これにより、すでに複雑なコードがさらに複雑になります。
業務要件の分解に無理がある 必要な機能を実装時に近くに開発する 厳密にモジュールに沿った分解ではなく、指針となる統一的な考え方が欠如している
課題 3: 製品には多くの需要があり、それらに本当の価値があるかどうかを区別するのが困難です。
課題 4: ロジックは急速に変化し、多くの要求によりコード ロジックの再設計が必要になります。
課題 5: 多くのビジネスがあり、各ビジネスの説明に一貫性がなく、コミュニケーション コストが高くなります。
垂直方向の境界は破壊され、コードは複雑になり、ビジネス プロセスは頻繁に調整されます。これらの複数の側面が互いに重なり合うため、開発とメンテナンスが飛躍的に困難になります。電話ロボットの第 1 レベルのアプリケーション システムの安定性を保証することは困難です。技術クラスのクラスメートが全員上級エンジニアであっても、自分が理解できるマイクロサービスの考え方に従って設計し、プロジェクトをモジュールごとに分解し、コードロジックが多くの設計パターンを引用して構築・拡張していても、接続されていたとしても社内のさまざまな部分に、プラットフォーム品質ツールを提供し、多くの単体テストを作成しました。しかし、プロジェクトの新しい要件が繰り返されると、依然として多くの「驚き」が現れ、チーム全体の頭痛の種になりました。
なぜ DDD なのか?毎日、非常に多くのテクノロジースタックやアイデアが存在しますが、それらに対処するために DDD が使用されるのはなぜでしょうか?まず第一に、DDD は「ソフトウェアの核となる複雑さにどう対処するか」を非常にうまく修正しており、多くの人がそれを知りたくなるのです。それでは、プロジェクトで遭遇する課題を DDD がどのように解決するかを見てみましょう。
まず、DDD の複雑さの分類を見て、DDD が対処しなければならない複雑さが私が直面している課題であるかどうかを判断しましょう。 DDD関連教材では、理解力と予測力の2つの側面から複雑さの原因を探り、分析します。
理解力 (つまり、ソフトウェア システムが複雑で開発者にとって理解するのが難しい):
最初のスケール: 理解力に影響を与える最初の要素。コードは数億行あり、各要求ポイント間の関係は相互に影響を及ぼします。 1つの領域を変更すると、体全体に影響します。
2 番目の構造: 不合理または無秩序な構造は、開発者が機能を維持することを困難にします。
予測能力 (つまり、ビジネスの発展を予測するのが難しい):
要件が変化した場合、ソフトウェアの実装の方向性を予測するのが難しく、過剰設計の問題が発生するそしてアンダーデザインが発生します。過剰設計のため、多くのインターフェイスが予約され、コードの実装の複雑さを増すために多くのパターンが構築されましたが、後にそれらが使用されていないことが判明しました。設計が不十分で、要件の実現がその後の開発を考慮していない、変更があれば既存の設計を覆して再開発する必要があるなど、製品の設計能力の低さに不満が出る。
DDD の複雑さの原因は、規模、構造、変化として要約されます。規模と構造は理解の障害を生み出し、変化は予測の障害を生み出し、この 2 つが合計して複雑さの問題を形成します。
次に、DDD は単なるコード設計段階の理論ではなく、要件分析、アーキテクチャ マッピング、モデリング、実装に至るまでのプロセス全体の設計ガイダンスも含まれています。
需要分析の段階では、関連する指導理念を通じてビジネス価値を事前に正確に把握し、将来の変化の方向性を捉えることができます。アーキテクチャ マッピングの段階では、要件からアーキテクチャに至るプロセスの指針となるイデオロギーが与えられ、設計の重みと仕様が追加されます。サブドメインの分割、システムの階層化、および限定されたコンテキストのビジネス分類を通じて、システム アーキテクチャの明確性を確保し、システムの複雑さを軽減するためのガイダンス仕様が提供されます。モデリングと実装の段階では、ドメイン駆動設計に関連したメタモデルが与えられ、各部分の機能分割が明確になり、ビジネスニーズや将来の機能変更に迅速に対応できます。
もう一度、DDD によって与えられる指針となるイデオロギーを見てみましょう:
スケールの問題: 境界の打破。サブドメインと境界付きコンテキストを使用して逆アセンブリを分割および征服します。
分割統治の考え方を考慮して、DDD は、境界付きコンテキストとコンテキスト マッピングという 2 つの重要な設計メタモデルを提供します。
構造的な問題: 階層化されたアーキテクチャと境界のある分離。
階層化は、ビジネス ロジックと技術的な実装の複雑さの問題を分離する役割を果たします。 DDD によって導入された階層化アーキテクチャでは、ビジネス ロジックがドメイン層にカプセル化され、ビジネス ロジックをサポートする技術実装がインフラストラクチャ層に配置されます。ドメイン層の上のアプリケーション層はアプリケーション サービスをカプセル化し、コラボレーションのために 2 つを結合します。
変化の問題: 変化に向けて積極的に設計します。
変化をコントロールすることはできません。私たちができるのは変化を受け入れることだけです。需要分析段階では、5W の考え方を使用して変化パターンを特定し、ビジネスの変化を制御します。 DDD は、モデル駆動設計のメタモデルを使用して、境界付きコンテキストのドメインをモデル化し、分析、設計、実装を組み合わせたドメイン モデルを形成します。
最後に、DDD が提供するソリューションを見てみましょう。これにより、パターンに洗練された一連の設計メタモデルが導入され、ビジネス ソフトウェアが規模を制御し、構造を分割し、変化に積極的に対応できるようになります。
この部分での私たちの経験では、チーム内の誰かが先駆者として行動し、まず DDD 関連の概念の徹底的な調査にエネルギーを費やし、その後、それをチーム全体に同期させます。私たちのチームに関する限り、研究フェーズは細分化されており、どのくらいの時間がかかるかを見積もることは困難ですが、チーム科学普及フェーズは 4 回続き、8 時間かかりました。その後、チームの生徒は概念的な指導に基づいて迅速かつ深く学習する能力を身につけます。そして、チームメンバーを組織して互いに議論し、理解を確認します。
3.2.1 需要分析段階では、実際のニーズを特定するのに役立つ 5W モデルの理論的サポートが導入されます。変化の方向を積極的に制御し、無意味な要件を排除します。
この部分は、製品分析のニーズを理論的に裏付けるための 5W 理論であり、実際のニーズを特定し、ビジネスの発展方向をより適切に分析するのに非常に役立ちます。上の図に示すように、無効な要件をソースから削減することもできます。
3.2.2 サービス仕様を導入し、ドキュメントベースのコード ビジネス機能を実装します。これは、開発とその後の要件の分類に役立ち、単体テストのカバレッジの考慮事項としても使用できます。
私たちのチームが採用したサービス仕様テンプレートは次のとおりです:
番号: ビジネス サービスをマークする一意の番号。
名前: 動詞句の形式のビジネス サービス名。
説明:
として、
がイベントをトリガーするように
が必要です。
ロールによってアクティブにトリガーされるビジネス サービス イベントには、UI コントロールのクリック、特定の戦略、コンパニオン システムによって送信されるメッセージなどがあります。
基本プロセス:
ビジネス サービスの主要なプロセス、つまり正常に実行されるビジネス シナリオを表現するために使用されます。 「主要な成功シナリオ」とも言えます。
代替プロセス:
ビジネス サービス、つまり実行が失敗するビジネス シナリオを表現するために使用される拡張プロセス。
受け入れ基準:
箇条書き形式でリストされた、一連の受け入れ可能な条件またはビジネス ルール。
DDD のモデル駆動設計メタモデルのソリューションを学習します。その主な目的は、責任の境界、つまり境界づけられたコンテキストを分割し、従来のネットワーク構造の関係を垂直の分節関係に変え、相互依存を軽減することです。限られたオンラインテキスト分解とダイヤモンドドライブ設計の全体的な使用が、全体的なイデオロギーの指針を形成します。このシステムは階層化アーキテクチャを採用しています。 COLA 4.0
パッケージ命名、クラス命名、エントリおよびチーム内での終了 メッセージ契約およびその他の仕様を参照してください。ここで言いたいのは、参照基準はないということです。まずは DDD の考え方を理解していただき、業界のコンセンサスが高い命名スキームを参考にしていただければ幸いです。同時に、チーム メンバーのプログラミング スタイルの好みを考慮し、最終的には自分のチームのコーディング標準を策定する必要があります。
入力メッセージと出力メッセージの名前を例として使用してみましょう。関係者全員を考慮した結果、上記のような特に細かい命名方法は採用しませんでした。代わりに、チーム内の単純なコンセンサスは、入力パラメータは *request、出力パラメータは *response という命名標準です。
DDD のアイデアに基づいて、ビジネス上でイベント ストーミングを実施し、ガイダンスの下でグローバルな需要分析とアーキテクチャ マッピングの設計を実施します。統一された言語を使用し、ビジネスの限定されたコンテキストを特定します。
技術系学生は自分の業務に基づいて設計しますが、デモ情報を参考にすれば比較的簡単に見つかるのでここでは詳しく説明しません。これは、境界のあるコンテキストを識別するためのガイダンス プロセスである V 字型マッピング プロセスです。
コーディングにはテスト駆動開発を使用すること、つまり赤、緑、黄色を使用することをお勧めしますdrivers;
この方法は 3 つの法則に従っており、要件の過小設計と過剰設計の問題を改善できます。
| #法律 1 | たまたま失敗するテストを 1 つだけ作成します。新しく追加された機能の説明として。 |
| 法律 2 | 失敗したテストを合格させるだけでない限り、本番コードを作成しないでください。 |
| 法 3 | すべてのテストに合格した場合にのみ、コードのリファクタリングを実行するか、新しい関数の追加を開始します。 |
以上が電話ロボットチームの DDD 演習の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
