Railsで導入してよかったデザインパターンと各クラスの役割について - masato_hiのブログ

3年ほどRailsを書いてきてある程度知見が溜まってきたので、忘れないためのメモとしてKPTと導入例を交えながらダラダラと書いています。 見出しの命名規則は クラス名/ディレクトリ名の単数形をupper camel caseにしたもの + KPT です。 Keepは今後も使うもの、Problemは開発規模によっては問題が発生する(した)もの、Tryは現在使用していないが使用したほうが良いと思っているものです。 これらすべてを導入すれば上手くいくというわけでもないので、開発規模に合わせて適切に採用していくと良いと思います。 DDDやデザインパターン等見聞きはしているものの詳しいわけではないので間違っている部分等あるとは思うのでその辺りはコメントでご指摘お願いします。 はてブコメント欄で頂いた指摘内容等についてはまとめの後でまとめて返答を記載しています。 Asset (Keep) app/as

[wwolf]

複雑な検索はfinderとしめまとめるのよさそう

[myun2-nw]

“Problem”

[kent-where-the-light-is]

“何をServiceとするかについては設計が難しい部分だとは思いますが、専門性の高い処理はほとんどここに配置することになると思います。”

[kayamak1]

“決済処理に失敗した、データ生成に失敗したというような重要度の高い例外については専用の例外を書く”

[takaesu]

モデルの肥大化を防ぐためのディレクトリ構成等参考になる

[Peranikov]

ParameterはControllerが受け取るparamsが複雑な時にラップするために作っていたな。Finderは良さそうだ。試してみたい。

[takuya_1st]

ふむー

[takeshiketa]

modelsをモデル層と捉えきれずStrutsぽくなってしまっている。

[takryou79]

デザインパターン

[pistachio0416]

まとまってて良い感じ。finderとかparameterとかだいたい似た考えっぽい

[seiunsky]

RuntimeErrorでええやんってマジすか、、、

[Kwappa]

よくまとまっている