Service層を作って異なるインターフェースの処理を共通化する

　webサービスを作っていると時折、異なるインターフェースから同じようなことをしたくなる時があります。具体的にはAPI認証で通るコントローラとID、パスワードによる管理者ユーザ認証で通るコントローラで似た処理をする時です。こうなった時、複雑さを減らすにはService層を作るのがよいです。
　例えば、ユーザデータ（一般ユーザに関するデータのまとまり）の更新を考えます。データが許容する整合性を保つ最大範囲を自由に操作できるのが管理者ユーザで、自分のニックネームのみを変えられるのがAPIユーザとします。ユーザデータの保存処理の責務はユーザデータ自身の整合性を保つことであり、誰に操作されるかに関心を持ちません。そのためユーザデータの操作可能範囲はそれぞれのインターフェースのバリデーションに任せます（LaravelならFormRequest）。ここまでをそのまま実装すると次図の様にモデルに対する複雑な操作が複数発生して混乱のもとになります。

　対策としてService層を設けます。これが上手く働くと次図の様に複雑さが軽減されます。

　Controller : Service = n : 1 の関係になるぐらいがちょうどよく、Service層の恩恵にあずかれます。常に 1: 1 では余分なコードにほかならないのでService層は不要です。また絶対にしてはいけないのが n : n のServiceがControllerに依存しだすパターンです。こうなるとかえって複雑さが増します。