書評『現場で役立つシステム設計の原則』

下記の本のレビュー記事。

 

現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法

現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法

  • 作者: 増田亨
  • 出版社/メーカー: 技術評論社
  • 発売日: 2017/07/05
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログを見る
 

 

内容

特定の理論や手法を説明したものではなく、それらをどのように組み合わせていけば、変更が楽で品質の高いシステムを開発できるのか、って問いに答えるオブジェクト指向アプリケーション開発の秘伝の書。

基盤となっているのは

  • ドメイン駆動設計
  • Thoutworks流のオブジェクト指向開発(マイクロサービスアーキテクチャ含む)
  • XP(エクストリームプログラミング)
  • データモデリング(リレーショナルモデル)

あたり

 

感想

最初の雑感

とにかく様々なことを勉強した上で、現場の実践で考え抜かれ、蒸留されたノウハウが詰め込まれている。ありがとうございます、としかいいようがない。本当に使えるノウハウが体系的に整理されている。

教育コンテンツとしても完成度がめちゃめちゃ高い。前提知識をほとんど要求しないので、Javaなどの静的オブジェクト指向言語とデータベースの入門書レベルをしっかり理解している人ならそれなりに理解できるように記述されている。語られている範囲が広いのに、ボリュームも少なく、頭に自然に入ってくる。これは驚異的。相当推敲を繰り返したんではないか。

古い設計理論や開発プロセスも踏まえて語られているので、昔ながらのSIの現場にも伝わる内容になっている。そして、伝統的なやり方がなぜだめなのか、どうすればうまくいくのか、がしっかりと書かれている。あとは現場で考えてね!で逃げないのって本当にすごく難易度が高い。

 

誰向けか

若手~ベテランまで広くお勧め。そして、SIのマネジメント層に読んでほしい。

 

ドメイン駆動設計との関係

エヴァンスのドメイン駆動設計にある、Entity(エンティティ)やAggregate(集約)みたいな重要なものが語られていない。これは、実は重要でない、というか、意識して作らなくてもいいんでないか、という主張なのではないか、と自分は思っている。エヴァンズのドメイン駆動設計のアップデート。だから、エヴァンのドメイン駆動設計を知りたかったら、やっぱり原典に当たったほうが良いかと思う。

エリック・エヴァンスのドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計

  • 作者: Eric Evans
  • 出版社/メーカー: 翔泳社
  • 発売日: 2013/11/20
  • メディア: Kindle版
  • この商品を含むブログ (7件) を見る
 

 

プロセス

アジャイルのような反復開発でどのように開発を進めていくのか、ということも書かれている。重要なところに当たりをつけて部品を作っていって全体をくみ上げるってのがオブジェクト指向開発、とな。。こういうのが明確に語られている本は記憶にないなあ。

そして、これはScrumみたいのを形式的に適用したらオブジェクト指向開発はうまくいかないってことになるんだよね。バックログがPO任せだと、POのやりたいことが順番に降ってくるだけ。ウォーターフォールと大差なくなってしまう。

 

画面とデータベースに真っ向から取り組んでいるのがいい

従来の教科書的なオブジェクト指向設計の話だと画面設計やデータベース設計と絡めて語られることがほとんどなくて、現場で一番苦労するのがそこだったりするので、

「オブジェクト指向使えない」

みたいなことになってたような気がする。

この本では、画面とデータベースという、コードを汚くする2大源泉に真っ向から取り組んで、成功しているように思える。そのブレークスルーの源は「ドメインオブジェクトの主役は値オブジェクトのようなスモールオブジェクト」って洞察だと思う。

 

読んでなるほどーと思ったとこ
  • 画面は利用者の関心事(ドメイン)を反映してるって視点。
  • ドメインモデルとデータモデルの本質的なミスマッチ
  • 業務マニュアルを初期から作っていく

なんとなくもやもやしてたけど、明確になった。

 

まだもやもやしているとこ
  • 小さいWebAPI→性能大丈夫か??
  • メッセージ文字列をドメインオブジェクトに直書き→国際化とかは?メッセージ一覧ほしくならないのかな?
書いてないけど、書かなくていいと思っていること
  • フレームワークとか、下回り(Radisとか)の話
  • 非機能面(性能とか)の対処→疎結合、高凝集の構造だと問題起こっても何とかしやすいからね。

 

書いてほしかったこと
  • テスト→多分、ユニットテストの重要性は小さくなっているはず。メンテもつらいし。開発の中でどうテストし、モデルの成長に合わせてメンテしていくのか、って話をちょっとだけでも書いてほしかった。