WHITEPLUS TechBlog

株式会社ホワイトプラスのエンジニアによる開発ブログです。

Androidアプリのこれからの設計を考えた

Android

この記事はWHITEPLUS Advent Calendar 2020の25日目の記事です。

はじめに

こんにちは！ホワイトプラスでAndroidアプリを主に担当している仲見川です。 AndroidアプリのRebootから半年ほどたって設計もある程度見えてきたので整理しつつ今後どのようにあたらしい設計を適用していくのかを考えて見ました。

本項ではDDDについての話が出ますが、実装をどのようにするかの話を主軸としておりDDDのモデリングについては記載していません。 AndroidについてもDDDについてもまだまだ勉強中なので正しく無い部分があったら遠慮無くご指摘ください！

従来の設計

2015年に最初に作られたときから大きなメンテナンスが行われてこなかった為、現在のAndroid界隈から見るとレトロな作りとなっています。 AndroidBeforeDDD.png (25.1 kB)

エリックエヴァンスのドメイン駆動設計で言う「利口なUI」とも言える状態で。

これはこれでゼロベースでは早く作れるメリットがあるため開発チームも企画をするチームも手探りが多くまず作る、という観点で見たときに当時は良かったけれど改修を重ね肥大化してくると変更した際にどこに影響がでるのか分からないといった状況へと変化しつつあり。

・迅速なプロトタイピングやイテレーションを行おうとしても、自然と限界に行き当たる。抽象化が欠けているために、リファクタリングの選択肢が制限されるからだ。
・複雑さによってすぐに覆い尽くされてしまうので、成長しようとしても、単純なアプリケーションを追加することしかできない。より豊かなふるまいが実現できるようになるといった、優雅な道は存在しない。
Eric Evans. エリック・エヴァンスのドメイン駆動設計 (Japanese Edition) (Kindle の位置No.2121-2125). Kindle 版.

エヴァンス本のこのデメリットが顕著になっているといえます。

これからの設計

リネットのサーバーサイドではリネットの「サービス変化に合わせて柔軟にスピード感を持って対応したい」と考えその方法としてドメイン駆動設計の考え方を用いています。（サーバーサイドでのアプローチと成果）

Androidアプリにおいても「サービス変化に合わせて柔軟にスピード感を持って対応したい」を実現するためにDDDを取り入れます。ドメインロジックの変更を容易にするアプローチとして「MVVMをベースとしてModel層をオニオンアーキテクチャ*1 」という形を選びました。

f:id:nakamigawa:20201216153439p:plain

ViewModelをACL（腐敗防止層）としてDomainModelとLiveDataの変換などを行います。 Viewに対してDomainModelを渡してしまうといっけんすると便利そうですがDomainModelの変更時にViewの利用状況も考慮しなければならない為、影響範囲を調べるだけでも大変になってしまいます。

Push通知やIntentでのバックグラウンド処理はViewModelとは別のACLを用途に合わせて切り出します。 View同士のIntent等はViewで行います。（ハンドリングにドメイン知識が必要であればViewからViewModelの判断処理を呼び出します）

上の図は少し抽象的なので具体的に実装をするにあたっては以下のように参照方向やパッケージの構造を作ります。

f:id:nakamigawa:20201216153738p:plain

移行計画

従来の設計ではViewとDBがAPI越しに密結合していてViewにドメイン知識がたくさん存在します。 そのため従来の設計とこれからの設計には基本的に互換性はありません。

全てを一気にあたらしい設計に置き換えてリリースできれば良いですがもちろんそういった対応は難しいです。 改修を行う度に少しずつあたらしい設計に寄せて行きます。

具体的には改修や機能追加時に複雑だったり変更が多く入ることが見込まれるドメインロジックにはDomainModelを作成しDomainModelにドメインロジックを凝集します。 そして、既存の画面で該当のドメインロジックを扱う画面は改修に合わせてDomainModelを使用するように変更していきます。

DomainModelを作るまでもない機能に関してはViewModelまでで済ませてしまいますが、データアクセスについてはViewModelを経由してDomainModelを取得する形に統一して行くので新しく作る機能についてはViewModelで完結する物は多くないと思います。

既存画面でDomainModelを必要としない物は結果的に従来の設計のまま残りますが、変更がない部分と言うことになるため従来のまま残っていてもひとまずは問題が無いこととします。

まとめ

今回はどのように実装を書くかという話を軸にしてしまいましたが今回の話はDomainModelを書く場所を用意する話で、 より良いアプリを作っていくために本質としてはDomainModelをチームでしっかりと洗練させて行かなければと改めて感じました。

ともすればモデリングよりもまず先に実装に意識が向いてしまうのでよくよく注意して行きたいと思います。

さいごに

ホワイトプラスでは事業成長とエンジニアリングの両方を考えるのが大好きなエンジニアを募集しています。

open.talentio.com

https://open.talentio.com/1/c/wh-plus/requisitions/detail/13196open.talentio.com

*1:この「MVVMをベースとしてModel層をオニオンアーキテクチャ」が不勉強でもしかしたら何かしらすでに名前があるアーキテクチャであれば是非教えて頂きたいです。