クリーンアーキテクチャのusecaseレイヤーに属しているメソッドについてです。
以下のようなレイヤーでアプリを作成しています。
そこで質問なのですが、usecaseに属するメソッドから、同じusecase層に属するメソッドを呼び出す行為は問題ないのでしょうか？
アーキテクチャの基本的な考え方として、依存性は常に上位に矛先を向けていなければならないというものがあります。
それを踏まえると同じレイヤーに属するもの同士で依存性を発生（？）させてはいけないよう気がします。
アーキテクチャの基本的な考え方として、依存性は常に上位に矛先を向けていなければならないというものがあります。
私の「依存とその方向」についての理解は、注目するのは安定度であり、不安定な方への依存を避けるというのがポイントと捉えています。
クリーンアーキテクチャの円の図では、内側の層が安定度が高く外側の層に行くほど不安定になるので、「内側から外の層に依存するのは避ける」という主張になっています。
ですので、同じ層の中での依存は許容される形になりますが、同じ層の中でも安定度の高低はあると思うので、それを考慮して依存の向きを決定したほうが良いのだろうと考えています。
（上や下という捉え方はなかったので、"上位"が何を指しておられるのかは分かっていません。「常に上位を向けていなければならない」について出典などあれば教えていただければ幸いです。）
usecaseに属するメソッドから、同じusecase層に属するメソッドを呼び出す行為は問題ないのでしょうか？
あまり経験は無いのですが、ユースケースが単一の目的や業務を表現するとすれば、ユースケースから別のユースケースを呼ぶのはどういった状況なのだろうか？という疑問があります。（参考としてぜひ教えていただければ幸いです）
また仮にそのような状況にあったらまずは、その処理は別のクラスやモジュールとして分離できないか、本当に共通化すべき処理なのか（たまたまコードの状態が同じだけではないのか）ということを考えると思います。
回答がこれだけだと申し訳ないので、合わせて参考になりそうな文献を提示します。
ドメイン駆動設計について発信されている松岡さんの著書『ドメイン駆動設計 サンプルコード&FAQ』には、まさに同じFAQが載っています。
（8.6.1 ユースケースからユースケースを呼んでよい？）
その疑問に対する著者の意見としては「複雑になるので推奨しない」です。
以上、参考になれば幸いです。
@yamada0088
Questioner
回答ありがとうございます。
やっぱり推奨はされないですよね。
「上位」「下位」というワードはこちらの記事で使われていました。
ユースケースで別のユースケースを利用する場面としては、FirebaseAuthを使ってアカウントを作成すると、同時にログイン処理が行われてしまうので一度ログアウトしなければいけないケースがあり、そのときにログアウト処理を実行するユースケースを呼びたかったです。
というのもリポジトリではエラーハンドリングを行なっておらず、ユースケースにてエラーハンドリングを行っています。
なので、エラーハンドリングを実装していないリポジトリメソッドを実行するのではなく、エラーハンドリングを実装しているユースケースを同じくユースケースであるメソッドから呼び出したかったのです。
「上位」「下位」というワードはこちらの記事で使われていました。
教えていただき、ありがとうございます。
ざっと読みましたが「本質的な価値」に近い方を「上位」と表現されているのですね。
FirebaseAuthを使ってアカウントを作成すると、同時にログイン処理が行われてしまうので一度ログアウトしなければいけないケースがあり、そのときにログアウト処理を実行するユースケースを呼びたかったです。
なるほど、そういった状況なのですね。
気になるのは、アカウント作成ユースケースから呼び出したいのはログアウトユースケースなのかログアウト処理なのかという点です。
例えば、ログアウトした時に「ログアウトしました」のような通知を送る改修をしようとした場合にログアウトユースケースを変更することになると思います。そういったケースを考えるといかがでしょうか？
つまりモジュールの抽象度や粒度といった観点での話です。
ユースケースからユースケースを呼び出すとしても、コントーラーから呼ばれる上位のユースケースと、ユースケースを構成するサブユースケースがごちゃごちゃになっていると複雑になりそうです。（ここの上位は依存の話とは別の意味です）
@yamada0088
Questioner
コメントありがとうございます。
素朴な疑問なのですが、「ログアウトしました」のような通知をクライアントに知らせる（UIでの要件）はコントローラーで実装するものだという認識がありました。
しかし、UIの要件もユースケースにて実装するものなのでしょうか？
「ログアウトしました」のような通知をクライアントに知らせる
こちらはユースケースが変更される適当な例を挙げただけなので何でもいいです。
他には「ログアウトした時間を記録する」とか考えられるので、イメージしやすいものに置き換えてください。
通知の方法としてはメール、SMS、...etcあるのでUI要件というイメージはなかったです。
具体的な方法によらず「ユーザーにログアウトした事実を通知する」というのはユースケースになりえると考えています。
@yamada0088
Questioner
失礼な確認になるのですが、
ユースケースになりえると考えています。
これはblue32a様独自の考えということでよろしいのでしょうか？
はい、回答は私個人の考えです。
@yamada0088
Questioner
わかりました。ありがとうございます。
