素のRailsは十分に豊かである（翻訳）｜TechRacho by BPS株式会社

はじめに 「Railsは関心の分離が不十分である」という批判をよく目にします。状況が深刻になったら、Railsに足りない別のピースを導入しなければならないというのです。しかし私たちはそうは思いません。 「素のRails（vanilla Rails1）ではここまでしかできない」みたいな批判を耳にすることがよくあります。Railsはアーキテクチャレベルで関心の分離が不十分なのだから、アプリはいずれメンテナンス不能になり、足りないピースを導入するという別のアプローチが必要になるというのです。 代表的なDDD（ドメイン駆動開発）書籍では、概念上の4つの層である「プレゼンテーション層」「アプリケーション層」「ドメイン層」「インフラストラクチャ層」について議論しています。 アプリケーション層は、ドメイン層と協調動作してビジネスタスクを実装します。しかし、Railsが提供しているのは「コントローラ」と「

[nemoba]

DDDの良さは「記録自信がコピーする」って変じゃねって考え直したこと。ドメインモデルの精錬のため他の歪みを許すか。ドメインモデルに歪みまとめちゃうかのそれだけ。

[snobsnog]

素を妻と誤読してしまい、プログラマ奥さんの話か〜と思ったら違った

[fuyu77]

Service Objectを使わない設計手法について詳しく書いてあって参考になる。リッチなドメインモデルの志向は良さそう。そこそこ高度なので開発チーム皆で目線を揃えるのにちょっとハードルありそうだが。

[tkmkg8m]

サービスと名の付いた単なる手続き集がアレで、概念抽出してPOROを app/models に置けばいいよねってのは同意。とはいえBasecampの include 地獄なコードは違う意味で保守性低いと思うよ。

[YassLab]

"「新規登録」というドメイン操作を担当する SigningUpServiceではなく、アプリでIDを検証して作成できるSignupクラスを用意する / Rubyによる純粋なオブジェクト指向そのものが、ドメインの概念をコードで適切に表現している"

[bopperjp]

要はオブジェクトを、「Service」だの「Command」だの「Interactor」だのに分類しないと管理できないような構成は、設計から逃げてるってこと？それをチーム全体で共有できるのは賢い集団だけじゃね？

[deeeki]

“私たちのアプリのapp/models/フォルダには多くのPOROが配置されています”

[nunulk]

"私たちの方法には、Railsドクトリンの柱の1つである「パラダイムを1つに絞らない（No one paradigm）」が反映されています。"

[mopin]

"そうしたクラスを「操作を呼び出すために単なる手続き的構文を使う」ためではなく、「必要とされる機能を公開するドメインモデルとして示す」ことを好んでいます。"

[programmablekinoko]

だってBasecampの人が自社の問題解決のために作ったんだもんな

[konk303]

rails ddd

[razokulover]

みてる

[arx0balest]

余計なことしなくていいから（良心）型無し糞言語は早く滅んでくれ。もう役目は十分終えたんだよ。よくがんばったね。もう休んで。害悪でしかないから。社会的損失が大きすぎるんだよ。

[iga_k]

serviceよりも app/models に PORO