Railsを学習していて発生した素朴な疑問、 RailsでDDDってどうなの？そもそもRailsってどんなフレームワーク？ に対して自分なりに納得できるよう調査したので記録しておきます。
RailsでDDDってどうなの？
DDDって何？
聞いたこともない、という方はこちら
一般にクリーンアーキテクチャとかに相性がいいとされるこのDDD。完全に思想通りと言わずとも（そもそも完全に思想を理解していない）、エンティティを中心に開発するとDBの都合とロジック側の都合とがいい感じに折衝されて、アサインされたプロジェクトに採用されているとちょっと嬉しい設計思想。
完全に理解したい人はエリック・エヴァンスのドメイン駆動設計を読んでください。私もいつか読みます。
データモデリングと両立する？
データモデリングは、プログラムレベルで業務に従ったドメインを設定することとは両立するという認識です。（参考記事）
（モデリングによっては、データモデルとドメインが一致する場合もあると思います。）
プログラマから見た「DDDにしたい」欲求は「DBを意識せずドメインを意識したコントローラー実装がしたい」欲求、というイメージなのかと思います。（著しく間違っていたら教えてください）
RailsとDDDの相性は？
結論から言うと、RailsとDDDの相性はあまり良くないみたいです。
DDDに従うということは、ドメインに依存した設計になる、ということであり、つまり依存方向がどの入出力からもドメインに向く、ということだと解釈できると思います。これはDBに依存しない「疎結合」な設計と言えます。（クリーンアーキテクチャっぽい説明ですが）
一方で、Railsの設計思想は、Rails作者のインタビュー（日本語訳）からもわかるとおり、「早くてキレイ」 を目指す代わりに 「インフラレベルの柔軟性を犠牲に」 しています。これは具体的にはDBとActive Record(Model)が対になっており、Controllerから直接Modelを呼び出す方法論までが明確に筋道立てられていることを指すと言えるかと思います。これは結果的に密結合 になってしまっていると言えます。
ですから、Railsの設計に反さずにDDDを取り入れたいのであれば、実装を簡易化するRailsの道筋から外れずにいつの間にかドメインに従っている 状態にしなければならなそうです。うーん、難しい。
RailsでDDDを実現できないか検討している方はたくさんいらっしゃるのですが、こちらの方のやり方が個人的にはRailsの流れにも沿って自然な感じがしました。取り入れるならこの方法を採用したいです。
Railsは「Rail」に従うと効果を最大限発揮できるフレームワーク（Laravelとの比較）
今回DDDをテーマにRailsについて調査してみてLaravelと比べる場面が多かったのですが、やはりRailsの哲学に鑑みても開発方法を絞ったフレームワークと言えると思います。
Laravelが様々な開発手法に対応しようとしているのに対し、Railsはただ一つの最善の方法を追求しようとしています。
やはりRailsの思想に合う開発はRailsで、それ以外（大規模開発、DDD等）は無理をせず他のフレームワークで（Hanamaiの方が柔軟性高いっぽい、PHPでいうSlimに近いのかな？）、という割り切りが大事なのかと感じました。