🚃 直近触っているRailsの諸々まとめ

Fat Model/Controller問題

そもそもなぜ問題か？問題なのか？

ControllerでHTTPリクエストを受けて、アプリケーションの入口・出口を担う

Modelでドメイン知識・業務ルールを表現する

単純にこの辺りが崩壊していく。読みづらい。

Model

特にこの辺りは全部一箇所に書くことになる。

永続化（ORM）

ドメインロジック

ライフサイクル制御

いつ何が起きるのかが、呼び出し側から追えない

副作用が暗黙に増える

決定的なものなら大丈夫。自分のクラスの特定のカラムに値を入れる計算をするなど

他クラスに影響が出るのは望ましくない

DBテーブル操作クラスに全知識を押し込んでいる状態になりがち。

使ってみたGem：trailblazer

こちらはコントローラーで特定の処理がいくつか呼ばれるみたいな現象を防ぐために使った。

RailsのMVCの外側に ユースケース層 を置く構成になった。concepts。

step単位で何しているか分かったから管理しやすかった

特定の処理をまとめておけるからテストがしやすかった

コントローラー全体の結合テストではなく、特定の処理の（operations）単位で書けた

例えばUserクラスに権限処理を書いているところもあると思うが、これをアーキテクチャの単位で分けれる

使ってみたデザインパターン：Repositoryパターン

外部ストレージへのアクセスを切り出した。本体→利用側のアプリという構造の中で、本体側のデータを出した。

DDDの場合の永続化を隠蔽する考えそのものを使ったというより、永続化しているものを取得する部分を隠蔽。

R/WのRの部分だけ活用。

api gateway pattern と呼ばれるものに近いかも