PHP の DDD について話しましょう

DDD は「Domain Driven Design」の略称で、中国語ではドメイン駆動設計と訳されることが多いです。今回はphpにおけるDDDについて紹介しますので、必要に応じて参考にしてください。

#DDD とは (まず、何ではないのか)

DDD は Domain Driven Design の略称で、ドメインと訳されることが多いです。 -中国語によるデザイン主導。 DDD とは何かを理解する前に、まず DDD が何ではないのかについて説明しましょう。

• DDD はソフトウェア フレームワークではありません。ただし、DDD の考え方に基づいたフレームワークは存在します。Axon は、DDD を指導的な考え方として Java に実装されたマイクロサービス ソフトウェア フレームワークです。

• DDD はソフトウェア設計パターンではありません。ファクトリやシングルトンのようなデザインパターンではありません。しかし、DDD思考ではリポジトリのようなデザインパターンが提案されています。

• DDD はシステム アーキテクチャ パターンではありません。 MVC のようなアーキテクチャ パターンではありません。ただし、DDD のアイデアでは、イベント ソーシング (イベント ソーシング) や読み書き分離 (コマンド クエリ責任分離) などのアーキテクチャ パターンが提案されています。

それでは DDD とは何ですか?

ソフトウェアは人間に奉仕し、人間の生産性を向上させるために作成されたツールです。各ソフトウェアは特定の目的を果たします。たとえば、CRM は顧客データの管理に重点を置き、販売者が顧客と連絡を取り合うのに役立つツールです。

ソフトウェアの本質は、コンピュータ内で実行されるコードです。抽象的なコードを人間が関心のある分野により正確にマッピングする方法は、関数型プログラミング (FP) かどうかにかかわらず、ソフトウェア開発者が模索してきたテーマです。またはオブジェクト指向プログラミング (OOP) は、どちらも開発者が現場に近いソフトウェア モデルを開発できるように設計されています。

従来のソフトウェア開発方法では、ソフトウェアの品質に影響を与える一連の技術的および非技術的な問題に遭遇することがよくあります。

• 開発者はテクノロジーに熱心ですが、技術が不足しています。デザインとビジネス思考。開発者はビジネスニーズを十分に理解せずに密室で作業しており、機能を立ち上げても誰も関心を持ちません。

• ビジネス入力ではなくコード入力。技術者はテクノロジーの実装に特別な関心を持っており、鶏を殺すために雄牛のナイフを使用する必要がない状況があります。

• データベースに過度に注意を払いすぎます。ビジネスではなくデータベース設計を中心とした開発では、ソフトウェアが刻々と変化するビジネス ロジックに適応できないことがよくあります。

DDD は、ドメイン (ビジネス) を出発点として、ソフトウェア モデリングの複雑さを解決することを目的とした設計思想であり、モデリング方法論としても理解できます。

DDD の設計哲学は、戦略的と戦術的な 2 つの部分に分かれています。

戦略設計はマクロレベルの設計として理解でき、その目的には、事業の複雑さの分析、事業領域の分割、事業統合方法の指針などが含まれます。戦術的な設計は、ビジネス ロジックを実装するための一連のツールを提供するマイクロ レベル (コード レベル) の設計として理解できます。

戦略的デザイン

ユニバーサル言語 (ユビキタス言語)

言語は人間のコミュニケーションのための基本的なツールですが、開発者は専門用語やドメインの専門家 (ドメインの専門家) を使用することに慣れています。一般に、専門用語を気にせず、ビジネスに精通した専門家を指しますが、そのため、必然的にコミュニケーション問題が発生します。一度コミュニケーション問題が発生すると、開発されたソフトウェアでは実際の問題を解決することが困難になります。ドメイン専門家の問題点。

ユニバーサル言語は DDD 思考の基礎です。開発者とドメインの専門家が共同で作成するコミュニケーション言語です。チーム内で人気があり、チーム メンバーが普遍的に使用できる共通のコミュニケーション言語です。言語バリアフリーコミュニケーションのために。

これには、開発者が技術的な色彩の強い専門用語を放棄し、ドメインの専門家と協力し、ドメインの専門家と同様にビジネス上の問題に焦点を当て、ビジネス上の用語を共同で掘り下げて磨き上げ、共通言語を作成する必要があります。

汎用言語はコードに直接適用できることが多く、クラスまたはクラスのメソッドとして直接記述することができます。

たとえば、ショッピング カートを開発する場合は、専門用語を使用する代わりに次のようにします。

• ##Cart::create(): ショッピング カートを作成します。

• Cart::updateStatus(): ショッピング カートのステータスを更新します。

• Cart::remove(): ショッピング カートを削除します。

ビジネスに近い共通言語を使用することもできます:

• Cart::init(): ショッピング カートを作成する。

• Cart::addItemToCart(): アイテムを追加します。

• Cart::removeItemFromCart(): アイテムを削除します。

• Cart::empty(): ショッピング カートをクリアします。

後者を使用する場合、開発者は各クラス メソッドの意味を説明する必要がなく、ドメインの専門家は各クラス メソッドの目的を直接理解できます。開発者は、ドメインの専門家と話し合い、コードを操作してビジネス プロセスを磨き上げることもできます。

境界付きコンテキスト

ユニバーサル言語の自由を実現した後は、境界付きコンテキストを使用して、ユニバーサル言語の各セットの使用境界を定義する必要があります。境界のあるコンテキストは、セマンティクスとコンテキストの間の境界です。その中の各要素は、独自の特定の意味を持ちます。つまり、各概念は、境界のあるコンテキスト内で一意であり、多義性は許可されません。

簡単な例を使用して、境界付きコンテキストを説明します。たとえば、ショッピング カートの限定されたコンテキストでは、製品を購入した顧客を表すために「ユーザー」という単語を使用できます。登録システムでは、ユーザー名とパスワードを持つアカウントを指すために「ユーザー」という単語を使用できます。単語は同じですが、境界が異なるコンテキストでは異なる意味を持ちます。

私たちは、限定されたコンテキストと普遍的な言語を使用して、言語レベルでビジネスを分割します。境界付きコンテキストにより、ドメイン内の各要素に明確な概念が与えられるため、開発者は 1 つの要素をサポートする複数の概念を頭の中でフラッシュしたり、「大きな泥の塊」のようなコードを作成したりする必要がなくなります。

サブドメイン

境界付きコンテキストが言語レベルでビジネスを分割する場合、サブドメインはビジネスのビジネス価値を分割します。すべてのビジネスには独自の焦点があります。同じ電子商取引プラットフォームに見えても、タオバオはオープン プラットフォーム モデルであり、京東はバリュー チェーン統合モデルです。明らかな違いの 1 つは、タオバオがサードパーティの物流を使用しているのに対し、京東はサードパーティの物流を使用していることです。 comでは独自の物流システムを構築しております。

では、開発者として、なぜ自分に関係がないと思われるビジネス モデルを気にする必要があるのでしょうか?逆に、ビジネスの構造を理解して初めて、ビジネスの迅速な発展をサポートする明確な優先順位を備えたシステムを開発することができます。

サブドメインは、優先順位を付けるのに役立つツールです。

サブドメインには 3 つのタイプがあります:

• コア ドメイン: これはシステム内で最も大きな投資が必要な領域であり、システム全体の中核となる競争を表します。ビジネスの力。企業の存続に関わるコア領域を磨くには多くのリソースとリソースを費やす必要があります。たとえば、JD.com が自社構築した物流システムです。

• サポート ドメイン (サポート ドメイン): このドメインは企業のコア ビジネスではありませんが、コア ドメインと切り離せないものであり、アウトソーシングのカスタマイズ ソリューションを使用して実装できます。たとえば、認証コンテキストや許可コンテキストなどです。

• 汎用ドメイン (汎用ドメイン): 完成したソリューションがある場合、汎用ドメインは既製のソリューションを購入できます。そうでない場合は、アウトソーシングを利用することもできます。一般ドメインは最小である必要があります。たとえば、タオバオの場合、物流はその一般的な領域です。

境界コンテキストとサブドメインの関係についてはさまざまな意見があり、1:1 を主張する専門家もいれば、1:N を主張する専門家もいます。私は個人的に 1:1 を支持しています。なぜなら、「Implementing Domain-Driven Design」という本の著者に深い影響を受けているからです。

コンテキスト マッピング

巨大なシステムでは、境界のあるコンテキスト間に特定の依存関係が存在する必要があります。あるコンテキストから別のコンテキストに概念をどのようにマッピングしますか?コンテキストマッピングを使用します。

次に、コンテキスト マッピングのいくつかの関係タイプを示します:

• パートナーシップ

• 共有カーネル)

• 顧客とサプライヤーの開発

• 適合主義者

• 汚職防止レイヤー

• 開くホスト サービス

• ##公開言語

#SeparateWay

• ##大きな泥の玉

• 上記は比較的抽象的な概念であり、場合によっては、2 つの境界のあるコンテキスト間に複数の関係が存在する可能性があります。

上記は、DDD 戦略設計のいくつかの中心的な概念です。

戦術デザイン

制限されたコンテキストで概念をモデル化する方法には、DDD が提供する戦術デザインを使用します。

エンティティ

まず最初に、エンティティについて説明します。

エンティティはドメイン内の独立したもののモデルであり、各エンティティには ID、UUID、ユーザー名などの一意の識別子があります。ほとんどの場合、エンティティは変更可能であり、その状態は時間の経過とともに変化しますが、エンティティは必ずしも変更可能である必要はありません。

エンティティの最大の特徴は、その個性と独自性です。たとえば、単純なショッピング カートのコンテキストでは、注文はエンティティであり、ID はその識別子であり、そのステータスは発注、確認、返金の間で変化する可能性があります。

Value オブジェクト (Value オブジェクト)

Value オブジェクトは、フィールド内のエンティティを記述、定量化、または測定するために使用されるモデルです。エンティティとは異なり、値オブジェクトには一意の識別子はなく、2 つの同等の値オブジェクトは交換可能です。値オブジェクトには不変性があり、一度作成されると、値オブジェクトのプロパティは確定され、変更できません。

価値対象を理解する最も直接的な方法は、現実の紙幣を想像することです。日常生活では、A の人民元の 10 元と B の人民元の 10 元は等価に交換できます。

上記のショッピング カートのコンテキストでは、金額 (Money) は値オブジェクトであり、金額は通貨 (通貨) と金額 (金額) で構成されます。

class Money {
  public $currency;
  public $amount;

  function __construct($currency, $amount) {
    $this->currency = $currency;
    $this->amount = $amount;
  }  
}

値オブジェクトをモデリングに使用すると役に立ちます。コードを使用してドメインをより正確にモデル化します。

集計

集計とは何ですか?集約は、コンテキストに応じたビジネス領域のより詳細な分割であり、各集約により独自のビジネスの一貫性が保証されます。

それでは、ビジネスの不変性とは何でしょうか?ビジネスの不変性は、ビジネス ドメイン内で違反できないビジネス ルールを表し、その一貫性が保証される必要があります。たとえば、注文を返金する場合、返金額は支払った金額を超えることはできません。

集計のコンポーネントはエンティティと値オブジェクトであり、エンティティのみの場合もあります。アグリゲートのビジネスの一貫性を保護するために、各アグリゲートは、アグリゲート ルートと呼ばれる特定のエンティティを通じてのみ操作できます。

ドメイン イベント

ドメイン イベントは、共通言語を通じて分析されるイベントです。一般的なトランザクション イベントとは異なり、ビジネスと密接に関連しているため、その名前にはビジネス名詞が含まれることがよくあります。データベースにリンクされています。たとえば、ショッピング カートに製品を追加する場合、対応するドメイン イベントは CartUpdated ではなく ProductAddedToCart である必要があります。

概要

DDD は、アプリケーション サービス (Application Service) やドメイン サービス (Domain Service) などの戦術的な設計も提供しており、記事の冒頭で述べたイベント ソーシングも提案しています。ここでは一つ一つ紹介しません。

DDD の核心は、ビジネスの観点からソフトウェアのモデルを構築することであり、よりビジネスに近いコードを作成し、コードからより直感的に業務プロセスを明らかにすることを目的としています。ただし、DDD の実現は一日にして成らず、継続的な練習と継続的な磨きが必要です。

推奨学習: php ビデオ チュートリアル

以上がPHP の DDD について話しましょうの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。