adminほとんどの商用ソフトウェアアプ しかし、すべてのソフトウェア開発者/アーキテクトがビジネスドメインの専門家であることを期待し、ビジネス機能全体を知っていることを期待す 一方、どのように我々は価値をもたらすソフトウェアを作成し、ソフトウェアを使用する自動化を必要としている消費者を持っていますか？ ソフトウェアアプリケーションは、技術的な卓越性の単なる展示品ではありませんが、ほとんどの場合、また、自動化されたビジネスの卓越性の実 これらの質問に対する答えは、ドメイン駆動型の設計とモデルです。
この短い記事では、DDDの概念、原則、パターンが、作成および管理できる洗練されたソフトウェアアプリケーションにテクノロジーとビジネスの卓越性を
Talk Ubiquitously
Ubiquitous languageは、ソフトウェア開発者とドメインの専門家の間のコミュニケーションを支援する普遍的な言語として機能するモデルです。
モデルの協力、学習、定義は、ソフトウェア専門家とドメイン専門家の間に多くの初期のコミュニケーション障壁をもたらします。 そのため、コンテキスト内で同じタイプのコミュニケーション（議論、文章、図）を実践してドメインモデルを進化させることは、実装を成功させるために最 これはドメインモデルを中心に構造化されており、境界のあるコンテキスト内ですべてのチームメンバーによって広く使用されています。 それは、ソフトウェアの開発の中でチームのすべての活動を接続するための媒体またはモードでなければなりません。
設計チームは、ドメインの専門用語やソフトウェアエンティティをユビキタス言語で深く理解し、接続して、ドメインモデルを発見し、進化させ続
|
ユビキタス言語 |
同等の擬似コード |
|
|
私たちはワクチンを投与します |
———–{} |
コアドメインではない–いくつかのより具体的な詳細が必要 |
|
患者さんにインフルエンザの予防接種をしていますが、 |
パティントネードフルショット() |
より良い、可能性があります いくつかのドメインの概念が欠落している |
|
看護師は、標準用量で患者にインフルエンザワクチンを管理します |
看護師->getStandardDose()) |
はるかに良い、とで開始するのが良いかもしれません。 |
上記の表で見たように、ユーザーストーリー（要件）を与えることができるさまざまな方法がありますが、最後の行は、何とどのように要因についてより明確にして
この記事は、読者がDDD原則がどのように提唱しているかを垣間見るのに役立ち、主題の専門家、ビジネスアナリスト、非技術関係者と技術/開発コミュ