iOSアプリクラス設計の個人的見解

iOSアプリの仕事をしているとよくクラス設計の話になりやすい。基本的にモバイルアプリは設計が自由なためアプリごとにアーキテクチャが異なる。
そのためMVC, MVP, MVVMなどのUIアーキテクチャやClean Architectureなどのシステムアーキテクチャなどの選択肢が多い。選択肢が多いというのは曲者である意味正解がないため、メンバーで共通の認識を取ることが難しかったりする。

Clean Architectureを取り入れるべきか?

Clean Architectureというか、ドメイン駆動設計を取り入れるかどうかの問題だと思う。それが、Clean Architecture・ヘキサゴナル・オニオンなのかはそこまで重要じゃない。

それで、個人的な見解だがモバイルアプリにこれらのシステムアーキテクチャを入れるのオーバーエンジニアリングかなと考えている。モバイルアプリが担当するのはViewに関することが多いので、ドメイン駆動設計をそのまま取り入れるとドメイン貧血症になりやすい。そのため、Viewに関連することをドメインに引き上げようとするが、何のロジックを引き上げるのかということも問題になってくる。
そこでメンバーと認識を合わせようとするが結構な手間も同時にかかる。自分のなかでこれらのアーキテクチャを入れた方がいいと思うのは、Lineやメルカリのようなアプリで本来メーセージアプリだったのがゲームが入ったり、メルペイが入ったり複数の目的になったアプリはいいのであって、99%以上のアプリはほとんど不要だと考えている。

テストである程度担保できればいいのではないか

実装していて大変だなと感じるのが特定のView, ViewControllerにロジックががっつり書いてあってロジックの再利用が難しいパターン。また、これらのロジックは基本的にViewと密結合しているためテストも書きにくくなっている。なのでこれを分離してあげれば良い。そのため、Clean Architectureという大層なものを導入しなくてもモデルに分離してあげれば良い。

ただ、気をつけていないとView, ViewControllerにロジック書かれてしまうので、Rx系を導入してView, ViewControllerは値をバインドしているだけという状態でいいと考えている。

そして、モバイルアプリを作るということはtoCよりのアプリであるケースがほとんどなので大体は爆死する可能性が高い。そのため、やっぱりそこまで作り込む必要はないというのが感想。

まとめ

この記事を書いたきっかけは、モバイルエンジニアは設計論が多くて新規参入を除外しているという意見を目にしたからだ。この意見は半分当たって、半分当たってないというのが自分の意見だ。設計をやりすぎな面もあるが、反対にどこまで細かく設計するのかの境界を見定めるのも結局設計の知識がないと通用しないなと感じる。

とにかく言いたいのはまだ売上がさほど上がっていない状態なら設計云々の話は不要だし、売上が上がっていないのに設計がキツい場合はビジネスそのものがイケていない or 画面設計がミスっているのどちらか。