#現場で役立つシステム設計の原則 の読書会をしました

はじめに

現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法 を使って、中途入社の研修として読書会をしました。

11月中に終わったので、まとめておこうと思います。

やってたこと

参加者は私と中途入社の2人だけに限定して、毎日空いている1時間を見つけて開催してました。 進め方は、電子版のpdfをモニタに映しつつ、1時間で進められるとこまで進めていくようにしました。

第1章　小さくまとめてわかりやすくする

第2章　場合分けのロジックを整理する

第3章　業務ロジックをわかりやすく整理する

コードのサンプルがJavaだったので、Scalaだとこう書けるよとか、PHPだとこれが出来ないからツライとか、プロダクションコードがこうなっているのはこの考えだからだよとか、実際のコードを見ながら説明をしていたりしてました。

第4章　ドメインモデルの考え方で設計する

第5章　アプリケーション機能を組み立てる

ドメインオブジェクトを成長させていくには、業務理解と併せてやっていかないといけないから、分析、設計、開発が別れてるようなプロジェクトだと無理だけど、今のプロジェクトはそうじゃないんだよということも伝えていました。

また、プロダクションコードでイケてない部分も見せながら、この考えを参考にしながら改善していきたいというのも併せて伝えました。

第6章　データベースの設計とドメインオブジェクト

データ分析の部署なので、データベースに関する箇所を厚くしたら、盛り込みすぎてしまいました。

紹介したのは、以下の資料です。

イミュータブルデータモデルや有効時間データモデルについては、実際にプロダクションで採用するとこうなるんだよという例を見せながら説明すると、納得していたように見えました。

CQRS + ESについては、少なくともCommandとQueryを分けると責務もはっきりするし、参照が多いレポジトリのクラスがいろいろ巻き込んで肥大化するのを避けることが出来るという自分の考えも伝えていました。

第7章　画面とドメインオブジェクトの設計を連動させる

第8章　アプリケーション間の連携

プレゼンテーション層については、今のプロダクションコードを見つつ、PHPのテンプレートに埋め込む部分と、Angular側に任せる部分と、APIとして何をレスポンスを返すのがいいかを、過去の経緯と今の考えを踏まえつつ説明してました。

RESTをどこまで厳密にやるのが今のプロジェクトにあってるのか、あってるとしたらどのドメインのコンテキストなのかを一緒に考えながら、話し合っていました。

興味を持っているGraphQLについてや、Akkaだとメッセージ基盤も内包してることを紹介してたりしてました。

第9章　オブジェクト指向の開発プロセス

SIerあるあるネタがお互いに出てきたので、どこも今もあんま変わってないんだなと思いました。

第10章　オブジェクト指向設計の学び方と教え方

オブジェクト指向エクササイズについては、麻疹にかかるように一度やり過ぎるくらいにやってから、現場でどこまで適用するのがいいのか考える必要があることを伝えていました。

最後の回では、「現場で役立つシステム設計の原則」批判 (1) ～何のために、「データとロジックを一体に」するのか？～ や「現場で役立つシステム設計の原則」批判 (2) ～ポリモーフィズムは何のために？～ を紹介しつつ、プロダクションコードの中の似たような箇所を見せつつ、どうしたらいいか自分なりの考えを出してもらいました。

おわりに

今のプロダクションコードを見ながら、この本で指摘されている内容と照らし合わせていくと、 自分自身の振り返りも出来たので、こういった機会を定期的に設けるのはありなのかもしれないと思いました。