※ この記事はエキサイトAdvent Calendar 2018 1日目の記事です。

今年もアドベントカレンダーやりたい！ということで半ば強引にカレンダーを立ち上げた@rmakiyamaです。
業務ではflagmeのAndroidやエキサイト婚活全般、Radiotalk(10月リリース)のAndroidを担当しています！

今回は、2年連続でAndroidのフルスクラッチ開発に関わることになり、エイヤア！と
Radiotalkアプリをマルチモジュールでの実装を進めていったお話をします。

設計方針

5月某日、設計方針をどうするかのチーム会議が行われました。
まずは、そこで決まった方針について簡単に説明します。

ガンガンいこうぜ！

なかなかド新規でAndroid開発！というのは弊社では多くなく
せっかくだし使いたい技術、やりたい設計、ガンガンいこうぜ！の作戦が議決されました。

というわけで

Kotlinは問答無用だよね
前回のMVVMの反省を活かしてMVVMで！
Repositoryパターンみなおしたい（独断と偏見）
Instant Appと相性良さそう
↑もあるし完全にマルチモジュールの機運だよね
DDDぽいの入れていきたい
AACもやろうぜ

という欲に満ちた感じになりました。正直、反省しています。

こうなった

フルKotlin
UseCaseでローカルまたはリモートからデータを取得する
ViewModelでObservableをLiveDataに変換して扱う
マルチモジュール
- 別モジュールからのデータ取得はリモートから取得と同じような扱いとしClientを経由
DBはRoomを採用
ActivityのBaseクラスを作らずやってみよう

モジュールの分割

モジュールの分割では「水平方向」と「垂直方向」でのわけかたがありますが、Radiotalkでは垂直方向での分割を採用しました。
水平方向での分割も同時に入れることも検討しましたが、単純にモジュール数がレイヤー数倍に膨らむといった懸念と、別プロジェクトではレイヤーわけした設計を、コードレビューを通してその原則を守るように実装できていた、などの意見から今回は採用を見送りました。

その結果、以下のような分割になりました。

app
common
talk
program
user
talkdetail
programdetail
userdetail
record
player
mypage
etc...

※ モジュールの分割は、当時もベストプラクティスがわかっておらず、１番後悔している部分です。これを参考に、はならないと思います。

UseCase

例として、Radiotalkでトーク詳細で表示するデータを取得するUseCaseを見ていきます。（一部実コードと違う部分もアあります）

GetDisplayedTalkUseCase.kt

internal class GetDisplayedTalkUseCase @Inject constructor(
        private val api: DetailsApiClient,
        private val programClient: ProgramClient,
        private val talkClient: TalkClient,
        private val userClient: UserClient
) : RxCommandUseCase<TalkId, DisplayedTalk>() {

    override fun execute(parameters: TalkId): Completable {
        return api.getDisplayedTalk(parameters.value)
                .flatMap { it.body()?.cache() ?: throw TalkNotFoundException(parameters) }
                .flatMapCompletable {
                    Completable.fromAction { onNextResult(it) }
                }
    }

    private fun GetDisplayedTalkResponse.cache(): Single<DisplayedTalk> {
        return Singles.zip(
                programClient.convertWithCache(program),
                talkClient.convertWithCache(talk),
                userClient.convertWithCache(user)
        ) { program, talk, user ->
            DisplayedTalk(program, talk, user, clipped)
        }
    }
}

このようにProgram, Talk, userそれぞれのコンバートやキャッシュ処理は、各モジュールで行うため、Clientを経由して処理をしています。

所感

よかったこと

責務の分離ができた

Kotlinのinternal修飾子を使うことで、制約を強くできたのは大きかったです。あとは、コードレビューで、「これはここにかくべきではない」「こっちのモジュールの責務では」みたいな議論ができたのも良かったです！

機能開発の分担が楽だった

リリースまでの開発は２名で行いました。当時、お互いに主務は別にあったため、手の空いたときにという状況でした。
今回は機能ごとにモジュールを分けていたので、自分の開発に集中することができました。

つらかったこと

開発期間が短い中、かなり手探りだったのでたくさんありました…
ざっと列挙すると

循環参照
- 画面遷移の循環
- Responseのモデルを使い回せない
DI（Dagger）
- 雰囲気でDIを使っている
- マルチモジュールでのDIの知見が少ない
ボイラーテンプレートが多い
- モジュール毎にDaggerの諸々を書かなきゃ（仕方ないよね）
- 毎回、DataBindingとViewModelの初期化とか
  - Baseクラスを導入しても良いかも

とくに困った循環参照問題について特筆してみます。

循環参照

マルチモジュールならではの問題で、モジュールAがモジュールBに依存している場合、モジュールBはモジュールAに依存できません。
ここで画面遷移の循環が発生します。例えば、Radiotalkの場合、番組詳細からトーク画面へ、トーク画面から番組詳細への画面遷移があります。

当初、それぞれprogramdetail/talkdetailのモジュールに分けていたため、循環依存が発生していました。

悩んだ結果、この場合に関しては、「詳細を表示する」という意味合いのモジュールとしてモジュールの統合をして解決しました。
DIを用いてインターフェースを使って、という方法も検討しましたが、開発期間の問題もあり、スピード重視の判断だったので最善ではなさそうです。

わからないこと

本業もありながら１０月のリリースに向けてスピード重視という部分もあり、不安も疑問も抱えながらの実装でした。
徐々にマルチモジュールの知見も多く見られるようになった今、まだ悩んでいる、わからない部分も多々あります。

マルチモジュール開発にしたけどビルドかなり遅い
- 特にcommonを変えたとき。そんなものなのかな。設定の問題、？
APIモジュールを作るべきだったのか
- 分割の考え方にもよるけど、作っておくとスムーズだったかも
ioschedくらい少ない分割でも良かったかも。
- 開発メンバーも多くない中で、分割数も結構あり、制約が多すぎたかもなと思っている

今後

リリースも完了した今、大きくやりたいことは以下の２つです。

モジュールの整理
DI整理

今回は、大げさに言うと「画面単位」くらいのモジュール分割になっています。
ここはサービスを俯瞰して、しっかりしたコンテキストマップを作り、モジュールの整理をしたいです。

DIについても、雰囲気でDaggerを使っている感じが否めないので、スコープを意識して設計しなおしたいです。

Android開発でマルチモジュールを採用してみて