IDDD 本こと「実践ドメイン駆動設計」の 1 章を読んだので忘れないようにアウトプットします。
1 章のテーマは「 DDD への誘い」になります。
そもそもなぜ DDD を導入するのか
DDD を導入した結果、DDD がもたらしてくれる物を本書では以下のように表現しています。
これをうまく使いこなせば、設計した結果が、そのソフトウェアの動作を明確に表すようにできる。
一般的なシステム開発では、ビジネスの観点で定められた要望に対して、技術的な観点で解決されます。
そして出来上がったシステムは技術的な観点に寄ったシステムとなり、エンジニア以外には理解し難いものになります。
また、ビジネスは時代に応じて変化を要求されます。
エンジニア以外には理解し難い状況に陥ったシステムはビジネスの変化に対応出来ず、破綻します。
これが、システムの寿命だと思います。
DDD はシステム設計にビジネスの観点の割合を増やし、システムの寿命を伸ばしていくために導入するものだと私は理解しました。
ユビキタス言語
DDD ではビジネス的な観点に立つ人をドメインエキスパート、技術的な観点に立つ人を開発者と呼んでます。
DDD ではユビキタス言語というドメインエキスパートと開発者の両方が理解出来る言葉を中心に設計します。
ユビキタス言語はビジネスの中から創作され、チームの中で共有される言語として仕事上の会話や打ち合わせ、コードで使用されます。
DDD ではユビキタス言語からデータと振る舞いが定められ、 ドメインモデルとして、その文脈に沿ってコードに落とし込まれていきます。
そのため、 DDD が実践されたシステムのコードはそうでないコードに比べ、業務知識が多く読み取れるようになります。
例として、ユビキタス言語を適用していないコードと適用したコードのサンプルを以下に示します。
// ユビキタス言語を適用していないコード // 以下のコードからは業務上の単語は知れても知識は得られない patient.SetShotType(ShotTypes.Flu); patient.SetDose(dose); patient.SetNurse(nurse); // ユビキタス言語を適用したコード // 「ワクチンの中には大人向けインフルエンザワクチンがある」という業務知識 Vaccine vaccine = vaccines.StandardAdultFluDose(); // 「看護師は患者にワクチンを投与する」という業務知識 nurse.AdministerFluVaccine(patient, vaccine);
DDD が事業にもたらすこと
本書では以下のように列挙されています。
箇条書きのレベルを下げて自分の解釈を簡潔にまとめます。
- 組織として、ドメインに関する有用なモデルを獲得できる
- 力を入れるべき分野を精査・集中させることが出来るため
- 事業について、より洗練された正確な定義ができて、さらに深く理解できる
- 背景となるビジネスに理解が深まるため
- ドメインエキスパートが、ソフトウェアの設計に貢献できる
- ユビキタス言語の検討や整理には業務知識が必要なため
- よりよいユーザー体験を提供できる
- よりビジネスに寄り添って作られたシステムは、システム自身がユーザーを正しい使い方に導くため
- モデルとモデルの間に、明確な境界を定められる
- DDD では境界づけられたコンテキストにより業務の関心ごとを分離する
- エンタープライズアーキテクチャが、より整理されたものとなる
- 境界づけられたコンテキストにより理解する単位が小さくなるため
- アジャイルでイテレーティブなモデルを、継続的に行える
- これは DDD が一般的にアジャイルで開発するため
- 戦略的な面でも戦術的な面でも、新しいツールを使える
- DDD の戦術的設計によるもの
DDD を実施する上での壁
DDD は複雑なドメインを可能な限りシンプルにモデリングするために使うものです。
そのため、本来シンプルに設計可能なシステムに無理に DDD を導入すると返って複雑になる可能性があります。
DDD を導入するにあたってまず、対象のシステムは DDD を導入するコストを払う価値があるか判断する必要があります。
また、導入するとなってもいくつかの壁はあります。
DDD ではより洗練されたユビキタス言語を作り出すため、多くの時間を必要とします。
ユビキタス言語を作り出すためには、情報源となるドメインエキスパートをプロジェクトにアサインし続ける必要もあります。
開発の仕方も従来とは異なるため、開発者には以下のような負担を強いります。
これらの壁は、本書では誰もがする経験の一例として挙げられています。
計画段階から意識しておく必要があると思います。
