ビジネスロジックとそうでないものを分離する

アプリケーションの適用領域（ドメイン）で意味のあるロジックは大事なものである上、複雑である場合が多いから、

常に正常に動作することを保証したい。

また、変更を加えるときに安全かつ的確に行いたい。

それらの目的のために単体テストを行う。

単体テストを行うとき、ビジネスロジック以外のものがビジネスロジックに紛れ込んでいるとき、テストしづらくなる。

例えば、データベースへの永続化を行っているところや、ファイルシステムへの書き込み、何かしらの通知を飛ばすところ（Webhookやメール送信）など。

これらがあると、テストではモックを使わなければいけないことが多い。

ビジネスロジックは、そういった外部のものへの依存をやめ、計算判断に徹するように設計する。何かしらの情報をもとにドメインにおいて大事な事柄を計算判断していくのがビジネスロジックの責務。

しかしアプリケーションを動かすためにはビジネスロジック以外の部分が不可欠。どうすればよいかというと、レイヤーを増やす。

RailsではController層がそれを担っている。Fat Controllerがアンチパターンとされる理由はだいたい大事なロジックをControllerに書くんじゃないよというもの。

アプリケーションとして動作させるために、ビジネスロジックとそうでないものを呼び出して連携させるのがController。

必要なデータをControllerで取得するケースがあって、取得するための方法をControllerが知っているのは違和感があったけど、「ビジネスロジックかどうか」という観点では、ビジネスロジックではないのでControllerが知っているのは問題なさそう。

ただ程度があるかなと思っていて、認可的な考え方がデータの取得に絡んでいる場合はモデルにスコープとして定義するのが良い気がしている。

例えば「特定のユーザしか閲覧できないデータの取得」。これは完全に認可が絡んでいるし、ドメインにおいて大事な気がする。