話しましょう、DDD についての私の重要な理解

著者: Min Dawei Ali ビジネス プラットフォーム ソリューション チーム

DDD を学習する過程で学ぶことができないと感じるとき、私たちはこう尋ねるかもしれません。「まだ学ぶ必要があるのか​​?」これは実に考えさせられるものです。この記事では、実務経験に基づいて、DDD についての理解を説明しようとします。

1. はじめに

「フォレスト・ガンプ」では、フォレスト・ガンプがノンストップで走り始め、しばらくすると多くの信者たちが一緒に走りました。

• フォレスト・ガンプ: 分からない、ただ走りたいだけだ。

• フォロワー: そうすることに意味があると感じていますし、『フォレスト・ガンプ』は今もその先を進んでいます。

同様に、私も最初は DDD が何なのか知りませんでしたが、みんなが DDD について言及し、DDD を学んでいるのを知ったとき、私も思わずランナーのように運動に参加しました。大きな牛が DDD を提案したので、たくさんの人が群がっていたので、それには、何か望むものがあるはずです。

しかし、ある日、A-ガンプは走るのをやめ、走りたくなくなり、信者たちは問題に遭遇しました。「私たちはまだ走りたいのか？」DDD を学習する過程で学ぶことができないと感じるとき、私たちはまた、「まだ学ぶ必要があるのか​​?」と尋ねることもあります。これは実に考えさせられるものです。

この記事では、実務経験に基づいて、DDD を学習する意味をより深く探求することを期待して、DDD についての理解を説明しようとします。

2. DDD の価値に注目する

ビジネスを行っている場合でも、プラットフォームやミドル オフィスを行っている場合でも、絡み合って複雑なビジネス ロジックと、あいまいに結合されたビジネス コードによって疲れ果てることがよくあります。皆さんの DDD の追求は、事業開発への容易な支援の要求でもあり、現状を改善できる適切な理論がないかを模索していると思います。結局のところ、より良い生活は共有されるのです。

2.1 ステータス: 階層化されたサポートメカニズム

生産効率の向上を核として、さまざまな枠組みを選択し、さまざまな組織設計を行っています。ただし、ビジネス ロジックがケースバイケースで実装され、再利用できない場合、研究開発コストが非常に高くなり、投資サイクルが非常に長くなります。

再利用を増やし、サービスのランディング時間を短縮するには、多くの汎用機能と製品が必要です。当社の配信プロセスには、主に次の 2 つの層があります。

• 基本機能:比較的アトミックな機能は基本 (ドメイン) 機能であり、ビジネスのカスタマイズをより適切にサポートできます。基本的なものを比較するため、表現される製品機能の範囲も非常に大きくなります。ただし、完成した製品には多くの基本機能が直列に必要であり、直列接続のコストも非常に高くなります。

• プラットフォーム製品:基本機能の多用途性は、現場の理解が不足しており、生産効率をさらに向上させるための「遺伝子」が不足していることを意味します。したがって、納品時には、抽象化はいくつかの高頻度シナリオに基づいてプラットフォームの製品機能を形成し、「すぐに使える」状態を実現するよう努めます。「プラットフォーム製品」レイヤーをベースにビジネスをカスタマイズすると、理解コストが大幅に削減されます。

層状サポートフレーム

2.2 破損: ビジネスロジックの侵入

このレベルは非常に優れているように見えます。初期段階では、歴史的な負担がないため、確かに特定の生産効率を向上させることができ、これは能力自体の利点です。しかし、時が経つにつれ、ビジネスアクセスの増加に伴い、企業同士が影響し合うようになり、研究開発に対する抵抗も増大しています。

研究開発効率が低下する重要な理由は、私たちが依然として「事業をどれだけ速く、どれだけ早く実行できるか」というロジックに従って関連作業を行い、水に遭遇したら橋を架け、山に遭遇したら穴を開け、そしてその後、目的地に直接行き、情報を伝達し、データベースフィールドの操作を行います。

このようなプロセスは、「クリーンなカーネルを確保しながら、ビジネス シナリオを通じてプラットフォームの機能を強化したい」という私たちの当初の意図に反します。機能は、比較的多数のユース ケースと比較的完全な考え方に基づいて抽象化される必要があります。これは水平方向の統一的な見方であり、より深い理解が得られます。ただし、垂直方向の配信では、より垂直方向に問題に対処できますが、多くの場合、単に「覗き見」するだけです。納期や業務ノードの制約のもとでは、より包括的かつ深く考えることは難しく、より一般的な設計を行うことは困難です。

2.3 抵抗: プラットフォーム フレームワーク ガード

では、なぜ DDD に注目するのでしょうか? DDD がソフトウェアの複雑さの中核である「問題領域」に直接的に影響を与えるとしても、それは依然として比較的抽象的なものである可能性があります。具体的には、これは私たちが追求する[長期的な生産性の向上]という価値観と実際に一致しているためです。

• 分野を細分化し、プロフェッショナルな人やモノを育てる： DDDの核心は、各分野をよく理解してパッケージ化し、ビジネス要件を分解して適切な場所に配置することであるため、そのような分解と沈殿を通じて、インプットが長期にわたって達成できるドメインを確保します持続可能な発展を実現し、競争力を形成します。

• 変更可能なものに依存しないメカニズムの保証: DDD は実際に多くの共通のスキルと経験を要約しており、そのような実装をより決定論的にすることができます。ドメイン エンティティを制御する集約ルートの機能、境界付きコンテキストの相互作用戦略、ドメイン コアの抽象ステータスなど、一度尊重して確認することを選択すると、組織的なコード構造に陥る可能性があります。合意形成が図られており、人事異動などによって大きく変動することはありません。

DDDへのこだわりは「職人気質」へのこだわりに例えられますが、DDDへのこだわりはビジネス理解へのこだわりでもあります。ビジネスに近づくには、ビジネスを理解する必要があります。ビジネスを理解するだけでなく、ビジネスのほとんどを理解する必要があります。この種の追求により、レベルを上げて最も本質的な質問、つまりどのような問題を解決したいのかに戻ることができます。どうすればより良く解決できるでしょうか？

3. DDD の学習の難しさ

あなたがそれほど混乱しているかどうかはわかりませんが、DDD の学習プロセスは、「干し草の山から針を見つける」プロセスのように思えます。たとえ何かを手に入れて使うことができたとしても、やはり「偽物感」が残り、あまり自然ではありません。DDD を学ぶのはなぜそんなに難しいのでしょうか?

3.1 感情: ドアがない

論語の次の場面は、私たちの混乱とよく似ています。

呉淑玉叔父が法廷の医師に「中尼よりも子貢のほうが価値がある」と子府景波が子貢に告げると、子貢はこう言った、「たとえば、宮殿の壁、与えられた壁も肩まであるし、あなたはあなたにぴったりです」家の美しさを見ることができます; マスターの壁は10万にも達し、門には入ることができません. 祖先の寺院の美しさと何百もの役人の富は見られません. 門を勝ち取る者は数が少ないかもしれないし、マスターの雲はふさわしくない！」

孔子が達成した境地を感じたいのと同じように、自分自身の知識をある程度蓄積する必要もあります。DDD の力を感じたい場合は、共鳴と認識を形成するために、ある程度成長する必要があります (成功または失敗した設計を経験したことがある、自分自身の経験や教訓があるなど)。

確かに、仕事の中で DDD のベストプラクティスはほとんど見られません。複雑なビジネスに直面して、どのソフトウェア構造が理想的な設計であるかを言う勇気のある人は誰もいません。

• これは決定論的な問題の分解ではないため、設計は顕微鏡下で研究され、さまざまな反例が常に見つかります。

• さらに、ベスト プラクティスは静的な結果ではなく、拡張のために設計を残し、ビジネス開発を反復できるように、十分に「ソフト」でなければならないことを私たちは知っています。

したがって、学びの扉を開くということは、少数の事例で一朝一夕にできるものではなく、自分自身の仕事と組み合わせて、ゆっくりと経験を積み上げていく必要があります。

3.2 難易度: パターンの分岐

DDD とは一体何なのか、混乱しています。

• 実践の例は説得力がありません。「DDD の実践」を見ると、「これも DDD ですか?」と疑問に思うかもしれません。これは、単なる通常のサーバー側フレームワークやソリューションではなく、他のシナリオや部門システムをカバーすることもできません。

• 抽象的な理論は空虚に感じられます。「抽象的な DDD の定義と戦略」を見ると、「これも DDD とみなされますか?」と疑問に思うかもしれません。それは単なるソフトウェア設計のコンセンサスではなく、いくつかの名詞の定義が課せられ、いくつかの戦略が私たちのシステムと一致しないのではありませんか。

抽象化を見ても、具体的な実装を見ても、説得力のある（決定論的な実装が可能な）理論や実践を見つけることは困難です。これは 23 のデザイン パターンとは異なるため、ほとんどのパターンは N 個のテンプレートでカバーできます。

特定のパターンを生成できないのはなぜですか? 次の図を詳しく見てみましょう。

• 抽象理論:抽象インターフェイスと同様に、「DDD の理解」の最上位の学習は主に、集約ルート、値オブジェクト、リソース ライブラリ、コア ドメイン、サポート ドメイン、その他の定義など、理解しやすく把握しやすい理論的な定義です。

• 一般的な実践:比較的具体的な抽象クラスと同様に、「DDD の理解」の中級レベルは、コンテキスト マッピング戦略、アーキテクチャの選択など、いくつかの一般的な原則とテクニックです。これらの要素は確かですが、トレードオフと選択を独自に行う必要があり、時代に追いつく必要があり、漸進的な部分は自分で学び、補う必要があります。

• 特定の実践:特定のクラス インスタンスと同様、「DDD の理解」の下位レベルは、さまざまな要素を設計、選択、補足するための、それぞれのビジネス シナリオと組み合わせた一連の特定の実践です。多くの選択肢が含まれるため、最終的な選考結果が乖離することも多く、人々は「千人には千の顔がある」と感じさせます。

2 つの違いは次のとおりです。

• 「コード抽象化レベル」の階層関係は比較的明確であり、制限されています。

• 「ドメイン主導の理解レベル」には明確な制約はなく、複数の戦略といくつかの重要な提案のトレードオフです。

したがって、問題の抽象度が高く、さまざまな戦略の不確実性が高いため、DDD では「23 の設計パターン」ほど洗練されたパターンを生成することは困難です。もしあるとすれば、それは比較的発散する一連のパターンでもあります。

DDD 理解レベルの類似性

したがって、DDD はソフトウェアの「ソフト」を重視しており、あらゆる側面をカバーしていることが徐々に理解できます。DDD を深く理解するには、これらの詳細かつシンプルな提案を理解するまでに「何千回もの試行」が必要です。そうすれば、「マスターが扉を導き、実践は個人に依存する」というモットーを理解できるようになります。 「群衆は何千回も彼を探しますが、その人は世界にいます。」薄暗い場所での素晴らしい瞬間。

4 番目に、設計原則に基づいて DDD を検討します。

DDD の実践自体は数千人規模になるかもしれませんが、いくつかのコアなトピックに焦点を当てて考える必要があり、これらの頻度の高いトピックを理解することでより良い設計が可能になり、ディスカッションの費用対効果も高くなります。次に、導入としての「6 つの主要な設計原則」(確固たる原則) に基づいて、DDD におけるいくつかの重要な理解を見ていきます。

4.1 単一責任の原則: ドメイン分割

単一責任では、クラスが変更する理由は 1 つだけである必要があります。単一の責任により、結束力が向上し、結合が減少し、進化が促進されます。

DDD におけるドメイン分割も同様に考えることができます。ドメインの分割では、ドメイン エンティティ、機能モジュール、サービスのいずれによって分割されるかに関係なく、実際にはドメインが可能な限り直交し、独立して進化および発展できるようにしたいと考えています。

単一責任の原則: 単一責任の原則

フィールドをどのように分割するのがより適切ですか? 初めてビジネス プラットフォームに入ったとき、ドメインの分割は「1 つ以上のエンティティ オブジェクト」の境界に基づいていることを知りました。ドメインの中核的な責任はドメイン エンティティを管理することであるため、これは実際にはより合理的です。しかし、これは結果なのでしょうか、それとも原因なのでしょうか？分割する場合、それはドメインに関する判断があるため、一部のエンティティを一緒にグループ化することがより適切であるためでしょうか、それとも一部のエンティティには明確な境界があるため、それらがドメインを形成できるためでしょうか? ちょうど下の写真のようになります。

• 全体としても部分としても使えます。

• 垂直方向のプラスとマイナスに応じて、上 1 (赤)、下 2 (黄、緑) の 2 つの部分に分けることができます。

• 横軸のプラスとマイナスに応じて、左側 1 つ（黄色）と右側 2 つ（赤と緑）の 2 つの部分に分けることができます。

• 3つの部分（赤、黄、緑）にカットできます。

クラスタリングの例

これはまさに思考の糧です。セグメント化が比較的簡単な場合は、多くの場合、業界標準がすでに存在しているためです (たとえば、電子商取引システムには注文、支払い、物流、在庫などのフィールドがある方が合理的です)。業界の標準はどこから来たのでしょうか? それは進化論から来ています：

• 最初は単なる大規模な取引である可能性があります。たとえば、支払いの開始時には、購入者と販売者の間の合意のみが行われ、モデリングは必要ありません。

• その後、決済が発達するとドメインが独立しました。これまでは専用のメンテナンスは必要なかったが、今後は徐々にチームを編成して関連する研究開発を行うことになる。

したがって、ドメインの進化と分割は、「ヒューリスティック アルゴリズム」 (許容可能なコストで解決できる組み合わせ最適化問題の各インスタンスに対して実行可能な解決策を与える、直感または経験に基づくアルゴリズム) に非常に似ています。

• 初期化:経験の予備的な分割に従って、業界標準にすることもできます (業界標準がない場合は経験のみに依存します)。

• コスト評価: コスト、開発効率、システムの安定性、運用保守コストの把握などの要素に焦点を当てて、生産および納品プロセスにおける人的コストを測定します。

• より良い解決策:事業開発の過程でコスト評価を計算し、評価に影響を与える「良い要因」と「悪い要因」を分析し、さらに調整します。

多くの場合、最終的には次のことがわかります。

• 調整の内容は、実は生産関係に合わせることです。

• 調整の原則:責任の一貫性を追求し、分業を洗練します。

• 継続的に調整を行う理由:ビジネスが進化するにつれて、結束基準も時代に合わせて対応する必要があります。

また、組合の観点から組織構造を見ると、分野の境界が見えてくることが多くありますが、その根本的な理由は、組織構造も生産関係に適応する必要があるからです。

4.2 オープンクローズの原則: エンティティの動作

オープンとクローズの原則は、ソフトウェア内のオブジェクト (クラス、モジュール、関数など) は拡張に対してはオープンであるが、変更に対してはクローズされる必要があることを意味します。つまり、拡張ブロックを設計する必要があり、拡張部分が安定性ロジックに影響を与えないようにする必要があります。

DDD では、エンティティの動作は、外部の世界に対して確実に閉鎖された状態で拡張する能力も考慮する必要があります。

オープン・クローズド原則：オープン・クローズド原則

私たちが最初に DDD を学習し始めたとき、制御と収束のためにエンティティに何らかのロジックを強制的に組み込むことがありました。しかし、後でビジネスが変化すると、エンティティ内で動作ロジックを想定することが難しくなることがわかります。

• より大きな影響:コアクラスを頻繁に変更する勇気を持つのは困難です。

• 集中化しすぎる:メソッドとロジックが増加するにつれて、エンティティはますます肥大化します。

• 多くのシナリオがあります。多くのロジックは直交しておらず、if や else とは異なり、交差と重ね合わせでいっぱいです。

POJO の get と set を放棄し、エンティティのリッチな動作に移行すると、コードを書くのがさらに難しくなりますか? 実際、私たちの問題は、エンティティの動作のクロージャーに過度に注意を払い、拡張機能の設計を無視したことに起因しています。

• オリジナルの get set 記述方法の本質は、多くの拡張機能がビジネス スクリプトに配置されていることです。ビジネス スクリプトには穴がたくさんありますが、それらはアプリケーション層にあり、コア ロジックからは離れています。基礎となるモデルや共通コンポーネントなどの基本ロジックは比較的きれいです。

• DDD を適用する場合、一部の動作をドメイン層に沈めた後、拡張も考慮する必要があります。拡張ではなく閉鎖だけに注目するなら、それはまさに「地面を刑務所として描く」ことであり、「種を拾ってスイカを失う」ことになる。

ただし、このジレンマを打破し、エンティティの動作の拡張を設計できるようにするには、実際には、エンティティの動作の表現であるレベルを参照する必要があるという認識を持たなければなりません。 1 つのクラスだけで完了します。戦略パターンやその他のメソッドを通じて実行できます。ルーティングは、外部のカプセル化と制御がある限り、モジュール内のいくつかのクラスによって実行されます。

1 つのクラスの制限を打破し、より多くのクラスの共同設計に移行することも、私たちの高度な方向性です。

4.3 リスコフ置換原理: リソース ライブラリ

リスコフ置換原則には、「基本クラスが出現できる場所には必ずサブクラスが出現しなければならない」というものがあります。重要なのは、合理的な抽象化と再利用です。考えさせられる例は次のとおりです: 正方形は特別な長方形です。正方形が長方形のサブクラスである場合、長さを設定するときに競合が発生します。長方形の長さと幅は独立して設定でき、長さと幅は独立して設定できます。はい、継承関係を使用するのは厄介です。

DDD では、代替可能性に関して、リソース ライブラリについて話したいと思います。

リスコフ置換原理: リスコフ置換原理

リポジトリの代替要件

元の階層化アーキテクチャでは、基盤となるインフラストラクチャとしてのデータベースなどのストレージ機能は、安定した基盤となるサービスとみなされます。ただし、実際の配信プロセスでは、さまざまなシナリオが頻繁に発生します。

• ローカル展開:オフライン小売取引では、サービスの安定性を確保するためにデータをローカルに保存する機能が期待されます。

• クラウド上の製品:外部企業に販売されるトレーディング製品にはさまざまなコスト要件があり、クラウド上のさまざまなストレージ サービスを購入することが予想されます。

これらのシナリオにより、より広範な市場に直面した場合、インフラストラクチャも不確実性が多く、交換する必要があると誰もが徐々に考えるようになりました。

ストレージ実装間の再利用戦略

実際の実装プロセスでは、すべてのフィールドが独立してデプロイされるわけではなく、組織およびパフォーマンスの要因により、いくつかのフィールドが一緒にデプロイされます。多くの場合、これらの領域のコードはプロジェクト モジュールにも含まれています。水平効率を考慮し、統一した保管体制を設計します。

施設が異なればストレージ機能も異なりますが、ストレージ プロセス全体 (プロトコル変換、ストレージ ステートメントの生成、実行とトランザクション、結果の返し) は似ているため、異なるストレージ機能のメソッドを再利用するプロセスでトレードオフを行う必要があります (データベース、Tair など。それは個別の抽象化ですか、それとも統一された抽象化ですか):

「大きな統合」が主な焦点である場合、リレーショナル ストレージと KV ストレージなどの異なるストレージを抽象化するときに、「長方形と正方形の問題」のように躊躇することになります。

• 利点:長期間保守し、内部の特殊性を理解していれば、実際に一部のメインコードを省略して開発効率を向上させることができます。

• コスト:しかし、多くの人が拡張しようとすると、多くの混乱を感じるでしょう。多くの不必要な適応があり、混乱に満ちています。

組み合わせに重点を置く場合は、複数のテンプレート セットを使用して、独立した選択をより適切に行うことができます。この種の分割統治により、全員が理解するコストが削減され、ストレージの機能と特性により適した独自の進化も可能になります。しかし、複数の理解の積み重ねが必要であり、人間のサポートが不足していることがよくあります。

「さまざまなストレージ機能に基づいて、さまざまなテンプレート フレームワークを設計する」ことが最初の選択肢であるべきだと思います。統一された抽象化は、最初は人件費が低いかもしれませんが、抽象度が高いため、理解と保守において「人的コストのブラックホール」となり、時間の経過とともに全体の収入が減少します。そして長期的には、それを失う価値はありません。逆に、異なるテンプレートを再利用して、最終的に全体的な利点を高めることもできます。

4.4 デメテルの法則: ドメインコラボレーション

デメテルの法則は、最小限の知識の原則としても知られており、ソフトウェア エンティティは他のエンティティとの対話をできるだけ少なくする必要があることを意味します。何らかの「キークラス」と通信する必要があります。

DDD では、ドメイン間のコラボレーションにも関連する計画と設計が必要です。ドメイン間の相互呼び出しを管理しないと、リンク関係が理解できないほど拡大してしまいます。

デメテルの法則: デメテルの法則

デザインパターンは、中間パターンでも出現パターンでも、一元管理することで複雑な多対多の関係を多対一のようなわかりやすい構造に単純化することが期待されています。そして一対多。同様に、ドメインのコラボレーションと外部配信のプロセスでは、さまざまなドメインの相互作用を接続するために調整レイヤーが追加されることがよくあります。これにより、各ドメインでのコラボレーションのコストが削減されるだけでなく、外部の理解のコストも削減され、より良い研究開発体験が得られます。

調整層はどのように生成すればよいでしょうか? それは授業に出席するのと似ています。教師は教えることができますが、教師がいないときは、授業に参加する生徒を指名できます。生徒たちはできるのですが、教える技術が熟達しておらず、生徒自身が学ぶ責任があり、非常に恥ずかしい役割でもあります。コーディネーション層とドメインの役割関係については後述する。

ドメインを調整層にできますか

議論する価値があるのは、トランザクションにおける「トランザクション ドメイン」と「オーダー ドメイン」の概念です。

• 「トランザクションドメイン」はトランザクションプロセス全体を担当し、さまざまなドメインを調整できるようです。論理的にはコーディネーターである方が適切ですが、主に注文の管理にあり、その他の調整機能が備わっています。ドメインエンティティがありません。

• 「注文ドメイン」は注文自体のサービスのみを担当し、他のドメインのことはあまり気にしていないように見えますが、注文契約にはすべての契約情報（直接的または間接的に保持されているかどうか）が含まれているため、次のことが意味されます。 「順序ドメイン」自体には調整の可能性がありますが、責任は十分に単一ではないようです。

エンティティがありません。なぜ「トランザクション ドメイン」があるのか​​、私は次のように理解しています。トランザクション プロセスを強力に制御する場合、トランザクションの API サービスはドメイン サービスと見なされます (注文の実行など)。 ）、「トランザクションドメイン」は論理的には境界があり、確立できます。しかし、本質は依然として注文を管理することであり、注文ドメインがドメインになることに依存しており、同時に調整能力を蓄積したいと考えています。

調整層はドメインになれるか

したがって、注文モデルの管理がトランザクション管理に与えられていない場合、これは私が常に考えている質問です。独自のデータベース エンティティがなく、メモリ モデルのみが存在し、純粋に下流ビジネスの理解に依存している場合は、アクティビティとデータフロー、それはドメインになれるでしょうか？

答えはおそらくノーです。

• 論理的には、個人は純粋に領域として理解することで認識しますが、結局のところ、知識自体も資産です。

• しかし実際には、通信事業者がなければステータス記録やデータサービスなど多くのことができず、支援することしかできず、核となる競争力がなければ生き残ることは困難です。

コーディネーターの役割は、比較的認知された「ドメイン」になるために、データ モデルを単独で保持するか、基本ドメインのいくつかのデータ モデルを使用し、管理権限を享受する必要があります。

調整レイヤーの名前

ドメインがコーディネーターの役割を引き受けたいのか、コーディネーターがドメインに発展したいのか、単一責任の論理には当てはまりませんが、そのような「兼業」は頻繁に発生し、核となるのは開発者の重複です役割。

調整層はドメインから選択するのに適しておらず、ドメインにも適さないので、各ドメインの事業活動と能力の間の調整部分を何と呼ぶべきでしょうか。現状では「商力」や「ソリューション」といった言葉の方が適切だろう。

4.5 インターフェース分離原則: ビジネス活動

インターフェイス分離の原則では、クライアントは必要のないインターフェイスに依存すべきではありません。クラスの別のクラスへの依存関係は、最小のインターフェイスに基づく必要があります。

DDD でのドメイン構築を学ぶことに加えて、アプリケーション層がビジネス リクエストをより適切に処理する方法にも注意を払い、ビジネス ロジックのセグメント化の基礎を学ぶ必要があります。

インターフェイス分離の原則: インターフェイス分離の原則

ルールがないと立ち回るのが難しい

以前、事業部門で業務を行っていたときは、業務活動やプロセスといった概念がなく、業務ニーズに基づいて業務スクリプトを書くことが多く、経験値がコードの洗練さに影響を与えていました。しかし、経験は別として、アプリケーション層のさまざまなビジネス ロジックを実行するためのより優れた構造フレームワークや原則を誰もが持っていないため、疑問もいっぱいです。

• 外部サービスインターフェースはどのようにセグメント化すべきでしょうか?

• 同様のサービス間でプロセスを共有できますか?

• 業務執行プロセスをさらに構造化し、細分化するにはどうすればよいでしょうか?

• ……

標準化が行われない結果として、誰もが独自の意見を持つことがよくあります。誰もが一連の構造を確立したいと考えていますが、誰も他の構造に同意しません。それぞれが独自のコード領域を持っています。

安定したプラットフォームのフレームワーク

このプラットフォームは長い間考え、管理されており、比較的安定したコンセンサスがあるため、現在機能しています。ビジネスの入り口とビジネスの入り口の間、ビジネスの入り口と安定したロジックの間の全体的な設計は、シナリオベースのロジックを実行するためのスペースと拡張機能を確保しており、その構造は比較的明確です。

• 事業活動に応じて入口が細分化され、事業活動に応じてサービス入口が拡張され、コアはユースケースを理解し、どの役割が何をする必要があるのか​​に注目します。

• プロセスに依存しない取り組みとオーケストレーション:ビジネス アクティビティは、多重化レイヤー (ドメイン サービス、外部サービス、ビジネス拡張など) に到達する前に、独立したままであり、オーケストレーションされます。

• プロセス ファイルを使用して実行プロセスを調整します。実行プロセスを実行ノードにセグメント化します。ノードのセグメント化は、「ファンクション ポイント」、「関与するドメイン」、「関与するエンティティ」などに基づいて行うことができます。ノード間の共通機能は、基本機能に組み込まれます。

• ……

繰り返しのレビューで合意形成

分割して征服し、全員の焦点を絞り、分割して協力することを改善します。これは非常に理解しやすく、受け入れやすいものです。ただし、適切な分割を確保するには、統一された合意と原則が必要です。

多くの場合、合意形成は、先に合意をしてから分割するのではなく、最初のコミュニケーションを経て分割を試み、レビューで合意に達し、紆余曲折の中で前進することが多いです。全員の意見や対立が比較的大きい場合、合意に達するプロセスは比較的遅くなります。幸いなことに、この種のセグメント化は頻繁に発生するものではなく、大きな需要や大規模なリファクタリングが発生する場合にも発生します。現時点では、確保されている研究時間と開発リソースも十分です。

4.6 依存性反転の原理: ヘキサゴナル アーキテクチャ

依存関係逆転の原則は、プログラムは具体的な実装ではなく、抽象インターフェイスに依存する必要があるということです。

DDD で言及されているヘキサゴナル アーキテクチャは、ドメイン構築をアーキテクチャの中核目標として、抽象コアのステータスをさらに強化します。

依存関係逆転の原理: 依存関係逆転の原理

フィールドを中心とすることは、実際には比較的重要な変更です。

• 以前は階層化されたアーキテクチャに基づいていました。ビューのレベルに注意を払い、機能を下げ、より多くのツールを再利用し、共通のコンポーネントを蓄積するように努めました。

• 次に、その分野に焦点を当てます。抽象化のレベルに注目し、理解をその分野の核心に統合し、より多くの「理解」再利用を実行して、ビジネス知識を蓄積します。

このような変化により、私たちは意識的に「ドメイン理解」を核として、業界競争力を形成し、「知識」を資産として販売することが可能になります。

ドメイン カーネルの抽象化を確実にするためには、ドメイン カーネルの境界を定義する必要があります。インターフェイスには次の 2 種類があります。

• アップストリームに提供される機能:インターフェイス宣言を通じて、引き受けることができる責任を説明し、ドメイン内でサポートを実装します。

• ダウンストリーム機能への依存:外部サービス、ビジネス拡張機能のカスタマイズ、およびストレージ サービスはすべてダウンストリーム サービスと見なすことができ、サービスの依存関係はインターフェイスを通じて宣言されます。

ドメイン コアと外部の間のインターフェイスが分離されていることがわかります。より基本的なサービスについては、アプリケーション層に属するビジネス入口と同じ外部ポートとみなされます。たとえば、ストレージ サービスは次のとおりです。

• データ フレーム + DO、変換を理解する必要がなく、変換は上流で完了し、DO は上流でもコア モデルとして使用されます。アップストリームは循環のコアオブジェクトとして DO を完全に使用します。

• これで、これは「ビジネス コンポーネント」として理解できるようになります。ドメインのストレージ インターフェイスを実装し、プロトコル変換を実行し、ドメイン オブジェクトをデータ ストレージ オブジェクト DO に変換する必要があります。DO はドメインによって直接理解されませんが、カーネルはドメイン オブジェクトに変換してから外部に公開する必要があり、カーネルによってパフォーマンスが定義されます。

この種のアーキテクチャは、ドメイン理解の抽象的な中心的な位置を確立し、研究開発の学生がビジネス上の問題について考えることにもっと注意を払うことを可能にし、単なる「ビジネス上の問題に近い」より多くの「血肉」のソフトウェアを構築します。ソフトウェアの複雑さに対処するプロセスでは、顧客の価値に近づくという方向性がより認識されています。

V. まとめ

DDD の追求は、さまざまなビジネス上の問題をエレガントに解決したいという願望から来ており、一連のフレームワークが問題を分解し、安定した効率的な生産効率を得るのに役立つことを期待しています。

しかしそれは「永久機関」の探求と同じで、明確な答えを出すことが難しい過程です。ソフトウェアの複雑さを解決するソリューションは、関連するシナリオと組み合わせて継続的に進化する必要があり、単に DDD を追求するだけでは「特効薬」は得られません。

しかし、「永久機関」の研究と同じように、エネルギーの変換プロセスに焦点を当てることができ、より効率的なエネルギー機械の作成につながる可能性があります。DDD の研究と追求により、ビジネスの深い理解にもっと注意を払うことができ、拡張しやすいコード実装を作成できるようになります。

「事業の継続的な発展」と「ソフトウェアの複雑さ」があるからこそ、プログラミングは課題に満ち、フレームワークの研究に熱中できるのだと思いますが、これは素晴らしいことではないでしょうか。