Clever Geek Handbook

ドメイン駆動設計：戦略的設計。 パート1





こんにちは、Habraユーザーの皆さん！ この記事では、主に戦略的なテンプレートを使用したソフトウェアの主題指向の設計に焦点を当てます。 第二部-戦術設計について- ここをお読みください 。



このアプローチは、Vaughn Vernonの著書「主題指向設計の方法の実装」で使用されていました。 この本の目的は、開発者がDDD飛行機で飛行できるようにすることです（子供の頃、著者は家族と一緒に小さな飛行機で旅行することがよくありました）。 上からの眺めは、さまざまな技術的詳細にこだわることなく、モデリング問題のより広い概念を提供します。 このようにDDDの状況を観察することにより、戦略的設計と技術的設計の両方の利点を実現できます。 詳細-カットの下で！



フライトは、



、



、



、



、



、



などの戦略的モデリングのツールとテンプレートを使用して実行され



。 この記事で説明するのは、それらについてです。



たとえば、



、



、



、



、



、



などの戦術的なパターンを使用した設計は、軽量のDDDです。 このアプローチを使用できることは非常に重要ですが、これらのテンプレートは主に技術的な性質のものであり、DDDの全体像を見るためには、まず戦略的テンプレートを実際に適用する方法を学ぶ必要があります。



DDDアプリケーションの主な目的は、ビジネス目標を最も正確に反映する高品質のソフトウェアモデルを取得することです。 これを実現するには、開発者と主題の専門家の両方の努力の組み合わせが必要です。 友好的で緊密なチームを作成すると、ビジネス上の多くのメリットを得ることができます。 チームメンバー間の知識の交換により、モデルに関する「秘密の知識」が出現する可能性が減り、さまざまな概念や用語に関してドメインエキスパート間で合意に達し、ビジネスのより正確な定義と説明が作成されています。



サブジェクトエリアの開発者と専門家のバランスを取り、サブジェクトエリアに関する有用な知識を交換しやすくするために、DDDアプローチでは、チームメンバー間のコミュニケーションで使用される用語、概念、およびフレーズの共通セットを使用することを提案します。プログラム。



単一言語



この集合的な用語の言語は、



（ユビキタス言語）と呼ばれます。 これは、主題指向設計の主要かつ最も重要なパターンの1つです。 これは、開発者に課されるビジネス用語ではなく、主題の専門家、開発者、ビジネスアナリスト、およびシステムの作成に関わるすべての人、つまり全体的なチームによって作成された実際の言語です。 チームの各メンバーはプロジェクトを説明するために



を使用するため、チームの役割はそれほど重要ではありません。 単一の言語を作成するプロセスは、他の自然言語と同様に絶えず進化しており、有用な単一言語の開発に最初に貢献したこれらのアーティファクトは時間が経つにつれて古くなるため、形式よりも創造的です。 その結果、最も安定で実績のある要素のみが残ります。 実験から正確な知識に移行するには、Vaughn Vernonの本で次の方法を使用することを提案しています。



  1. 物理的および概念的な主題領域の図を作成し、名前とアクションを示すラベルをそれらに適用します。 このような図は本質的に非公式であるため、フォーマルモデリング（UMLなど）を使用する意味はありません。
  2. 簡単な定義と、見込み客の評価を伴う代替用語を含む用語集を作成します。 したがって、単一言語の安定したフレーズが開発されます。
  3. 用語集の代わりにドキュメントを作成します。 このドキュメントには、ソフトウェアに関連する略式の図または重要な概念が含まれます。
  4. 用語集やその他の文書をすぐに学べない他のチームメンバーと既成のフレーズについて話し合う。


コードはかなり迅速に開発され、単一の言語の現在のバージョンと調整する必要があるため、後で図、用語集、またはその他のドキュメントを放棄できます。



開発者にとって最も重要なことは、専門家の意見を聞き、対象分野に関する最大限の有用な知識を得る能力です。 同時に、専門家は開発者と彼らの希望にも耳を傾けるべきです。 チームは、連携して事業の理解を深めれば、共に学び、成長します。



本からいくつかの例を挙げます。



チームとして、コードの形でインフルエンザワクチンを使用するモデルを議論し、「看護師はインフルエンザワクチンを標準用量で処方します」のようなフレーズを言います。 可能なシナリオ：







明らかに、最初のオプションはまったく最適ではなく、2番目のオプションは優れていますが、いくつかの重要な概念を考慮していません。 最終バージョンは、タスクに最も適しています。



サブジェクト領域のフレームワーク内では、特定の用語またはフレーズの意味が非常に異なる場合があることを理解することが非常に重要です。 概念の範囲内に一定の境界があります

単一の言語には、非常に具体的な文脈上の意味があります。



限られたコンテキスト



この概念的な境界は、境界付きコンテキストと呼ばれます。 これは、単一の言語に次いで2番目に重要なDDDプロパティです。 これらの概念は両方とも相互に接続されており、互いに存在し合うことはできません。



したがって、



は、



をソフトウェアモデルにマッピングするドメインモデルが存在する明確な境界です。





たとえば、銀行サービスの文脈と文学の文脈における「アカウント」という用語の対比を考えてみましょう。



銀行のコンテキスト



概要には、銀行の観点からのクライアントの現在の財務状況を反映した売掛金および買掛金取引の記録が保持されます→ 経常収支または貯蓄口座の要約



文学的な文脈



概要とは、一定期間に発生した1つ以上のイベントに関する文学表現の集合です→ Into Thin Air：A.の個人アカウントは、amazon.comで販売されています。 エベレスト災害



サマリーのタイプを名前で区別することはできません。 しかし、それらは概念的なコンテナの名前、すなわち 関連する限られたコンテキスト。



これらの制限されたコンテキストは、異なる



関連してい



。 次の例では、同じ



内で同じ名前が使用されています。



本の出版社の中には、ライフサイクルのさまざまな段階を経ているものもあります。つまり、本はさまざまな



を経ています。





この場合、適切なブックモデルを開発する方法はありません。 たとえば、契約が締結されるまで、書籍のタイトルは未定義のままであり、編集プロセス中に変更される場合があります。 マーケティングには、表紙と注釈を除き、文学および技術版のほとんどのアーティファクトは必要ありません。本の販売には、名前、倉庫の場所、コピー数、サイズ、重量のみが必要です。 混乱を避けるため、DDDアプローチでは、ライフサイクルの各段階で個別の



を使用する必要があります。 各



のブックモデルは、他のすべてのモデルとは大きく異なります。 特定の



各チームは本について語り、彼らが



に何を望んでいるかを正確に知ってい



。



上記の例では、同じ



内でさまざまな



使用して



ます。



サブジェクトドメイン、サブドメイン、セマンティックコア







は、組織が行うことと、それが行う環境です。 組織のソフトウェア開発者は、



作業する必要があります。 ドメインモデルを開発する場合、ある程度複雑な組織であっても、単一の包括的なビジネスモデルを作成することはほとんど不可能なので、特定の



に集中する必要があることを理解しておく必要があります。 モデルを実際の機能に従って、



全体の論理的に分割された



（サブドメイン）に分割することは非常に重要です。



使用すると、特定の問題を解決するために必要な



さまざまな部分をすばやく判断できます。



また、



（コアドメイン）を決定できる必要があります。 これは、DDDアプローチの非常に重要な側面です。



は、組織にとって最も重要な



です。 戦略的な観点から、ビジネスは



際立っている必要があります。 ほとんどのDDDプロジェクトは



焦点を当てています。 最高の開発者と専門家がこの特定の領域に関与する必要があります。 ビジネス上の利益を達成し、利益を最大化するために、ほとんどの投資をここに向ける必要があります。







ではなく重要なビジネスの特定の側面がシミュレートされる場合



サポートサブドメインを指します。 ビジネスには専門性があるため、



が作成されます。 ビジネスに特別な目的はないが、ビジネス全体に必要な場合は、



（汎用サブドメイン）と呼ばれます。 これらのタイプの



はビジネスの成功にとって重要ですが、主な重要性はありません。 これは、ビジネスに利点をもたらすため、理想的に実現さ



べき



。



これは、DDDアプローチによる戦略的設計の基礎です。



タスクスペースとソリューションスペース







は、タスクスペースとソリューションスペース



構成されます。 タスクスペースでは、解決する必要がある戦略的なビジネス上の問題について考えることができ、ソリューションスペースでは、ビジネス上の問題を解決するためのソフトウェアの実装方法に焦点を当てます。





理想的なオプションは、



と



間で1対1の対応を提供することです。 したがって、タスク空間とソリューション空間が組み合わされ、ドメインモデルは、設定された目標に応じて、明確に定義された領域に区別されます。 システムがゼロから設計されていない場合、多くの場合、



が



と交差する



。



一例として、Vaughn Vernonの本は、小規模なオンライン小売会社のコアコアを提供します。 オンラインストアは、販売履歴と在庫データを分析する予測メカニズムを使用して、需要の予測と最適な在庫の特定の量を取得する場合、その位置を改善できます。 （企業は、需要のない商品にお金を費やして追加のストレージスペースを占有するべきではありません。）この



により、組織の競争力が大幅に向上し、収益性の高い取引を迅速に識別し、必要な在庫レベルを保証できます。 タスクスペースは、調達と在庫に関連する



と



構成され、次の図に表示されます。



これは



一部にすぎず、組織が運営する



全体ではありません。 タスク（セマンティックコアとサブドメイン）のスペースを分析する必要があります。 図に示す調達モデルは、



ソリューションです。 ドメインモデルは、明示的に



たコンテキスト（最適な調達のコンテキスト）で実装さ



。 この



は、最適調達のセマンティックコアと呼ばれる1つの



明らかに対応しています。 調達プロセスの技術的側面を明確にするために、調達コンテキストと呼ばれる別の



が開発され、最適な調達コンテキストに関連して補助的な役割を果たします。 これらは、ERPシステムのオープンインターフェイスとの相互運用性を提供します。 調達コンテキストとERP調達モジュールは、調達サービスサブエリアに結合されます。 ERPモジュール自体は、他の商用調達システムに置き換えることができるため、



てい



です。 ただし、調達サブリージョンの調達コンテキストと組み合わせて表示すると、



になります。 図に示すように、最適な調達コンテキストは、ストレージユニットを管理するインベントリコンテキストとも相互作用する必要があります。 在庫の



内にあるERP在庫モジュールを使用します。 ERPアプリケーションはさまざまなモジュールで構成されており、論理的な



と見なされます-これらは在庫と購入の



。 これらのモジュールと在庫および調達コンテキストは、



結合され



。



したがって、タスクスペースを評価するには、まず、次のことが必要です。





タスクスペースの評価は、ソリューションスペースの評価に影響します。 ここでは、既存および新しいシステムとテクノロジーについてすでに考える必要があります。 私たちは、



が求められている明確に分離可能な物理的



観点から考えなければなりません。 次のとおりです。









は、



モデルだけで構成されているわけではありません。 モデルはその主要コンポーネントですが。 モデルからデータベーススキーマを作成すると、この



も参加し



。 同時に、スキームが以前に存在し、そのプロジェクトでプロジェクトが違反された場合、このスキームは



は適用されません。



また、モデルを表現



は、



指し



。 境界内にもあるサービス指向のエンドポイントも実装できます。 ユーザーインターフェイスコンポーネントとサービス指向のエンドポイントの両方が



に委任され



は、モデルに関連して



として機能します。 また、これらの



、



境界内にあり



。







のサイズは非常に異なる



があります。 主なことは、モデルが



内の



豊かさを実証することです。



内でモデリングするために必要なだけの



概念を持っている必要があり



-多かれ少なかれ。 重要なものを見逃さないために、明確で良い基準を見つける必要があります。 これに



を使用できます。 したがって、3番目の重要な戦略的設計テンプレートになります。



コンテキストマップ



DDDアプローチに従って、特定のチームは独自の



作成する必要があります。



、このチームが配置されている決定スペースを反映しています。 この



は、



、それらの間の統合リンクで構成されています。 例：



このコンテキストマップには、将来の出来事ではなく、現在の状況が表示されます。



作成プロセス中は、形式的な手続きは避けてください。 詳細が多すぎると、作成プロセスが妨げられるだけです。



イベントの自然な経過は、コンテキストの境界がチームの組織部門と一致することです。一緒に働く人々は、共通のモデルコンテキストを共有します。



予備を作成した後



、の関係を決定することで詳細にすることができます



。プロジェクトチームと個々のプロジェクトチームの



間には、次のような関係が



あります。





開発の例は、 Alberto Brandolini Strategic Domain Driven Design with Context Mappingの記事



から取得できます。最初に、境界と次の関係を使用して、単純なコンテキストマップを描画します。















これら2つのコンテキストでは、同じ名前の概念に違いがあります。たとえば、Webユーザープロファイリングのアカウントはユーザーアカウント（ユーザー名とパスワード）です。同時に、PFM Application（個人財務管理）の場合、銀行の観点からクライアントの現在の状態を説明する要約です。前述のように、まったく同じ概念をまったく異なる概念で使用



できる場合があるため、それらに対して異なるモデルを定義する必要があります。









たとえば、PayeeAccountは同じBankingAccountですが、動作が異なります（残高を取得できません）。このようにして、別個の経費追跡コンテキストが作成されます。また、上記の例では、別に、オンラインバンキングサービスのコンテキストが作成されます（このようなサービスは、銀行取引明細書の印刷など）。









作成の最初のステップの後、



すべての関係を詳述できます。各関係には方向があります。親（アップストリーム）はダウンストリーム（ダウンストリーム）に影響しますが、その逆は当てはまりません。



詳細



は次のようになります。









オンラインバンキングサービスのコンテキストは、APIによって提供されます（オープンプロトコルサービスおよび公用語にすることができます）。このAPIを変更するとき、新しいAPIを使用するには、個人の財務管理のコンテキストをすぐに変更する必要があります。同時に、



オンラインサービスのコンテキストの概念が個人の財務管理のコンテキストに漏れないようにするために使用する必要があります（ドメインモデルの変換が行われます）。



Webユーザープロファイルのコンテキストは既成の外部モジュールとして使用され、「そのまま」提供される



ため、ここで関係が確立されます（上位の下位の下位）。



原価計算のコンテキストの場合、比率はここで最適です。



、共通の目標と概念がありますが、態度の方向性がないためです。



これは簡単な例です



が、実際にはもっと複雑です。



おわりに



この記事では、戦略的なパターンによるオブジェクト指向設計の基本概念を議論しました：



、



、



、



、



、



。これらのツールは、プロジェクトの戦略的発展を把握し、最大の成功を達成するためにビジネスをさらに発展させる方法を理解するのに十分です。



もちろん、この記事を読んだ後、私はまだ多くを明らかにしたいと思うでしょう。これについては、前述のVaughn Vernonの本を参照することをお勧めします。このための特別なコミュニティもあり、アドバイスを求めることができます。戦術同じモデリング技法ならびにパターン、など



、



、



そして他のものは次の記事に説明します。



ご清聴ありがとうございました！



作成者：greebn9k（セルゲイグリブニャック）、wa1one（ウラジミールコヴァルチュク）、silmarilion（アンドレイカハレフ）。


More articles:


All Articles