⚒️

【Eric Evans DDD】読書メモ第1,2章ドメインモデルを機能させる

2023/06/11に公開

アーキテクチャ

DDD

tech

第1部ドメインモデルを機能させる

ドメイン駆動設計におけるモデルの有用性

モデルと設計の核心が相互に形成し合う
- モデルとドメインが深く関連すれば最終成果物である実際に動くプログラムに適用されることが保証される。
- この密接な結びつきは保守や継続的開発に役立つ
モデルはチームメンバ全員が使用する言語の基盤
- 開発者やドメインエキスパートと通訳せずにコミュニケーションが取れる
モデルとは蒸留された知識
- モデルはドメイン知識を構成して最も関心のある要素を区別するためのチーム内で取り決めた方法。共有された言語があれば効率的に共同作業ができる

ソフトウェアの核心

ソフトウェアの核心はドメインに関係した問題をユーザーのために解決する能力。
開発者は複雑なフレームワークに取り組み、複雑なドメインの解決を試みるが、ドメイン理解に真正面から立ち向かわなければ的外れな設計になってしまう。

第1章　知識を噛み砕く

効果的なモデリングの要素

1. モデルと実装を結びつける

本質的な結びつきがわかるので荒削りでもプロトタイプ(簡単な図)を作る
そこから少しずつドメインエキスパートと会話して洗練させていく

2. モデルに基づいて言語を洗練させる
モデルで利用される単語を使って会話すると通訳しなくても開発者とドメインエキスパートとで分かり合える
3. 知識豊富なモデルを開発する
オブジェクトにはふるまいと守るべきルールがある
モデルは単なるデータスキーマではなく、問題を解決するのに欠かせないもの。
モデルはさまざまな知識をとらえている。
4. モデルを蒸留する
モデルが完成するにつれて重要な概念が追加されていき、不要な概念は取り除かれ、新たなモデルが生まれたりする。
5. ブレインストリーミングと実験を行う
言語をスケッチやブレインストリーミングと組み合わせることでモデルを実験していった。
チームがシナリオを詳細に検討する際には会話で使われる表現自体が提案されたモデルを実現できるかどうかについて調べる簡易的なテストになる。

ブレインストリーミングと大量の実験が持つ創造性によって知識豊富なモデルを見つけ出し、そのモデルを蒸留できるようになる。こうし知識を噛み砕くことでチームの持っている知識が価値あるモデルへと変わる。

知識の噛み砕き

チームメンバ間のやりとりはメンバ全員がモデルを一緒に噛み砕くことで変化する。ドメインモデルを絶えず改良し続けると開発者はドメイン知識習得を強いられ機械的に機能を作り出すことがなくなる。ドメインエキスパートは自分の理解を精緻にし、プロジェクトが必要とする概念の正確さを理解するようになる。
改善されるにつれてチームメンバのドメインに対する理解が深まり、モデルがされに精緻化される。
有能なドメインモデラは知識を噛み砕く。
本当に重要なものを明らかにしてくれるシンプルな説明を探す。こうした理解こそが、意思決定を行う際に、基礎となり得るのである。
このようなモデルは決して完成することがない。 代わりに進化していく。
モデルは実用的で役立つ,厳密なものでなければならない。

継続的学習

ソフトウェアを書き始めるとき、我々は対象を十分理解してるわけではない
自分達がどれほど理解していないかを知らない。
高度に生産的なチームは自分達の知識を意識的に育て、継続的学習を実践する。
こうして学んだメンバはチームの中でコアとなる。

深いモデル

役立つモデルがすぐ見つかる表層いあることは滅多にない。
ドメインとアプリケーションがやるべきことを我々が理解するようになるにつれて、たいていの場合、表層にあり　最初は重要と思われたモデル要素を廃棄するか、それらのモデル要素を違った視点で見ることとなると、最初は考え付かなかった、たいていは核心をつくようなうまい抽象が現れてくる。

第2章　コミュニケーションと言語の使い方

ユビキタス言語

用途の幅広い、共有されたチームの言語とその言語を使った活発な実験が必要。
言語に亀裂が入ると言語に亀裂があるとプロジェクトは深刻な問題に直面する
ユビキタス言語における変更はモデルに対する変更であると認識する
ドメインについて会話する際伝えにくかったり不適切だったり、設計の妨げになるような曖昧さがないようにユビキタス言語を定義すべき

ドキュメントと図

シンプルな略式のUML図によって、議論に確固とした基盤が与えられる。しかし詳細にコーディングしようとしているオブジェクトを、すべてモデリングツールに描かなければならないわけではない。
図はコミュニケーションと説明のための手段であり、ブレインストーミングを容易にする。オブジェクトモデルにおいて概念的に重要な部分を表す、簡略化した図である。
モデルは図ではない。図の目的は、モデルについてコミュニケーションし、説明するのを助けることにある。

書かれた設計ドキュメント

ドキュメントはコードや会話での表現を補わなければならない
すでにコードがうまくやっていることを、ドキュメントでもやろうとすべきではない
ドキュメントは活動の役に立たなければならず、最新の状態を保たなければならない
ドキュメントはプロジェクトの活動に取り込まれていなければならない

説明のためのモデル

実装、設計、チーム内のコミュニケーションの根底にあるモデルは一つであるべき
しかし、他のモデルが必要とされる場面があり、それはスコープ。
ソフトウェア開発プロセスを推進する技術的なモデルは、厳密に刈り込み、機能を満たす上で必要な最小限のものにしなければならない。
それに対して説明のためのモデルあれば、ドメインの持つ、スコープがより限定されたモデルをわかりやすくわかりやすく示すコンテキストを提供するような場面を含むことができる。
- 説明のためのモデルがオブジェクトである必要はなく、通常はそうでない方が良い。UMLを避け、ソフトウェア設計と一致するという誤った印象を与えないようにした方が良い。