質問: 私はAndroidアプリの設計・開発に携わっているのですが、Androidアプリ開発を前提に, 設計について疑問があります。 皆様のご意見を伺いたいのですが、 Androidアプリ開発でDDDやクリーンアーキテクチャを採用した際, `Presenter` <-> `UseCase` のやりとりにRxJavaの`Observable`を使うことがよくあります。 ビジネスロジックなどの処理はバックグラウンドで行い, UIへ結果を返すのにこれで担っています。 ``` Observable.create(...) .subscribeOn(backgroundScheduler) .observeOn(uiThreadScheduler) .subscribe(...); ``` ここまでは他所でもよく見かけるパターンなのですが、 このパターンを`UserCase` <-> `Domain`, `Domain` <-> `Infra`層でのやりとりにまで広げているものを見かけます. 私は`Observable`に対して"非同期処理にまつわる面倒の多くを解消してくれるライブラリ"程度の認識でいるため、この記載を見ると"UseCase層より下層でも非同期によるメッセージングを推奨されている記載"に見えてしまいます. `Observable`は確かに便利ですが, 個人的にはビジネスロジックに非同期性を持ち込むのはコードを複雑化させる原因であると考え, UseCase層より下層での処理は同期処理で書くようにしています。 制約や要件の都合上、どうしても非同期を使う必要のあるケースもありますが、 それらがなくとも`Observable`の使用を推奨するようにとれる記載も見かけます。 `Observable`とすることの優位性を考えた結果、下記が思いつきました。 1. Androidの(貧弱な)バックグラウンドタスクAPIの代用 2. レイヤー間のインタフェースに柔軟性(エラー応答, 複数回応答, Pub/Sub)を持たせる意図 3. StreamApiの代用 4. Promiseの代用 5. 処理のカプセル化/処理のペンディング(後からsubscribeで発火させるコマンドパターン) 個人的にこれを解釈したところ, UseCase層より下層での`Observable`の扱いは、非同期処理の応答/監視を意図したものではなく, (2)(3)の恩恵を受けるための策ではないのか? との結論に至ったのですが... どのような理由があって`Observable`を使用されているのか, ご意見をお持ちの方にお聞きしたいです。 UseCase層より下層での非同期処理についてもあわせてご意見いただけると助かります。
回答: 同じくAndroidの設計や開発をしています。 あまり参考にならないかもしれませんが、同じような疑問をもったことがあったので、 考えをシェアさせてください。 私は、`UseCase`より下層で`Observable`を使ったこともあり、あえて使わなかったこともあります。 まず初めに下層で使った理由ですが、 1. yuki312さんが書かれている(2)の理由、特にエラー処理によるところが大きい。 2. チーム全体的にRxJavaの経験が少ないので、勉強のためにあえて。 次に、質問されている内容ではありませんが、 下層であえて使わなかった理由は、 1. RxJavaがdeprecatedになった場合に、代替手段に切り替える手間が大きくなりそうだから。 2. ドメインロジックが入る`Domain`層にRxJavaの知識が入るのはやめたかった。 (Data層もその責務を考えるのであれば`Observable`がどうしても必要なところはあまりないという考え) 3. ユニットテストがつらい。(毎回`TestSubscriber`を挟まなくてはいけないから) 後者のケースでは、DDDのレイヤードアーキテクチャを採用していたので、 実際には`UseCase`ではなく、 `Application`層の`ApplicationService`で`Observable`に変換をしていました。 以上が、UseCaseより下層で使った理由と使わなかった理由になります。 ちなみに、ご存知だったら恐縮ですが、 Android-CleanArchitectureでも議論はされていますね。