「エリック・エヴァンスのドメイン駆動設計」と「ドメイン駆動設計入門 ボトムアップでわかる!ドメイン駆動設計の基本」を読んだ

読み終えたんす

元々、Clean Architectureを読んだ後に読むぞ〜〜!と思っていた本として、エリック・エヴァンスのドメイン駆動設計を想定しており。
ってことでReal World HTTPの後に(発売日を迎えてホヤホヤのモダン・ソフトウェアエンジニアリングを間にはさみつつ)、週末を中心に読み進めてたら5/23-6/16・・・と1ヵ月弱、なかなか苦戦しながら読み終えた。*1

また、「まずこの本を読んで、多分難しくて理解度が低いだろうから、間を置かずに次はコレを読もう」と決めていたのが 「ドメイン駆動設計入門 ボトムアップでわかる!ドメイン駆動設計の基本」。

ひるがえってコチラは、昨日読み始めてサクサクと進み。今日には終わったので、とても読みやすかった印象。
「こんなに日本語の本を読むのが遅くて大丈夫なのか自分。。」と凹みかけていたので、リハビリではないけど、読める本はちゃんと読めるんだな良かった!とも思った。

ということで、一段落したので #phpgenba のエピソードを復習しながら読書メモをまとめてみる。*2 php-genba.shin1x1.com

読んで見る順番としては個人的にはこれで良かった

最初にDDD本を読んだよ

最近は「まず原典にあたる」のが正しいスタンスかな〜という風に感じており、それもあって"まずは1番難しそうな"本から取り掛かった。
ということで、「エリック・エヴァンスのドメイン駆動設計」だ(長いので、以下「DDD本」)。

恐らく、「原典」が最初にあり(もしくはターニングポイントとなるくらいの爆発力をもたらしており)、その後に出た「解説書」「攻略本」というのは、その著者の大いなる編集力によって情報が微分&クローズアップしているものでは?と思っている。

当然ながら、その様な後発本が出るのは「オリジナルが難解だから」という何よりの証左だとは思うし、初手でそこに当たるのは高コストだなという風に感じる。

なので、目的としては「理解して血肉とする」や「高解像度なインプットを得る」という風に設定せずに、「地図を広げる」というところを意識している。具体的な道筋やどこにどんな建物が立っているか?までを正しく理解できる事は望まず、「なにをどこまで取り扱っているか、どのくらい風呂敷が広がっているか」の感覚を得られればOK〜というもの。
重要な概念はその登場頻度によって「感じる」ことができるし、朧げでも話の流れを追ったり逆に1発で理解できる箇所もあるかも知れない。そうやって、頭の中に薄いINDEXを作るようなイメージ。
(ちなみに、これによって出来ることの1つとして「索引を眺めるだけでも目に入る単語が増える」し「気になったページを読みに帰ることが出来る」というものがある。何となく、1回とりあえずクリアしたRPGのような感覚がある。行きたい町に好き勝手に戻れたり、取り逃したアイテムを回収しにダンジョンに戻ったりね)

これが、自分が「まず1回は原典を読んでみよう」というモチベーションを持っている理由だ。

実際に、今まで何となく耳にしたような言葉たちは「単語の定義としては」レベルで言えば説明を得ることが出来た。
ドメインモデル、ユビキタス、境界づけられたコンテキスト、値オブジェクトやエンティティ、知識の蒸留・・・これらに「耳馴染み」が出来た。

読み切るのに相応の時間を費やしたことになる。
が、ここ最近は「インプットに掛ける時間・量を大事にしていこう」と決めているので、多少コストが高かろうと意味の有りそうな順番を求めて読む本を決めていこう・・というのが自分の中では重要。

次にDDD入門を読んだよ

(実はかなり最初に買ってたんですよ)

その一方で、追っかけて読んだ「ドメイン駆動設計入門 ボトムアップでわかる!ドメイン駆動設計の基本」(長いので、以下「DDD入門」)については、やはり「物足りなさ」を感じるかなというのは正直な所。

が、決して「だから良い本ではなかった」というものではなく、寧ろ目的を履き違えなければ「見事な本だった!!」という感想。

何が「物足りなかった」かといえば、「ちゃんと削ぎ落としてる」という部分だ。
DDD本の難しさの1つはその抽象さにあるように感じており、それは「組織の形とコミュニケーション、コミュニケーションと実装、アジャイル開発やイテレーション」というとても広大な範囲を扱っている事に良く現れているように思う。・・これをワンストップで解決しようという「DDD」のコンセプトはやっぱマジやべぇな、となるのだが。

一方で、DDD入門はこの「難しさ」に立ち向かった。自分の感覚では、極めて「コードに近い位置」に軸足を置きながら話してくれているのがこの本の「優しさ*3」だ。
DDD本は「どうモデリングしていくか」という点に常に脳みそのリソースを30%以上喰われている感覚があったが、DDD入門は基本的に「どういうコードになるのか」に終始しているのではないか。

本書中で「ボトムアップドメイン駆動設計」という概念に触れており、まさに「"具体"や"卑近"から、着実に一歩ずつ積み上げていく」という読書体験に近い。

本書のアプローチもまたボトムアップです。ドメイン駆動設計の構成する要素のうち、もっとも根底にあるものからひとつひとつ解説してきました。そして、その解説自体も、トップダウンにそれが何であるかを紹介するのではなく、必ずそこにある問題を提示し、紐解く作業を添えています。本書はドメイン駆動設計のパターンを伝えると同時に、その実践の手本として、新たな知識との向き合い方を伝えているのです。ある知識を得るために、前提となる知識が必要となることは多くあります。なるほど知識は連鎖するものです。ボトムアップに知識を積み上げていけば、必ずや理解へ到達することでしょう。

成瀬 允宣. ドメイン駆動設計入門 ボトムアップでわかる!ドメイン駆動設計の基本 (Japanese Edition) (Kindle の位置No.5427-5432). Kindle 版.

あるいは、「はじめに」から引用すると「モデリングはいったんさておき」というスタンスだ。

そこで本書はモデリングについてはいったん棚上げにして、具体的なコードをベースにパターンを集中的に解説し、全体を通して最終的なコードを提示します。どこかへ行こうとするとき、目的地がわからないということはとても不安を覚えます。本書が提示するコードは明確な形をもった目的地としてあなたの道しるべになるものです。

成瀬 允宣. ドメイン駆動設計入門 ボトムアップでわかる!ドメイン駆動設計の基本 (Japanese Edition) (Kindle の位置No.49-52). Kindle 版.

DDD入門はどんな本でした?

まずは「読みやすい」本だなぁ〜(ありがたい〜〜〜!!!!)という感想。
他方で、全く未学習の状態からこの一冊で「DDDは何かという肌感を掴めるか」というと少し不足があるかも知れない。

「なぜDDDをするのか」という部分、第1章で取り扱っている内容が「軽い」かも?と思ってしまった。・・・これはDDD本を先に読んだから、かも知れないけれど。
そういう意味では性急に「本題」に入ってしまっているのか?とも。それによって「抽象的でわけが分かりにくい話」を掻っ捌けているので、一冊の本としてのバランスは良いなぁ〜と感じているのだけど。
その辺りは、何か別の文献(web上に「DDD入門」みたいなものがあるかも知れない。探してみると。)で補ってからこの本に入る、という準備が出来るといいのかな〜

視点を変えて、「どういう人が読むといいか」「読むことでどういうことが期待できるか」という点。

前者については、自分のように「DDD本をとりあえず読んでは見たものの」もしくは「読もうとしたけど挫折した人」などはまさに。その他には、「DDDというものに向き合う必要が出てきている、が、いまいち理解できていない・・・」という人など。 難しい単語たちを優しく説明してくれてるのは間違いないので。

後者の方に関して言えば、「とりあえずDDDで書かれたコードを読めるようになる」というゴールが近いように思う。「自身が先導してDDDを導入したり土台のデザインをする訳ではないが、チームとしてDDDを採用しているメンバー」などはドンピシャなのではないだろうか。明日から働きやすくなるんじゃない・・・?って気がする。

例えば目次を見てみると、この本が「いかに具体的・現場的な問題を取り扱っているか」という意志が匂ってくるのではないか。
特に端的に顕れている(と感じる)前半部分の章立てを引用する。

  1. ドメイン駆動設計とは
  2. システム固有の値を表現する「値オブジェクト」
  3. ライフサイクルのあるオブジェクト「エンティティ」
  4. 不自然さを解決する「ドメインサービス」
  5. データにまつわる処理を分離する「リポジトリ
  6. ユースケースを実現する「アプリケーションサービス」
  7. 柔軟性をもたらす依存関係のコントロール

すごくないですか、「モデリング」や「コミュニケーション」から焦点を外したDDDの解説は、こんなにも足早に実装的な話に入れる・・・・DDD本だと「値オブジェクト」「エンティティ」を主題として取り扱うのは、第2部:第5章「ソフトウェアで表現されたモデル」まで時間を要しているというのに!

このアプローチの違いから、「自分自身が率先してDDDをやっていくという立場」には不足でも「DDDを採用している現場のいちメンバー」に薦めるには充分に有用性があるな〜と感じる次第。ゼロからデザインをするのは厳しかったとしても、他の人のコードを読みとったりソコに乗っかってコードを書いたりはできそう、という印象。

良い塩梅だったなぁ〜〜〜と思った。

読了後に読んだ筆者の「あとがき」を見ると「どういう本か」は伝わってくる気がする。

nrslib.com

あとはなんだろう、コードがC#だけどソコは自分的には全く問題なかった。
変に擬似コードを使うよりは(実世界のコードだし)洗練されているから良いし、本書に出てくるサンプル程度であれば言語の癖みたいなのも感じることはなく「オブジェクト指向だと大体こういう雰囲気じゃんね」というノリで読めたという感じ。

DDD本は難しかったネ^^

読むのに骨が折れた!読みにくくない??そうでもないのかな・・

やはりDDDに関しての肌感みたいなのを持っていない状態で挑戦するには強敵だな、と。
とはいえ、これで世の中にあるドメインが〜とかユビキタス言語って〜みたいな議論に付いていける土壌を耕せたと思えば、非常に価値があるコストだったと感じている。スタート地点に立てたはず・・・

もちろん、全くわからない!!何もわからない!!と終始叫びながら900ページ弱を読んだわけではないので、新しい知識もそれなりに入ってきたつもり。

  • 今まで「ドメインモデルを隔離するって一体なに??」という状態だったのが、言わんとしている事が分かった気がする
    • Clean Architecture(もとい、フレームワークやインフラ層を「些細なこと」として扱うような態度)での「本当に守りたいものは何か」を記述していくとこうなるのか、という感じ
    • これらについては、徹底的な(実装パターンとしての)DDDを採用しなかったとしても、着眼点として持っておくことは出来そうに感じた
      • 例えば仕様の隔離や誰がどんな責務を持つか、制御の流れをどうするか?など
      • DDDというかOOPで達成されるべきことについて、自分の中での練度が上がったかも知れない(勘違いの可能性もある^^)
  • 先行して概念だけ(何となく)知っていた「ユビキタス言語」、それ自体とても便利そうなもの〜という認識だったが、「ここまで徹底的にやるのか」といった感じで、確かにそうすると抜群に効果が出そうだな・・・という気がした
    • 例えば何かのIssueやPRのdescriptionを埋める時、もしくはインラインコメントを書いたりレビューをしたりする際の思考態度が変わる
  • アナリシスパターン is 何・・・
    • これはまた何か本を読んで知識を蓄えた方が良いのだろうか
    • もしくは、これに限らず「どう分析してモデリングしていくか」みたいな技法は知りたいと感じる。アナリスト的な機能なのかな、と思うが。
      • それらを無くして「どういう風にしたら良い設計たり得るか」については語れないのでは、、、、、という気がした
  • しなやかな設計 はメチャクチャ良い概念、好きぃって思った

↓ 好きだなぁと思った箇所。リファクタについて

  1. 困った時のリファクタリングをする際に、原因がコアドメインかコアと補助的要素との関係を含むものかどうかを調べる。そうであれば、歯を食いしばって、まずそれを修正すること。
  2. 自由にリファクタリングする余裕がある場合、最初に集中すべきなのは、コアドメインのより適切な括り出し、コアの隔離の改善、補助的なサブドメインから不純物を取り除くことによる汎用サブドメイン化である。

Eric Evans. エリック・エヴァンスのドメイン駆動設計 (Japanese Edition) (Kindle の位置No.8807-8810). Kindle 版.

(DDDに限らず)往々にして、「リファクタをすべきか、そのままでいいか」「どうしたら成功するか」みたいなのは判断が難しい所。
カッとなってやった!!!という時にコードを書く瞬発力は上がると思っているが、気分駆動でやった問題は精度の面でブレが怖い。「時間取ってリファクタしてみたけど結局なにも良くなってないじゃん」というのは良くあるし、「よく出来ると思ったけど挫折した」も同等かソレ以上にあること。
なので「何故やるべきか」の尺度はあるに越したこと無いよね〜!と感じる。

アーキテクチャは方針」であるのだから、設計思想やパターンに密接に関わっているDDDの目指すものが、自ずと「リファクタリングかくあるべき」と語り始めるのはとても自然なことだなぁと感じる。

この後どうする?

まだまだ「薄く広く、全体的なINDEXを作ってみた状態」だと思っている。なので、この後には「脳みそのシナプスをつなげる」「より具体-抽象を結びつけながら、自身の持つ解像度を上げていく」ことが必要だという感じ。
とはいえ、概念的な部分についてはDDD本が一通り抑えてくれているだろうな・・という信頼はあるので、あとは「馴染んでいく」という部分だ。

DDD本が難しかったのは「もう少し具体例・実践例を知りたい」という所があり、あと「会計がさも分かりやすそうな例として取り上げられてるけどあんまり馴染みがなくて・・」「流通もゴメンナサイ・・・」という気がしたので、より実践的な話に触れてみたいと感じている。

ということで、これを読んで見る。

実践ドメイン駆動設計

実践ドメイン駆動設計

高いなぁ買うの日和ってたんだけど。2冊読み終わった勢いでポチったので・・・・・

なんとなく「1度読んだ本」はその後も行き来してパラパラと開きやすい気がするので、実践DDDを読みながらリファレンスとしてエリック・エヴァンス先生にもお話を伺いに行こうかな。

あとは、少し自分でも手を動かしてみたいよな〜。MVC&ActiveRecordなFWとも組み合わせられるかな?
CakePHP4を用いてDDDの実践、みたいなのをやってみたい気はする。

例えばshin1x1さんのサンプルを見た時、とても「cake的じゃない」と感じた記憶があるのだが、今見たらもう少し深く理解できそうかも知れない。
(とはいえ、今のところはやっぱり「折角cakeでやる旨味」みたいなものが薄そうかな〜という印象は持っている。コレが喰わず嫌いでしかないのか?は確かめてみたい。)

github.com

あとでよむ

少し復習してみましょう、くらいのノリで読みたい nrslib.com

*1:別のこの間の週末を全てこの一冊に費やしていたわけではなく、並行して読み進めている本があったり、趣味コードを書いたり諸々もあったんですよ!!という言い訳

*2:当日は会場で聞いていたが、壁の裏から漏れ聞こえてくるうずらさんの存在感が凄かったのを思い出す度に笑ってしまう

*3:「易」ではなくて