サービスレイヤの設計見直し

## 概要

サービスレイヤの設計見直し
3.nのリファクタリングフェーズにおいて、以下の指針でサービスレイヤの設計を行う

- 壊れにくく
- テストしやすく
- 扱いやすい

## 目指すもの

- SOA のサービス
- マイクロサービスアーキテクチャのサービス
- RESTful API のサービス

## 関心の分離

- よく言われるやつ
- そもそも「関心」って何？
- 関心を分離することで何が良くなるの？

- 業務上の一処理
- 商品, 注文, 顧客など
- レイヤ
- アプリケーションとデータの橋渡し
- サービス同士が依存しないこと
- 注文は商品や顧客に依存するけど, どうすんの？
- 商品が変わったり, 顧客が変わったりしても注文サービスのコードは影響を受けないように設計する
- 状態を持つサービスと状態を持たないサービスに分ける
- ステートレスサービスと, ステートフルサービス
- 基本的にはステートレスサービス
- セッションを扱わない
- 引数で結果が一意になる
- ステートフルサービス
- 状態を扱うサービス
- コントローラで担うべき. 通常は扱わない
- ライフサイクル管理など

## やらない方がよいこと

- セッションを内部で扱う
- Request, Response を内部で扱う
- サービスの内部で他のサービスを呼び出す
- 他の業務を扱う
- 固有のプレゼンテーション層に依存する
- Form やバッチのロジックを扱わない

## 意識すること

- インターフェイスを持つ
- テストしにくいなと思ったら設計を見直す
- 大きくしすぎない
- 外部に公開すれば RESTful API に流用できるように
- あくまでも業務を扱うビジネスロジックである

## 各サービスクラスの改善点

### CartService

- セッションを扱うべきではない
- CartSession 等に変更した方が良いと思われる
- セッションを透過的に扱うという手もある
- http://docs.sylius.org/en/latest/book/orders/checkout.html

### CsvExportService

- サービスではなくユーティリティなので名称変更した方が良い
- 検索対象, 検索パラメータを渡すと CSV 出力してくれるサービスはあっても良いと思う

### CsvImportService

- サービスではなくユーティリティなので名称変更した方が良い

### EntityProxyService

- サービスではなくユーティリティなので名称変更した方が良い

### MailService

- メールを組み立てて送信しているだけなので, もっと汎用的なユーティリティにした方がよい
- メールまわりの拡張性を落している

### OrderHelper

- サービスではない

### PaymentService

- RequestStack を保持しているので切り離したい

### PluginService

- サービスではなくユーティリティなので名称変更した方が良い

### PurchaseFlow

- サービスとは毛色が違うので別にした方が良い

### SchemaService

- サービスではなくユーティリティなので名称変更した方が良い

### ShoppingService

- セッションを保持しないよう透過的に扱うようにした方が良い
- 値コピーしているメソッドは `Entity::copyProperties()` を使用した方が良い

### SystemService

- DBバージョンを返しているだけなので名称変更した方が良い

### TaxRuleService

- サービスではなくユーティリティなので名称変更した方が良い

### OrderService

廃止予定

### CalculateService

廃止予定

## 参考

Sylius のサービス設計が参考になる
http://docs.sylius.org/en/latest/api/index.html