DDD本を読んだ感想

DDD本を１周しての雑多な感想。

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

コーディングに早さと質の、うまい早い安いのバランスを求めたいのだけどモデリングでうだうだと悩んでて遅筆になっちゃってるし、最初は名案やと思ってた方向性で突き進んだ結果、結局コレジャナイ感の高いコードができあがる。

近況を述べますとリポジトリとかサービスだとかの用語をネットや会話やコードで見るようになって、俺の中でDDDが話題沸騰中という雰囲気になっていた。リポジトリって何するの？サービスじゃ抽象的すぎでよく分からん。何も考えずパターンに当てはめてるだけでは。なんて中身も見ずに思っていた。でもパターンというものは良いもので、人との認識をある程度共通化できるコミュニケーションツールとしてや、昔からのノウハウが蒸留された知識として決断を支援してくれることもある。僕が用語を理解していないだけで、実はかなり便利なものなのではという流れで読み始めた。

DDD本の内容

DDDでは取り組むドメインを理解し続けようと努め、その理解を具現化することに重点を置く。ドメインを理解していなければ、一時的にしか使われないようなところに力を入れてしまったりと的はずれな開発方針になる。なので、プロダクトの重要な部分においてドメインエキスパートと開発者達はプロダクトの成長という目的のために、二人三脚で進む。

ドメインエキスパートの考えている概念とそれを表現するコードの前提に齟齬があると、手戻りが発生することになる。概念とプロダクトのコードはモデルレベルでマッピングできるよう努めると、ドメインエキスパートと開発者間の溝は小さくなる。概念をそのままコードとして表現できれば、ソフトウェアとして表現したいものが全然表現されていなかった！ということが減る。

ドメインに対する深い理解を得るには時間がかかるし、そもそも完全な理解というものは無いので、探求し続ける必要がある。その中でブレイクスルーがあったり、理解がめちゃくちゃ間違ってたりで今まで具現化していたものに大幅に修正を加える必要が出てくる。そういう状況がきても対処できるような、しなやかな設計にできる高度なスキルが必要になる。

というのがDDD本を読んで知ったこと。納得のいく、まっとうな話だと思う。

DDDは、オブジェクト指向コミュニティの間で長年培われてきたドメインモデリングのノウハウやベストプラクティスを集大成した、1つの設計思想／哲学です。ドメインモデルをこれから構築しようとする人に、設計上の判断を下すための枠組みと、ドメイン設計について議論するためのボキャブラリを提供するものです。

http://wwww.ogis-ri.co.jp/otc/hiroba/technical/DDDEssence/chap1.html

DDD本は上記のように、ボキャブラリを提供してくれることが一番良い所だと感じている。モデリングに関するブログ記事とかコードとかも読みやすくなる。

DDDを適用するとき

ドメインへの理解があって開発も自分でするなら、自分が書きやすい・保守しやすいと思う方法を取れば良い。でも、自分がベストだと思っている方法が人から見ると分かりにくかったりすることは当たり前にある。ドメインという概念をベースに抽象化されたパターンは誰にでも分かりやすそうだと思うし、蒸留されたドメインモデルも扱いやすそうだと思う。出来上がっているモデルへの分かりやすさや手の入れやすさという点では良いと思うけど、高度なモデリングスキルをもってチーム全体で開発していくという点が厳しい。DDDを本格的に採用するにはドメインに対する深い理解があるドリームチームが望まれる。なので、できる部分はDDD本に書いてあることを実践しましょうという印象をもった。

個人的にはドメインへの理解がどうのこうのというよりも、ドメイン知識に頼らずとも取り回しやすいコードを書こうという意識が第一にありたいなと思う。そういう点では、レイヤ化アーキテクチャとかのDDD本に書いてあるいくつかのパターンが有効に使える。次の段階でドメインモデルの蒸留等のドメインへの理解を元にしたパターンがくる。

最後の結論に書いてあることが良かった。基本的に良い話が多く、しっかりプログラミングしよう！！！！！！！！！という気持ちになる。

実際に動く複雑なソフトウェアを、素人が作成できる時代にはなっていない。初歩的なスキルを持ったプログラマを大勢集めても、ある種のソフトウェアを作り出すことはできるが、そうやって作れるのは、土壇場にある企業を救い出せるような類のものではない。