ドメイン駆動設計(DDD)は主要なソフトウェア設計手法であり、[1]その分野の専門家からの入力に基づいてソフトウェアをその分野に適合するようにモデリングすることに重点を置いています。 [2] DDDは単一の統一されたモデルを持つという考え方に反し、代わりに大規模なシステムを境界付けられたコンテキストに分割し、それぞれに独自のモデルを持たせます。[3] [4]
ドメイン駆動設計では、ソフトウェア コードの構造と言語 (クラス名、クラス メソッド、クラス変数) はビジネス ドメインと一致する必要があります。たとえば、ソフトウェアがローン申請を処理する場合、「ローン申請」、「顧客」などのクラスと、「オファーの承諾」や「撤回」などのメソッドが含まれる可能性があります。
ドメイン駆動設計は、次の目標を前提としています。
- プロジェクトの主な焦点をコアドメインとドメイン ロジック層に置く。
- ドメインのモデルに基づいて複雑な設計を行う。
- 技術専門家とドメイン専門家の間で創造的なコラボレーションを開始し、特定のドメインの問題に対処する概念モデルを反復的に改良します。
ドメイン駆動設計の批評家は、モデルを純粋で有用な構造として維持するために、開発者は通常、かなりの分離とカプセル化を実装する必要があると主張しています。ドメイン駆動設計は保守性などの利点を提供しますが、Microsoft は、モデルがドメインの共通理解を形成する上で明確な利点を提供する複雑なドメインに対してのみ、これを推奨しています。[5]
この用語は、2003年に出版されたエリック・エヴァンスの同名の本の中で造られたものである。[6]
概要
ドメイン駆動設計は、いくつかの高レベルの概念と実践を明確に表現します。[6]
最も重要なのは、ソフトウェアのドメイン、つまりユーザーがプログラムを適用する対象領域です。ソフトウェア開発者は、ドメイン モデルを構築します。ドメイン モデルは、ドメインの選択された側面を記述し、そのドメインに関連する問題を解決するために使用できる抽象化のシステムです。
ドメイン駆動設計のこれらの側面は、ドメインの専門家、ユーザー、開発者が共有する共通言語、つまりユビキタス言語を促進することを目的としています。ユビキタス言語は、ドメイン モデルで使用され、システム要件を記述するために使用されます。
ユビキタス言語は、戦略的設計や戦術的設計とともに DDD の柱の 1 つです。
ドメイン駆動設計では、ドメイン層はオブジェクト指向の多層アーキテクチャにおける共通層の 1 つです。
モデルの種類
ドメイン駆動設計では、複数の種類のモデルが認識されます。たとえば、エンティティは、属性ではなくIDによって定義されるオブジェクトです。たとえば、ほとんどの航空会社は、すべてのフライトの座席に一意の番号を割り当てます。これが座席の ID です。対照的に、値オブジェクトは、属性は含まれますが概念的な ID を持たない不変のオブジェクトです。たとえば、名刺を交換する場合、人々はそれぞれの固有のカードを区別するのではなく、カードの情報 (属性) のみを気にします。
モデルは、イベント(過去に起こったこと)も定義できます。ドメイン イベントは、ドメイン エキスパートが関心を持つイベントです。モデルは、ルート エンティティによって結合され、集約になります。集約の外部のオブジェクトは、ルートへの参照を保持できますが、集約の他のオブジェクトへの参照を保持することはできません。集約ルートは、集約内の変更の一貫性をチェックします。たとえば、ドライバーは車の各ホイールを個別に制御する必要はなく、単に車を運転するだけです。このコンテキストでは、車は他のいくつかのオブジェクト (エンジン、ブレーキ、ヘッドライトなど) の集約です。
モデルの操作
ドメイン駆動設計では、オブジェクトの作成はオブジェクト自体から分離されることがよくあります。
たとえば、リポジトリは、データ ストア (データベースなど) からドメイン オブジェクトを取得するためのメソッドを持つオブジェクトです。同様に、ファクトリは、ドメイン オブジェクトを直接作成するためのメソッドを持つオブジェクトです。
プログラムの機能の一部が概念的にどのオブジェクトにも属さない場合、通常はサービスとして表現されます。
イベントの種類
DDDにはさまざまな種類のイベントがあり、その分類については意見が分かれることがあります。Yan Cuiによると、イベントには2つの主要なカテゴリがあります。[7]
ドメインイベント
ドメインイベントは、特定のビジネスドメイン内での重要な出来事を意味します。これらのイベントは境界付けられたコンテキストに制限されており、ビジネスロジックを維持するために不可欠です。通常、ドメインイベントはペイロードが軽く、処理に必要な情報のみが含まれています。これは、イベントリスナーが通常同じサービス内にあり、その要件がより明確に理解されているためです。[7]
統合イベント
一方、統合イベントは、異なる境界コンテキスト間で変更を伝達する役割を果たします。統合イベントは、システム全体でデータの一貫性を確保するために不可欠です。統合イベントは、潜在的なリスナーのニーズが大きく異なる可能性があるため、追加の属性を持つより複雑なペイロードを持つ傾向があります。これにより、多くの場合、より徹底したコミュニケーションアプローチが採用され、関連するすべての情報が効果的に共有されるようにするために過剰なコミュニケーションが発生します。[7]
他のアイデアとの関係
境界付けられたコンテキストはマイクロサービスに類似している。[8]
ドメイン駆動設計は、本質的にはオブジェクト指向アプローチに結び付けられていませんが、実際には、そのような手法の利点を活用します。これには、コマンド/メソッド呼び出しの受信者としてのエンティティ/集約ルート、最上位の集約ルート内での状態のカプセル化、およびより高いアーキテクチャ レベルでの境界付きコンテキストが含まれます。
その結果、ドメイン駆動設計は、それぞれJavaと.NET Frameworkに固有の技術的な実装の詳細であるPlain Old Java ObjectsおよびPlain Old CLR Objectsに関連付けられることが多くなりました。これらの用語は、ドメイン オブジェクトは、より具体的なテクノロジ フレームワークではなく、ドメインのビジネス動作によってのみ定義されるべきであるという考え方が広まりつつあることを反映しています。
同様に、ネイキッドオブジェクトパターンでは、ユーザーインターフェイスは、十分に優れたドメインモデルを単純に反映したものでよいとされています。ユーザーインターフェイスがドメインモデルを直接反映したものとなるように要求することで、より優れたドメインモデルの設計が強制されます。[9]
ドメイン駆動設計は、ソフトウェア開発の他のアプローチに影響を与えています。
たとえば、ドメイン固有モデリングは、ドメイン固有言語を使用して適用されるドメイン駆動設計です。ドメイン駆動設計では、ドメイン固有言語の使用が特に必要ではありませんが、ドメイン固有言語の定義やドメイン固有のマルチモデリングのサポートに役立てることができます。
一方、アスペクト指向プログラミングでは、ドメイン モデルから技術的な懸念事項 (セキュリティ、トランザクション管理、ログ記録など) を簡単に分離できるため、ビジネス ロジックにのみ集中できます。
モデル駆動型エンジニアリングとアーキテクチャ
ドメイン駆動設計はモデル駆動エンジニアリングやモデル駆動アーキテクチャと互換性がありますが、[10] 2つの概念の背後にある意図は異なります。モデル駆動アーキテクチャは、より優れたドメインモデルを定義することよりも、モデルをさまざまなテクノロジープラットフォーム用のコードに変換することに重点を置いています。
しかし、モデル駆動エンジニアリングによって提供される技術(ドメインをモデル化し、ドメイン専門家と開発者の間のコミュニケーションを容易にするためのドメイン固有言語を作成するなど)は、実際のドメイン駆動設計を容易にし、実践者がモデルからより多くのものを得るのに役立ちます。モデル駆動エンジニアリングのモデル変換とコード生成技術のおかげで、ドメインモデルを使用して、それを管理する実際のソフトウェアシステムを生成することができます。[11]
コマンドクエリ責任分離
コマンド クエリ責任分離(CQRS) は、データの読み取り (「クエリ」) とデータへの書き込み (「コマンド」) を分離するためのアーキテクチャ パターンです。CQRS は、Bertrand Meyerによって考案されたコマンドとクエリの分離 (CQS) から派生したものです。
コマンドは状態を変更し、集約ルートまたはエンティティでのメソッド呼び出しとほぼ同等です。クエリは状態を読み取りますが、変更は行いません。
CQRS ではドメイン駆動設計は必要ありませんが、集約ルートの概念によってコマンドとクエリを明示的に区別します。つまり、特定の集約ルートにはコマンドに対応するメソッドがあり、コマンド ハンドラーは集約ルートでそのメソッドを呼び出すという考え方です。
集約ルートは、操作のロジックを実行し、失敗応答を生成するか、データ ストアに書き込むことができる自身の状態を変更する役割を担います。コマンド ハンドラーは、集約ルートの状態の保存と必要なコンテキスト (トランザクションなど) の作成に関連するインフラストラクチャの問題を取り込み、処理します。
イベントソーシング
イベント ソーシングは、エンティティが直接のシリアル化やオブジェクト リレーショナル マッピングではなく、イベントを読み取ってイベント ストアにコミットすることによって内部状態を追跡するアーキテクチャ パターンです。
イベント ソーシングをCQRSおよびドメイン駆動設計と組み合わせると、集約ルートはコマンドを検証して適用し (多くの場合、インスタンス メソッドをコマンド ハンドラーから呼び出すことによって)、イベントを発行する役割を担います。これは、集約ルートがメソッド呼び出しを処理するためのロジックの基盤でもあります。したがって、入力はコマンドであり、出力は 1 つまたは複数のイベントです。これらのイベントはイベント ストアに保存され、多くの場合、関心のあるユーザー (アプリケーションのビューなど) 向けにメッセージ ブローカーで発行されます。
集約ルートをモデル化してイベントを出力すると、標準的なn層データ受け渡しアーキテクチャのように、エンティティから読み取りデータを投影する場合よりもさらに内部状態を分離できます。 1つの大きな利点は、集約ルートが内部状態を包括的に隠蔽するため、公理定理証明器(Microsoft ContractsやCHESS [12]など)の適用が容易になることです。 イベントは集約ルートインスタンスのバージョンに基づいて永続化されることが多く、これにより、楽観的同時実行性を通じて分散システムで同期するドメインモデルが生成されます。
注目すべきツール
ドメイン駆動設計は特定のツールやフレームワークに依存しませんが、注目すべき例としては次のようなものがあります。
- Actifsource は、DDD とモデル駆動型エンジニアリングおよびコード生成を組み合わせたソフトウェア開発を可能にするEclipse用プラグインです。
- Context Mapperは、戦略的および戦術的なDDDのためのドメイン固有言語およびツールです。[13]
- CubicWeb は、データ モデルによって完全に駆動されるオープン ソースのセマンティック Web フレームワークです。高レベルのディレクティブにより、リリースごとにデータ モデルを繰り返し改良できます。データ モデルを定義するだけで、機能する Web アプリケーションを作成できます。デフォルトのビューが十分でない場合、データをどのように表示するかを定義するには、さらに作業が必要です。
- OpenMDX は、 Java SE、Java EE、および.NETをサポートするオープンソースの Java ベースの MDA フレームワークです。OpenMDX は、 「モデルを使用して運用システムの実行時の動作を直接制御する」という点で、一般的な MDA フレームワークとは異なります。
- Restful Objects は、Restful API をドメイン オブジェクト モデル (ドメイン オブジェクトはエンティティ、ビュー モデル、またはサービスを表す) にマッピングするための標準です。2 つのオープン ソース フレームワーク (1 つは Java 用、もう 1 つは .NET 用) は、リフレクションを使用して、ドメイン モデルから Restful Objects API を自動的に作成できます。
- Qlerify は、スウェーデンの会社 Qlerify AB が開発したソフトウェア モデリング プラットフォームです。2022 年にリリースされたこのプラットフォームは、ソフトウェア開発の生産性を高めるために設計されており、イベント ストーミング、ドメイン駆動設計(DDD)、ユーザー ストーリー マッピングなどの方法論をサポートしているため、ユーザーはビジネス要件をAtlassian Jiraなどのツールと同期できる詳細な仕様に変換できます。この統合により、リアルタイムのコラボレーションがサポートされ、ソフトウェア要件とユーザー ストーリーを定義するための視覚的なアプローチが提供されるため、関係者の調整に役立ちます。
参照
- セルベースアーキテクチャ、分散型リファレンスアーキテクチャ
- データメッシュ、ドメイン指向データアーキテクチャ
- イベントストーミング
- 知識表現
- オントロジー(情報科学)
- 意味解析(知識表現)
- 意味ネットワーク
- セマンティクス
- C4モデル
- 厳密に型指定された識別子
- 統合設計
- システム科学
参考文献
- ^ ミレット、スコット、チューン、ニック (2015)。ドメイン駆動設計のパターン、原則、および実践。インディアナポリス: Wrox。ISBN 978-1-118-71470-6。
- ^ Vernon, Vaughn (2013).ドメイン駆動設計の実装. Upper Sadle River, NJ: Addison-Wesley. p. 3. ISBN 978-0-321-83457-7。
- ^ ドメイン駆動設計: ソフトウェアの核となる複雑性への取り組み。Addison-Wesley Professional。2003年。ISBN 978-0321125217。
- ^ martinekuan. 「戦術的 DDD を使用したマイクロサービスの設計 - Azure アーキテクチャ センター」。learn.microsoft.com。2024年 9 月 7 日取得。
- ^ Microsoft アプリケーション アーキテクチャ ガイド、第 2 版。http://msdn.microsoft.com/en-us/library/ee658117.aspx#DomainModelStyle から取得。
- ^ ab エヴァンス、エリック(2003 年 8 月 22 日)。ドメイン駆動設計:ソフトウェアの核となる複雑性への取り組み。ボストン:アディソン・ウェズリー。ISBN 978-032-112521-7. 2012年8月12日閲覧。
- ^ abc Cui, Yan. AWS 上のサーバーレスアーキテクチャ。Manning. ISBN 978-1617295423。
- ^ ソフトウェアアーキテクチャの基礎:エンジニアリングアプローチ。オライリーメディア。2020年。ISBN 978-1492043454。
- ^ ヘイウッド、ダン (2009)、ネイキッドオブジェクトを使用したドメイン駆動設計、プラグマティックプログラマーズ。
- ^ MDEはMDAのスーパーセットとみなすことができます
- ^ Cabot, Jordi (2017-09-11). 「ドメイン駆動設計とモデル駆動エンジニアリングの比較」。モデリング言語。2021-08-05閲覧。
- ^ MSのバグ発見ツール
- ^ Stefan Kapferer と Olaf Zimmermann: ドメイン駆動型サービス設計 - コンテキストモデリング、モデルリファクタリング、契約生成、第 14 回サービス指向コンピューティングシンポジウムおよびサマースクール (SommerSoC 2020)[1]
外部リンク
- ドメイン駆動設計、定義とパターンの概要(PDF)、Eric Evans、2015
- GitHub の DDD Crew: 境界付きコンテキスト キャンバス、集約キャンバス、モデリング プロセス、その他のリポジトリ
- ドメイン駆動設計、手法、ツールの紹介
- C# 言語で集約ルートを実装する
- コンテキスト マッパー: 戦略的ドメイン駆動設計のためのモデリング フレームワーク (ツール、チュートリアル、DDD モデリングの例)
- デザインプラクティスリポジトリ (DPR) における戦略的 DDC アクティビティとデザインプラクティスリポジトリ (DPR) における戦術的 DDC アクティビティ
