Ruby/RailsのWebアプリケーションはドメイン駆動設計を当てはめることができないのでmastodonのような設計方針にする

Ruby/Railsはinterfaceキーワードがないため、JavaやC#のようなinterfaceクラスを定義することができないが、Duck Typingという概念により楽しいを優先した実装が可能になっている。

かといってRuby/Railsのフレームワークに全てを託してMVCを構築して密結合なソースコード、ディレクトリ構成になると後々きつい。

ドメイン駆動設計の実践的ソースコードとしてはそれを実践している企業のソースコードをみたらめちゃくちゃ勉強になるけど、できない場合はCargo Trackerを読むと良い。

エリック・エヴァンスのドメイン駆動設計を読んでいると途中でCargo Trackerのドメインを例に説明している箇所が出てくるのでJavaで実装されているCargo Trackerのソースコードを読んで、概念を具象に置き換えて読むことができる。

Railsをドメイン駆動設計で設計をするとなぜRailsを選択したのかがわからない設計方針になってしまうため、Railsでドメイン駆動設計を実践している企業はあまりないはずだ。

mastodonはMVCを基本構成としていながらModelには基本メソッドを用意し、Serviceに業務ロジックを書いている。Serviceに書かれたロジックをModelが呼び出しているため、Modelがファットにならない。

Railsのようなフレームワークと結婚をする場合はクリーンアーキテクチャやドメイン駆動設計を当てはめることはほぼないだろうが、MVCをService、Policy、Form、Query、Concernsで上手くバラす。

ドメイン駆動設計でいうエンティティとリポジトリはModel、複雑なクエリはQueryオブジェクトに分離される。

Policyは権限制御。Formは複数モデルを使用する場合のPORO。Concernsは複数モデルで共有してもよい小さい処理などを入れる。