Service object, class, layer
サービスクラス、サービスオブジェクト、サービスレイヤーのややこしさを整理
いろんなところで語られている、概念の曖昧さがある。どのサービス？
DDD
アプリケーションサービス
アプリケーション層に基づくユースケースを書くもの
ドメインの知識に基づかない、アプリケーション特有の処理を書く
ドメインサービス
ドメインモデルを構成する3要素、Value object, Entity, Serviceの1つ
Value objectでもEntityでもないが、ドメイン層に基づくビジネスロジックを書くもの
PofEAA
Service Layer
https://www.martinfowler.com/eaaCatalog/serviceLayer.html
モデル層を守る障壁、モデル層へのアクセスに規律を課すもの
レイヤードアーキテクチャの1つ
なぜ欲しくなるのか？
Fat modelの解消
MVCではcontrollerとmodelのどちらか、特にモデル層にビジネスロジックの記述が押し付けられやすい
その処理を特定のユースケースごとに分割して吸い出すためのサービス
本来ドメインモデルにあるべき処理が吸い出されていくとドメインモデル貧血症になる
複数のモデルを操作したい
処理の再利用性の向上
testabilityの向上
RailsのようにEntityがActiveRecordパターン
課題・考察すべきこと
どこに置くか、ファイルレイアウト、レイヤー
新たなレイヤーを追加することの問題
規律がないレイヤーは破綻する
曖昧な責務のオブジェクト、レイヤー
モデリングが不十分ゆえに起きている
イミュータブルデータモデルにおけるイベントエンティティの見落とし
トランザクションスクリプト的な設計を促進しがち
Railsでは
Rails wayの基本では、REST&CRUDで操作するリソースに1:1で紐づくモデルが存在する
これに乗ることで高速に開発ができるので、そうなるようなモデリング（データモデリング・クラス設計）が重要
モデル app/models
ActiveRecordであることが大半
データモデリングとしてイミュータブルデータモデルを検討すれば、リソース・イベントのどちらもモデルとして自然に扱える
Fat modelからはValue objectを抽出できる可能性あり
composed_ofなど
ActiveRecordでない場合
POROでもよい
このPOROがDDDにおけるドメインサービスであったりする
Form objectパターン
このパターンに則る限りはサービスを考える必要はほとんどない
2025-09
今改めてServiceクラスについて考える 〜あるRails開発者の10年〜
Kaigi on Rails
ActiveRecord 複数のモデルにまたがる処理を書きたいときの設計方法 - Service層を入れるのはできるだけやめてほしい
上述の通りPOROやイベントモデル、フォームオブジェクトなどを紹介