Ddd_In_Rails_Way

RailsでDDDを実現する

前提

DDD とは

Rails(主にAR) と DDD は相性が悪い

• Active Record モデルをドメインモデルとして扱う問題点
  • テストしづらい
    • 純粋なドメインロジックのテストがしたいだけなのに、DBの前準備が必要
  • Fat Model
    • インフラ層のロジックが入り込む
  • ビジネスロジックがインフラ都合に引っ張られがち
    • 本来ドメインの変更とテーブルの変更は連動しないはず
    • テーブル変更が全てのドメインに影響する

参考

• Railsで考えるドメイン駆動設計のコアドメイン - Speaker Deck ドメイン駆動設計の比類なきパワーでRailsレガシーコードなど大爆殺したるわあああ！！！ #DDD - Qiita

事例

どこまでDDDに則るかは濃淡がある。

Rails Way は破壊しない方針

• DDDに "寄り道する" という考え方
• ActiveRecord でデータをやりとりする
• 紳士協定でARメソッドは限定的に呼び出す
• 少しだけ実装が増える
  • 以下が新登場
  • ドメインモデル

参考

• Railsにおけるドメイン駆動設計の実践 - Linyclar

Rails Way 逸脱 (DDD重視)

• インフラ層にActiveRecordを閉じ込める

• ドメインロジックは純粋なRubyで実装する

• 実装量が増える

  • 以下が新登場
    • インフラ層(リポジトリ)
    • ドメインモデル

  参考

• ドメイン駆動設計の比類なきパワーでRailsレガシーコードなど大爆殺したるわあああ！！！ #DDD - Qiita

• 巨大レガシーシステムの戦略評価とリファクタリングにおけるDDDの活用事例 - Speaker Deck

比較検討