ドメイン駆動設計の読み方

on under programming
1 minute read

エリック・エヴァンスのドメイン駆動設計、途中理解に苦しむところも多くて何度も挫折しそうになりましたが一か月半ほどかけて少しずつ読み進めた結果やっと読了しました。

この本、周りの人の話を聞いていると、途中で挫折して放置してるみたいな話をよく聞くので、自分なりの挫折しない読み方みたいなものをまとめておきたいと思います。持ち合わせている知識によってこの本の印象は大きく変わると思うので、新卒一年目エンジニアの個人的な意見として受け取ってください。

ドメイン駆動設計

ドメイン駆動設計の難しさ

読み方の説明の前に軽く、ドメイン駆動設計とは?みたいな話をしておきます。まず、ドメイン駆動設計のドメインとはソフトウェアがこれから解決していく対象になる領域のことで、その領域をいかに解釈し変更に強いチームやソフトウェアの構造を作っていくかといったようなことが議論されています。

議論の対象になる分野は、開発チームの分離・集約の方法から、ドキュメントの書き方、ソフトウェアのアーキテクチャに至るまで非常に広範囲です。これらの分野は独立して一冊の本になるくらい(マイクロサービス、UML、オブジェクト指向、クリーンアーキテクチャ等)ボリュームのあるものなので、この守備範囲の広さがこの本の難しさの一つの要因になっていると思います。これらの範囲を一冊の本でまとめようとしているわけなので、各分野の説明はざっくりとしたものになります。その上で、それらを活用したあとの結果や、特定分野に知識が偏ったときの副作用等を中心に議論が進むのでなかなか理解が難しいです。各分野に対して本を読んだり、実務で経験したりしていないと、実感がわかない部分は多いと思います。

加えて、本に登場する用語が抽象的で、はっきりとした定義がなされないまま議論が進むことも理解を進める上での障壁になります(共有カーネル、コンテキストマップ、コアドメインみたいな用語が次から次へと出てくる)。「共有カーネル」について説明している章を例として見てみると、最初にチーム間での連携についての話が始まった後、だんだんとチーム間で相談を行いながら共有カーネルを変更していく話になっていきます。それで気づくと共有カーネルについてはっきりと明言がされないままその章が終わってしまいます。読み終わった後、共有カーネルってなんだったけ?ってなって章をもう一度読み返していると、モデルやコードのサブセットを共有するみたいな話をみつけて、あっ!共有カーネルって今まで議論してきた事柄をチーム間で共有していくことを指しているだけか!みたいな理解にやっと行きつく形になります。

このように、そもそも議論する対象が広いのと、明確な定義がされていない用語が多いという二点においてこの本には読みずらさがあると感じました。

どう読むか

ではどう読むかといえば、最初は流し読みをしてしまって、最終的に気になる部分の知識を補強していくというのが自分なりの結論です。流し読みしていく途中でも、わからない用語があとの議論で再度登場して理解が深まるといったことが何度も起きます。そのため一通り読み終えた上で再度気になる部分だけ読み込むと、全体像がとらえられて理解できなかったところがすんなり入ってきたりします。

それでも分からない場合はググったりしながら意味を理解すればいいと思います。ものによってはその用語に関して一冊本が出てきたり(エクストリームプログラミングやアナリシスパターン等)もするので、興味があればその本を読んでみたりするのもいいと思います。その選択をする上でも最初にざっと読んで全体を理解しておくことには価値があると思います。

自分の場合は最初からわりと真面目に一つ一つの章を読んでしまったので、わからない用語をググったり、前の章にさかのぼって理解したりするのにだいぶ時間を使ってしまいました。読み切ったあと冷静になって振り返ってみると、一つ一つの用語の細かな理解よりも、それぞれの繋がりをざっくり把握した上で全体を理解することの方が重要に感じました。

もちろんこの知識を実務で使う場合は、それぞれの課題に関してある程度理由をもって意思決定をしていく必要があるので、もう一歩細かな理解も必要になります。そういった場合は、この課題はここで議論してたなぁというのを思い出して再度その章を読み直したり、近い内容を議論している本を探してくれば、より実感がわいて理解が進みやすいと思います(この辺は、まだやっていないので完全に感覚で話ですが)。

結論

結論としては、ドメイン駆動設計はあまり神経質にならずに最初は理解できる範囲でざっくり読み切ることが重要だと思いました。課題を解決していく事例を流し読みするだけでもだいぶためになると思います。そもそもこの範囲の知識はソフトウェアエンジニアが一生をかけて補強し続けなければいけないものだと思うので、最初にざっと全容を理解しておけるだけでもだいぶ有益です。途中で散々用語がわかりにくいだなんだ言ってきましたが、本の中に登場する内容は絶対にいつか直面するだろうなと思えるものばかりでした。ソフトウェアの柔軟性や取り組むドメインに追従していくことに課題を感じているエンジニアはぜひ一度流し読みしてみてはいかがでしょうか。

DDD, プログラミング
comments powered by Disqus