modeling-how-to-learn.connpass.com
こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
会の前提
最初に会で話す内容についての前提について話がありました。
- ドメインモデルを用いた設計について頻繁に議論しており、4人の中ではかなりコンテキストが共有されている(コンテキストを省いて座談会をしてしまう可能性がある)
- 普遍的な設計の話をするつもりだが、言語はJavaを用いているので、Javaの概念が前提になっている可能性がある。
会で印象的だったこと
凝集度の捉え方の違い
トランザクションスクリプトは、リクエストベースで捉えると凝集度が高いように感じられますが、ドメインモデルの視点で捉えるとあちらこちらに業務ロジックが進んでいて凝集度が低いように感じられてしまうという話がありました。
トランザクションスクリプトからドメインモデルへの発想の転換が難しくなる原因の一つとして捉えることができて、面白かったです。
ドメインモデルが実践できないパターン
ドメインモデルが実践できない現場を見ていると、
の3パターンがあるというお話を聞いていきました。
「ドメインモデルに関する知識がない」場合は知識を教えればよくて、「ドメインモデルに関する知識はあるが、実践できない」場合はIDEの活用方法(ドメインモデルに必要なコーディングを素早く行うためのテクニック)を教えたりすれば良いということでしたが、「ドメインモデルの知識もあるし実践もできるが、やっていない」場合だけはどうしたものか分からないということでした。
実際にコードを書いて見せればドメインモデルのキャッチアップが進む？
一からドメインモデルを書いていくというのは難しいけれど、すでにコードベースがあったり、わかる人がコードベースを作ってあげれば雰囲気を掴んで書けるようになるのでは？という問いかけがあったのですが、実際の所コードベースがあってもなかなか馴染める人は少ないようお話が出ていました。
また、雰囲気だけ掴んで何となく書けるようになったけど本質は理解できていないので、クラスの書き方とかがドメインモデルっぽくなっても、ロジックが散らばりだしたりとあまりドメインモデルの恩恵を受けられていないコードになってしまうという話が出ていました。
トランザクションスクリプトが選ばれやすい理由
ドメインモデルの恩恵がなかなか分かってもらいにくいという話を受けて、高崎さんから「逆にトランザクションスクリプトが選ばれる理由は何だと思うか？」という問いかけがされました。以下、話で出ていた要素を箇条書きで挙げていきます。
- トランザクションスクリプトの方が直感的で、処理の遷移がわかりやすい
- 要件が決まっていると、拡張性や変更容易性の価値が分かりにくいので、作りやすいトランザクションスクリプトが選ばれる
- 作りっぱなしで運用保守をしない前提だと、トランザクションスクリプトの方が早く作れるのでトランザクションスクリプトが選ばれる
増田さんが感じるドメインモデルに対する周囲の温度感の変化
増田さんがドメインモデルに注目し出したのは2008年だということですが、その際には本当に周りからは相手にされず、ブログで独り言を書いているような感覚だったということです。
その後、コミュニティ活動をしていく中で理解をしてくれる人が現れ出して、2013年に本の出版の話をもらうまでになったということでした。
ただ、スタートアップの人たちは本を出版して注目をしてくれた一方、SIerの人たちからは「面白いけど実践は難しい」という感想が殆どだったということで、SIerの人たちからも賛同を得られるようになったのはここ最近の話だと増田さんは感じているようです。*1
ドメインモデルにまず落とすところ
ドメインモデルを実践しようと思ったもののまずはどこからやればいいのか分からないという場合には、金額や小数点の切り上げ、日付などのロジックをカプセル化して、value objectを積極的に作っていくと良いという話が出ていました。
Kent beckのテスト駆動開発で語られている例がMoneyだったこともあって、納得感があ理ました。
ロジック化と自己文書化のバランス
アクティアの方々は、元々はドメインモデルの自己文書化に重心を置いていたということで、業務ロジックがないものでもValue objectをどんどん作っていたようですが*2、今は業務ロジックがないものはvalue objectにしていないということです。
自己文書化に振り切った結果どのような姿になるのか、という話の一端が聞けて面白かったです。
業務に目を向ける人とプログラミングに目を向ける人
ドメインモデルを実践するにあたっては業務知識も必須で、業務に興味を持てることも重要ですが、エンジニアはなかなか業務よりもプログラミングに興味を持つ人が多いし、業務知識を持っているマネージャー層の人はプログラミングはできないというし、中々両立させるのは難しいのかもしれない、という話が出ていました。
SIerでも自社開発でもこの傾向ははっきりあるということですが、増田さんの観測範囲では、業務知識を持っている人がドメインモデルを用いたプログラミングに取り組み出す例は見たことがないようで、プログラミングが好きな人が、より良いプログラミング方法を探究していく中でドメインモデルに目覚めるパターンしか見たことがないということでした。(ただし、この結果を良いとは思ってはおらず、業務知識を持っている人がドメインモデルを用いたプログラミングに興味を持つパターンも探求していきたいと話がありました)
プログラミングが好きな人がドメインモデルに目覚めて業務知識をつけていくパターンに至るまでの過程
トランザクションスクリプトのリファクタリングをしていく中で、パッケージ構成の整理を話すタイミングが出てきて、その中でわかりやすいパッケージ構造に興味が湧き、パッケージ整理をするために自然とドメインの知識をつけ始めるというパターンが挙げられていました。
また、パッケージ構成については、ツリー構造に捉われなくなり出すと、一段上のステップに進んでいる感覚があるということです。
全体を通した感想
今回は普段の増田さんのイベントよりも座談会の比重が重かったのもあったのか、いつも以上に現場のリアルな話が聞けたのがよかったです。
普段はもうちょっと座談会聞きたい。。と思うこともあるのですが、今日はお腹いっぱいになるまで話を聞けました！
個人的には綺麗な話よりも現場のドロドロした話を求めているので、大満足でした。
