無限大な夢のあと

テニスとアニメが大好きな厨二病SEのブログ

「エリック・エヴァンズのドメイン駆動設計」を読んで(自分用メモ) 第1部 ドメインモデルを機能させる

DDD導入研修の課題として、下記の書籍「エリック・エヴァンズのドメイン駆動設計」を読むことになりました。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

本文章は上記の書籍を引用させて頂きます。


ただ漠然と読んでいるだけだと、頭を通りすぎていきそうなので、自分なりに要点や響いた箇所、メモを残しながら読んでいこうと思います。
「Domain-Drive Design Quickly」は約80ページしかありませんでしたが、こちらはボリュームが大きいので、覚悟しながら読もうと思います。

Kindle書籍からだとコピーできないため、簡単にまとめていきます。

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

・Intordcution

ドメイン駆動設計におけるモデルの有用性
 1.モデルと設計の確信が相互に形成し合う。
 2.モデルは、チームメンバ全員が使用する言語の基盤である。
 3.モデルとは、蒸留された知識である。

ここも一応メモ。
後ろの章を読むと、より理解度が上がる気がするので。

・第1章 知識を噛み砕く

効率的なモデリングの要素
 1.モデルと実装を結びつける。
 2.モデルにもど突いて言語を洗練させる。
 3.知識豊富なモデルを開発する。
 4.モデルを蒸留する。
 5.ブレインストーミングと実験を行う。

ここの手順はメモとして残しておく。

知識豊富な設計

モデルによって捉えられる知識は「名詞を見つける」ことにとどまらない。
ビジネスの活動やルールも、ドメインに含まれるエンティティと同じように、ドメインにとって中心的なのだ。

エンティティや値を超えて、その先に行こうとする、このような動きに伴った時こそ、知識の嚙み砕きは力を発揮できる。
通常、ドメインエキスパートは、自分の頭の中で起きているプロセスがいかに複雑化を意識することなく、仕事をする中でこれのルールを全て調べて矛盾を調整し、常識で考えて隔たりを埋めている。だが、こういうことはソフトウェアにはできない。
ソフトウェアエキスパートと密接に協力する中で、知識を噛み砕くことによって初めて、ルールが明確となり、具体化されて、折り合いがつけられるか、あるいはスコープの対象外とされるのである。

「名詞を見つける」ことにとどまらないということに少しドキッとした。
ドメインエキスパートとともに知識を噛み砕いて、明確化していくということが大事。

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

声に出してモデリングする

モデルを改良する最適な方法の1つは、話して見ることだ。考えらえるモデルのバリエーションから生じる様々な概念を、声に出して構成してみる。荒削りな表現は聞けば、すぐわかる。

ここは例を見て、そうだなと思った。
実践してみよう。

「彼らには抽象的すぎる。」
「オブジェクトがわかっていない。」
「彼らの用語法に従って要求を集めなければならない。」

豊富な知識を持つドメインエキスパートがモデルを理解できないとしたら、モデルに何か問題があるのだ

ここは現場ではよくありそう。
解決策の一つとして、ユビキタス言語を作っていくというのはあるのか。

設計に関する本質的な詳細は、コードにおいて捉えらえる。

同意。

常に覚えていてほしいのは、モデルは図ではない。

モデルを伝える手段の一つが図であるだけ。

ドキュメントはコードや会話での表現を補わななければならない

そうあるべきだと思う。

すでにコードがうまくやっていること、ドキュメントでもやろうとするべきではない

受託開発でよく作るいわゆる詳細設計書かな。
これらは納品物ということで必要なだけで、いわゆる基本設計書相当のドキュメントがWikiなどに残っていればそれで十分。


・第3章 モデルと実装を結びつける

ソフトウェアシステムの一部を設計する際には、紐付けが明らかになるように、ドメインモデルを文字通りの意味で忠実に反映させること。
モデルについて、再検討し、より自然いソフトウェアに実装されるように修正すること。
これはドメインに対するより深い洞察を反映させようとする時にも言える。強固なユビキタス言語を支えることに加えて、ドメインと実装両方の目的に使える単一のモデルを要求すること

ここは繰り返し記述されていることだが、単一のモデルということに着目。

設計で使用する用語法と責務の基礎的な割り当てをモデルから引き出すこと。
コードはモデルの表現となるから、コードに対する変更はモデルに対する変更になるかもしれない。
その影響は、プロジェクトの他の活動全体へと適宜伝わっていかなけければならない。
実装を一分の狂いもなくモデルに結びつけるには、通常、オブジェクト指向プログラミングのようなモデリングパラダイムをサポートする、ソフトウェア開発のためのツールと言語が必要である。

モデルを元に実装も行っていきましょうという話。
実際問題、コード設計に入った時にトランザクション境界で色々考えなければいけないが、そこは設計パターンみたいな解決のアプローチがあるのかな。

第2部 モデル駆動設計の構成要素 へ続く。

実践ドメイン駆動設計 (Object Oriented SELECTION)

実践ドメイン駆動設計 (Object Oriented SELECTION)

ドメイン駆動 (Programmer’s SELECTION)

ドメイン駆動 (Programmer’s SELECTION)

ビジネスパターンによるモデル駆動設計

ビジネスパターンによるモデル駆動設計