DDD本読書会を完走した感想
みなさん、あけましておめでとうございます。
この記事はmohikanz Advent Calendar 2019の23日目の記事です。
クリスマスどころか年またいじゃってごめんなさい、mohikanzのアドベントカレンダーも3年目ですね。
この記事では、そのmohikanz参加者の有志で行われたオンライン読書会でDDD本を扱った話をします。
mohikanzとは？
当ブログにはときどき登場する、エンジニアの雑談Slackです。
2年前のアドベントカレンダー初日に良い記事が投稿されてるのでご査収ください。
すっかり有名人になった @inductor 氏が書いてくれてます。
オンライン読書会
オンライン読書会については、主催者の @gim_kondo さんが書いてくださっています。
忙しい人のために大雑把に説明すると、
- 毎週水曜日21:00開始
- 担当者は担当範囲を事前に資料にまとめておく
- Discordを使って集まり、資料に沿ってすすめる
- 途中で解釈をめぐって議論したり、実例に当てはめたりする
- 22:30くらいに終了
という感じです。これを5月から12月の半年強、ほぼ毎週続けてきました。
扱った本
タイトルのとおり、DDD本です。
Amazonレビューをいくつか拾い上げて抜粋してみると、
日本では、特にこの領域においてのリソースが不足している（頭数は居るけど、ちゃんと出来る人が居る印象が無い）ので、この本の内容をしっかり理解して進めればもっと日本のIT環境は良くなるはず。
設計を他人に説明、教えるのは、設計する事以上に難しい事だと思われる。ここまで体系的に踏み込んだ設計の本は他にないかと思われる。間違いなく良書。何周も読み返したい。
と絶賛されている一方で、
400ページも使って説明する内容ではなく、100ページぐらいの軽い読み物に纏まる内容。読み進めるうちに、飲み屋での酔っ払ったベテラン・プログラマの講釈みたいに、得る物と時間のコストが割に合わないと感じた。
この本が高評価されているのは集団催眠か情報商材詐欺か何かかあるいは悪い夢なのではないかと思う。
とメタメタにこき下ろされているなど、まあ毀誉褒貶の激しい本です。
僕の感想を端的に述べると
読書会で3人で読んだおかげで、苦痛度が3分の1になり得たものが3倍になった
です。
結婚式で聞くようなセリフですけど本当にそのとおりだったので、詳しく書いていきます。
- mohikanzとは？
- オンライン読書会
- 扱った本
- DDD本は読書会向き
- 苦痛度3分の1で得たものが3倍
- デメリットはあるか
- 得られたもの
- 「RailsとDDDは相性が悪い」
- 偉そうに語ってはみたものの
- まとめ
DDD本は読書会向き
先ほど「毀誉褒貶の激しい本」と書きましたが、読んでみるとまあ納得で、
- 鈍器（576ページ）
- 抽象的な内容で、具体例は挙げられるものの何が言いたいのかはわかりづらい
- 書き方も抽象的で、翻訳の苦労がしのばれる
と、一人で読み通すのは苦行じみていると言わざるを得ません。
一方で、
- ビジネスモデルを正確に捉え、ドメインエキスパートとコミュニケーションを取ることの重要性が繰り返し述べられている
- モデル駆動設計の概要とその構成要素、実装への落とし込み方が細かく書かれている
- ソフトウェアが運用に伴って大規模化したあとに設計を保つ方法までカバーされている
と、ソフトウェア設計に関して抽象化が難しいため、重要だがあまり語られることのない内容に紙幅がきちんと割かれており、他の本にはない知見が得られます。
要は、DDD本は「得られるものが大きいことはわかっているけど、ハードルが高いのもわかっているので手を出せない」タイプの本です。
「みんな読みたいけどハードルが高い」ということで、読書会には格好の題材だったのです。
苦痛度3分の1で得たものが3倍
実際、読書会を始めてみると、これが良いことづくめでした。
それぞれ、箇条書きで挙げてみます。
「本が分厚い」ことの苦痛が軽減される
- 精読するのは担当回のみでOKなので、単純に読む量が3分の1
- 読書会は毎週行われるので、週に2-30ページは確実に前に進む
「文章の意味が取りづらい」ことの苦痛が軽減され、誤解が減る
- 自分が資料を作る際には「人に見せる」という意識が働くため、中途半端な理解のまま前に進むことがない
- 自分が精読した箇所で、わからないところがあれば読書会に持っていって議論できる
- ひとりで読むと意味を取り違える場所も、精読した人の意見や議論によって正しく読める
抽象的な内容もきちんと理解できる
- 自分が精読した箇所はもちろん理解できるし、他の人の担当箇所もその場で理解できなければ質問できる
- 抽象的な内容に具体例を当てはめるディスカッションができるし、その過程で他の人の経験が聞ける
- 重要な内容は繰り返し述べられるので、時間をかけて読むことで徐々に脳みそにインストールされている感覚になる
と、「DDD本を読むときの最適解はこれではないか」と思えるほどの経験でした。
デメリットはあるか
単純に忙しくなること以外はないんじゃないでしょうか。
3週に1回ペースで担当が回ってきて、平日に時間が取れず土曜の午後をまるまる潰して準備するなんてこともありましたが、それだけの価値は確実にあると思います。
得られたもの
DDD本を読むうちに、要件定義や設計の仕事をする上で「ビジネスフローとサービスを一致させる」という明確な判断軸が生まれました。
また、コードを書いたりレビューしたりする際も「コードがドキュメントの代わりになるように、なるべく表明的に書かれているか」「ビジネス領域に即した適切な名付けがされているか」を軸にできるようになりました。
それから、ドメインビジョン声明文のようなものを整えて、サービスのコアを明確にするという業務上の目標が生まれました。
開発者としての自分のスタイルが全く見いだせていない中で、「守るべき基準」が自分の中にできたのは非常に大きい出来事だったと思います。
言ってみれば、守破離の守が生まれ、今後の経験をフィードバックする対象ができたのです。
DDD本はBtoBのSaaSを開発運用するという自分の仕事にカチリとはまったと思います。
あと、「Sandi Metz本」も並行して読んでたので相乗効果も確実にありました。
「RailsとDDDは相性が悪い」
普段はRailsで開発しているのですが、DDD本にふれる以上はこれについて言及しないといけないかな。
ここに
RailsはActiveRecordが密結合で実現しているためDDDのモデリングの考え方と相性が悪く、レイヤードアーキテクチャをやろうとすると型がないことなどDDDの考え方が適応しにくい
と書かれているように、確かにそのまま適用するのは難しいと思います。
モデルとデータマッピングオブジェクトが一致するような状況だと、ドメインが小さすぎてそもそもDDDをやる意味がなく、普通にRailsで作ってしまえば良いので。
ただ、DDDの「概念」がRailsで開発しているエンジニアに不要かと言われればそうではなく、
- ユビキタス言語の定義
- ビジネスルールをコードで明示するという考え方
- 表明的に記述することの価値
- エンティティと値オブジェクトを区別する考え方
- サービスクラスの扱い方
など、 長く利用するサービスを設計する上で役立つ概念が詰まっています。
特にBtoBで長くメンテされるサービスを扱っている人はRails製であっても読んでおくべきと思います。
偉そうに語ってはみたものの
参加者3人の中では自分の経験が一番浅く、一番学ばせてもらったと思います。
主宰のこんどうさん、顔の見えないオンライン読書会であることを意識してきちんと相槌を打ってくれたことでものすごく話しやすかったです。
参加者のshunさん、口数は最も少ないながら、指摘や解釈の切れ味は一番でした。勉強になりました。
どうもありがとうございました！
次の題材はすでに社内読書会で読んだ「徳丸本」とのことなので一旦参加はお休みしますが、次の題材に読みたい本が来たら是非に参加したいと思います。
まとめ
- 読書会でDDD本を扱ったが、非常に読書会向きの本だった
- 設計上の判断を行う際、自分が守るべき軸ができた
- Railsとの相性は悪いが、特にBtoBのサービスを開発する人は読んでおくべき
そんなわけで、みなさん今年もよろしくお願いします。
