天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

「エヴァンス本も読まずにドメイン駆動設計とは何事か?」に参加してきた

modeling-how-to-learn.connpass.com

今日はこちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

和智さんの発表

まずはEvans本翻訳者の和智さんから、Evans本に書いていないこと/書いていることについて発表がありました。

Evans本に書いていないこと

ビジネスモデルの構築やサービスデザイン

ビジネスをしらなきゃシステムは作れない、という話は書いてあるものの、ビジネスやサービスをどう作り上げていくか、という話は(もちろん大事だけど)Evans本には書いていないということでした。

システム設計, DB設計, 画面設計

あくまでもアプリケーション設計の話が書いてあって、インフラの話やネットワークとの関連の話は書いていないということでした。
DBの設計スキルや画面設計スキルは別の本で身に着ける必要がある(Evans本で身に着けたと思い込むより、身に着けられないと思って別の本を読んだ方が幸せになる)ということです。

サーバサイドプログラムや連携する複数システムをどう構成するかといったシステム設計のスキルも、他の本で身に着けた方が良いということでした。

要件定義, テスト, 運用, 開発プロセス

アジャイルなど、一部の考え方はもしかするとEvansと関連している部分があるかもしれないものの、あくまでも設計の話しかしていない(もっと言えば設計プロセスの話はしていない)ということでした。

ただし、Evansのホームページには、DDDを実践する際の開発プロセスの話が簡単に紹介されているということでした。

Evans本に書いていること

Evans本に書いていないことを読むと、Evans本は読む価値がない本だと思われそうですが、勿論そんなことはなくて、非常に価値がある本だと和智さんは考えているということです。
価値がある理由としては、普遍的な考え方がEvans本には書かれているという話を和智さんはされていました。
具体的には、拡張性や保守性を上げるために、部品をどのように作っていくのか?といった話や、ソフトウェアには業務知識を埋め反映さよう、といった話など、設計における普遍的な考え方が書かれているということでした。
Evansは野球のミットのような設計が大切だと話していたようで、ある面は固く、ある面は柔らかく設計をするんだ、という話をしていたそうです。

また、この話の流れで、古くから言えばMVCの考え方もEvansが大事にしている考え方の共通項があるという話もされていて、概念的な構造をそろえよう、という考え方が非常に深いレベルで書かれているという話がされていました。

Evans本談義

和智さんの講演の後は、和智さん増田さん佐藤さんかとじゅんさんの4人で、Evans本に関する談義が繰り広げられていました。以下、話されていた中で自分が印象的だったトピックを書いていきます。

Evans本の読み方

Evansいわく、第一部を読んだ後は第三部を読んで欲しいと話していたということです。*1
ただし、実態としてはこの読み方をしている人は少なく、第二部を中心に盛り上がりを見せているのは少し違和感があるということでした。(ドメインビジョン声明文などはEvans本にしっかり書いてあるのに、大体の人が読んでいない体感があるというお話でした)

また、Evansは言葉の曖昧さがかなりあるので、言葉の曖昧さを許容しながら読まないとかなりきついという話をしていきました。Evansも言葉の定義にはかなり苦労したのではないかという話も出ていて、言葉の粒度が前半と後半で大きく変わっているという指摘も上がっていました。

正直読みやすい本ではないという話で、増田さんは一ページ目から最後までを通し読みしたことはなく、一部の気になる部分を、何度も何度も繰り返すような読み方をしていると話していました。*2

また、和智さんの講演で出ていた「考え方が書いてある本だよ」という意識は大切だということで、ロラン・バルトの零度のエクリチュールにおけるエクリチュールの話が表現されているのがEvans本だという話も出ていました。

右派?左派?

和智さんは、Evansが提唱している概念と構造を揃えようという話は、変数レベルまで揃える必要はないと思っていると話していましたが、増田さんは、(過激派なので?笑)変数レベルまで拘らないといけないという話をされていました。

和智さんは、Evansが言っていることは本質的には変数レベルまで概念を揃えようという話だと思っているけれども、あくまでも考え方の本なので、Evans本を読んでパッケージレベルで概念が揃えられるように現場でなったならそれはそれでいいんじゃないかと考えているのが理由だということです。

増田さんは、パッケージレベルとかサブシステムレベルでEvansの考え方を実践するためには、Evansの考え方を深いところまで理解する必要があり、そのために変数レベルまで概念を揃えることを実践していると話していました。
増田さんは、世の中のDDDに対する考え方やEvans本の実践話を見ていると、「ユビキタス言語を実践してみました」くらいの浅い部分で理解が終わっている例が多いことに違和感を少し感じているということです。
そうした理解でEvans本が役立たないと思うくらいなら、深いところまで実践することで、抽象度が高いEvansの概念を理解して、現場で効果を実感したいという話をされていました。

和智さんと増田さんの協働経験

和智さんと増田さんは、一度一緒のプロジェクトで働いた経験があるということで、その時のエピソードが幾つか出ていました。

増田さんは、和智さんとのプロジェクトの経験からjigを開発されたということで、トップダウンとビルドアップの設計の往復(ただしビルドアップメイン)という今のスタイルが身についたということでした。

Evans本の概念が分からない時どうする?

登壇者の方からは、以下のような話が挙がっていました。

  • 増田さんの本と増田さんのブログを読む
  • Evans本の参考文献を読む
  • 分からない概念をキーワード検索して、理解を深める

会の感想

座談会という形で、Evans本を精読されている方の話が聴けて楽しかったです。
Evans本に限らず、登壇者の方々が読書を通してあるトピックに対して深い理解をしていく過程が垣間見えたのは、特に学びになりました。

*1:じゃあ今の三部を二部にしてくれよと思ったと和智さんが話されていました笑

*2:ただし、増田さんはまえがきとあとがきは丁寧に読んでいたということでした