- 壊れにくく
- テストしやすく
- 扱いやすい
- SOA のサービス
- マイクロサービスアーキテクチャのサービス
- RESTful API のサービス
-
よく言われるやつ
-
そもそも「関心」って何？
-
関心を分離することで何が良くなるの？
-
業務上の一処理
- 商品, 注文, 顧客など
-
レイヤ
- アプリケーションとデータの橋渡し
-
サービス同士が依存しないこと
- 注文は商品や顧客に依存するけど, どうすんの？
- 商品が変わったり, 顧客が変わったりしても注文サービスのコードは影響を受けないように設計する
- 注文は商品や顧客に依存するけど, どうすんの？
-
状態を持つサービスと状態を持たないサービスに分ける
- ステートレスサービスと, ステートフルサービス
- 基本的にはステートレスサービス
- セッションを扱わない
- 引数で結果が一意になる
- ステートフルサービス
- 状態を扱うサービス
- コントローラで担うべき. 通常は扱わない
- ライフサイクル管理など
- セッションを内部で扱う
- Request, Response を内部で扱う
- サービスの内部で他のサービスを呼び出す
- 他の業務を扱う
- 固有のプレゼンテーション層に依存する
- Form やバッチのロジックを扱わない
- インターフェイスを持つ
- テストしにくいなと思ったら設計を見直す
- 大きくしすぎない
- 外部に公開すれば RESTful API に流用できるように
- あくまでも業務を扱うビジネスロジックである
- セッションを扱うべきではない
- CartSession 等に変更した方が良いと思われる
- セッションを透過的に扱うという手もある
- サービスではなくユーティリティなので名称変更した方が良い
- 検索対象, 検索パラメータを渡すと CSV 出力してくれるサービスはあっても良いと思う
- サービスではなくユーティリティなので名称変更した方が良い
- サービスではなくユーティリティなので名称変更した方が良い
- メールを組み立てて送信しているだけなので, もっと汎用的なユーティリティにした方がよい
- メールまわりの拡張性を落している
- サービスではない
- RequestStack を保持しているので切り離したい
- サービスではなくユーティリティなので名称変更した方が良い
- サービスとは毛色が違うので別にした方が良い
- サービスではなくユーティリティなので名称変更した方が良い
- セッションを保持しないよう透過的に扱うようにした方が良い
- 値コピーしているメソッドは
Entity::copyProperties()を使用した方が良い
- DBバージョンを返しているだけなので名称変更した方が良い
- サービスではなくユーティリティなので名称変更した方が良い
廃止予定
廃止予定
Sylius のサービス設計が参考になる http://docs.sylius.org/en/latest/api/index.html