研修でエヴァンス本を読むという課題を頂いており、自席で読書に勤しんでおります。Scala + DDD でやっているので DDD の部分を身につけるという文脈です。読むだけだと忘れてしまうので、自分が特に重要だと感じた点に絞ってメモを残します。
background
XP のプラクティスであるところの
- イテレーティブな開発
- ドメインエキスパートと開発者が密接に関わる
点を前提としている。
設計の方法論についての本だが開発プロセスにも言及する。設計を実践する上で開発プロセスは切り離せないため。
第1部 ドメインモデルを機能させる
ドメインとはソフトウェアユーザの活動、関心事のこと。ドメインをモデリングしたものがドメインモデル。
ドメインモデルを中心に据えてドメインの複雑さ、量に立ち向かおう。
モデリングは写実的であれば良いわけではない。詳細を省き、簡素化、抽象化することが重要。関心の薄いものはモデルから削除する。
ドメインモデルはコミュニケーション、分析、設計、実装において単一のものを用いることが重要。ドメインエキスパート、開発者間で通訳をなくすことで、コミュニケーションを円滑にする。
分析、開発を別の人が担当した場合、意図が伝わらない、フィードバックが得られないなどの理由により、分析と実装の間でモデルが別れてしまう。
オブジェクト指向設計というパラダイムにより、ドメインモデルを設計に反映する。（他の選択肢として論理というパラダイムでPrologに反映するという例が言及されている)
ユビキタス言語
会話、設計書、コードを通じて一貫して使われる言葉を確立する。ユビキタス言語。開発者とドメインエキスパートがドメインモデルを確立するための対話を行うことにより確立していくことができる。モデルと言語が一致していること。
抽象化した概念を用いて実装詳細を隠蔽することでドメインエキスパートと円滑に会話できるように心がける。
声に出してモデリングすることが大事。人間に備わっている言語能力によりモデリングが助けられる。
モデルの表現
UML のクラス図、オブジェクト相互作用図は便利。オブジェクト間の制約など表現しづらいものを自然言語で書き加える。
詳細を表現するにはコードが便利。コードを使おう。
ドキュメントは
- コードで満たされていることを重複してしない
- 最新に保つ
- モデルと結びついている
ことに留意。
説明用のモデル
ドメインのスコープを超えて話す場合などに、説明用のモデルが必要になる。ドメインモデルはドメインにスコープを区切っているため。
説明用のモデルはドメインモデルと表現を変えた方が良い。
感想
設計方法論にも関わらずプロセスまで踏み込んでしまうため違和感がある。しかし厳しい現実ではプロセスを抜きにして方法を語ることはできないという主張は納得できるところがある。
第1部を一言で表すなら「ドメインとモデルが重要。全員が使える一つの言語、一つのモデルを練り上げて複雑さに対抗しよう。」ということになるだろうか。
完読せよとのことなので、その2へ続きます(予定)。