1

では、図書館管理システムを設計する必要があるとしましょう。現在、これは、ユビキタス言語を記述し、境界付けられたコンテキストを把握し、集約ルートを作成し、最終的に書籍、ユーザー、著者などを含むオブジェクト モデルを作成することにより、ドメイン駆動型の設計原則によって実行できます。

しかし、Salesforce や Sharepoint (カスタム フォームやワークフローを設計および作成する機能を備えたもの) のような一般的なシステムを設計しなければならない場合はどうでしょうか。そのため、まず、図書館管理システムや人的資源管理システムなどの他のシステムを実装するために使用できる汎用システムを作成します。

汎用システムの設計にドメイン駆動設計の原則を引き続き適用できますか? はいの場合、ユビキタス言語では、書籍、ユーザー、著者、従業員、部門などのドメイン オブジェクトをリストする必要があります。以来、この汎用システムは、他のドメイン固有のシステムを実装するために使用できます。

言い換えれば、一般的なシステムを作成する際にドメイン駆動設計の原則をどのように適用するのでしょうか? これは、後で他のドメイン固有のシステムを実装するために使用できます。

4

1 に答える 1

3

汎用システムの設計にドメイン駆動設計の原則を引き続き適用できますか?

はい、DDD は、説明した汎用システムに適用できます。

はいの場合、ユビキタス言語では、書籍、ユーザー、著者、従業員、部門などのドメイン オブジェクトをリストする必要があります。

objectやhashtableなどの名前は一般的なものであるだけでなく、非常に強力な技術的意味合いも持っています。ユビキタス言語は、開発者とドメインの専門家の間で共有されるため、技術的な影響はできるだけ少なくする必要があります。これは、オブジェクトなどの技術的な名前が間違っていると言っているわけではありません。ドメインとそれをサポートする技術インフラストラクチャとの違いに注意してください。すべてのドメイン エキスパートが開発者である場合でも、この区別を行うことは重要です。

DDD は、戦術と戦略という 2 つの要素で構成されていると言えます。戦術的なパターンは技術的な性質のものであり、リポジトリ、値オブジェクトなどを含みます。これらのパターンは通常、言語とプラットフォームごとに固有の表現を持っています。これらのパターンは、テクノロジーの変化に応じて変化する可能性が最も高いです。たとえば、 DDD でイベント ソーシングを使用する場合、戦術パターンは多少異なります。あなたが説明したような一般的なシステムを実装する場合、戦術パターンはさらに異なる場合があります。

戦略的パターンは、より高いレベルの抽象化で動作し、境界付けられたコンテキスト、コンテキスト マップ、ユビキタス言語、モデル/設計の渦などを含みます。これらのパターンは、技術的な制約に縛られず、戦術的なパターン以外にも適用できます。また、ある意味では、戦術パターンよりも重要であり、コンピューターのやり方よりも人々の考え方に合わせて調整されているため、基盤となるテクノロジーに関係なく適用できます。その結果、一般的なドメインで戦略的パターンの利点を引き続き享受できます。

于 2012-12-10T23:10:07.440 に答える