前回のふりかえり
第10章③の主旨
- 宣言的な設計
- プログラムやその一部をある種の実行可能な仕様として作成する方法
- 性質を厳格に記述することで、ソフトウェアを実際に制御する
- 設計の宣言的スタイル
- 設計的な設計の利点を得るには、意図の明白なインターフェース・副作用のない関数・表明などの要素を組み合わせて使用する
- それに加え、論理演算子を使用することで、仕様を結合するという方法もある
第11章 アナリシスパターンを適用する
- 深いモデル・しなやかな設計は容易に手に入るものでは無いが、ドメイン(会計など?)によってはすでにドキュメント化され、共有されたものがある。
- それを使うと、本来高くつく試行錯誤を手早くすませることができる。
→ それがアナリシスパターン
アナリシスパターンはどういうものなのか
→ そのまま用いることができるものではない
- 調査に対して有益な手がかりを与え、明確に抽象化された語彙を提供してくれる。
- 自分たちで一からドメインモデルを模索せずに済む
アナリシスパターンを使うに当たって注意すること
- アナリシスパターンの用語を使用する場合は、そのパターンが規定する基本的な概念を崩さないように注意する。元のまま保つようにする。
→ ここがよくわからなかった。アナリシスパターンの用語を改変するのではなく、モデルの進化を通してユビキタス言語を変更するよう努めろということ?
思ったこと・気になったこと
- 11章だけ読んでも「アナリシスパターン」の姿があんまりよくわからなかったので調べてみた。
アナリシスパターンとは、分析(analysis)のパターンです。デザインパターンがオブジェクト指向設計の中で繰り返し現れる構造をパターン化したものであるように、アナリシスパターンはドメイン分析の中で繰り返し現れる構造をパターン化したものです。「量」「勘定」「計画」「ポートフォリオ」「先物取引」など、再利用可能なドメインモデルがパターンとしてまとめられています。
アナリシスパターンとDDDの違いは、アナリシスパターンが「ドメインモデル」のパターンであるのに対し、DDDは「ドメインモデリング」のパターンであるということです。アナリシスパターンはドメインモデルの具体例を提供するものであり、DDDはどうやってドメインモデルを構築すればよいかを教えてくれるものです。
[ 技術講座 ] Domain-Driven Designのエッセンス 第1回|オブジェクトの広場
アナリシスパターンを使うことでドメインモデリングの工程をある程度(全部ではない)スキップすることができるということかなと理解した。