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