増補改訂版 パーフェクト Ruby on Rails の感想

みんな読んでるパーフェクト Ruby on Railsを読みました。

パーフェクト Ruby on Rails 【増補改訂版】 (Perfect series)

• 作者:すがわらまさのり,前島真一,橋立友宏,五十嵐邦明,後藤優一
• 発売日: 2020/07/25
• メディア: 単行本（ソフトカバー）

9章くらいまでは流し読みです。以下個人的に面白かったところを書きます。

10章 コンテナを利用したRailsアプリケーション

Gemfileのimageレイヤのキャッシュのところ参考になりました。この方法なら多少imageのレイヤーは増えるものの、本体コードに変更があってもGemfileに変更がない時にimage build中にbundle installしなくてすみますね。*1

11章 複雑なドメインを表現する

値オブジェクト

Railsでの値オブジェクトの具体的な活用例がのっていました。composed_ofを業務で使ったことはないのですが、ファットモデルでもう限界だってなってから使ったほうが良さそうな手法だと思いました。Rails開発だとできるだけ要件削って値オブジェクトにロジックがそれほどないくらいにシンプルにしたほうが良い気がします。 値オブジェクトってもう型っぽいしJVM言語とかGo使ったほうがいいのでは。

サービスオブジェクト

何度実行しても結果整合性が取れる形にしたいですね（小並）

12章 複雑なユースケースを表現する

Railsにおける「レール」の正体と「レール」の限界と向き合い方という２つの節がよく言われる「Rails辛い」を言語化してあったのが良かったです。
Railsにおける「モデル」は「記事の投稿が完了したらメールを送信する」といったユースケースロジックと、「記事には投稿者がいる」といったドメインモデルが全部「モデル」に置けることが「レール」の正体であり、Railsの初期開発においてまずファットモデルが良い方向だとされる*2のもこのためだと思います。
よくフォームオブジェクトやプレゼンターがRails開発で用いられていますが、改めてユースケースをモデルから分離するための技法の一つだと言語化できるとモデルに書くべきロジックとフォームオブジェクトやプレゼンターに書くべきロジックの区別がつけやすくなるのではないでしょうか。 クリーンアーキテクチャやDDDの本は当然アーキテクチャの基本や考え方が中心になって話が進むのですが、パRailsはあくまでRails中心で話が進むので実務でも活かしやすい章だと思います。

13章 複雑なデータ操作を実装する

Concernがモデルに密接に結びつくのはまずい。最近そんなコードを書きました！！！！　すいませんでした！！！
自分は値オブジェクトとかサービスオブジェクトに分離する前にConcern化の方を先に考えていたので参考になりました。