読者です 読者をやめる 読者になる 読者になる

もちゅろぐ

お辞儀して顔上げたらおっさんになっていた子どもが大人を目指します。

Webアーキテクチャとモバイルアーキテクチャをごっちゃにすると違和感と齟齬しか残らない

久々の更新。

お酒の力をかりてツラツラと書いてます。

私は仕事でWebのフロントエンド、バックエンドと、モバイル(iOS/Android/Xamarin)の開発を一通り経験しました。 そんななか、最近のQiitaとかのアーキテクチャ記事に凄い違和感を覚えるので、頭の整理も兼ねてチラ裏としてまとめてみました。

アーキテクチャのほとんどがモバイルアプリではオーバーデザイン

少し気の強い見出しですが、説明させてください。

昔からMVCの対抗案/亜種として、MVP/MVVM/Fluxとか色々と出ています。 出てること自体は特に気にしていないのですが、アーキテクチャは具体案というより概念寄りなので、 Web/Mobile問わずどのプラットフォームにも当て込めることが可能です。

Qiitaの記事にもアーキテクチャ・設計に関する記事が結構あります。 だけどアーキテクチャの記事がサーバサイドとアプリで分け隔てなく書かれていることが多いと感じています。

サーバ側はドメイン領域が大きくなりやすく、複数DB、複数サービスとの連携が当たり前になりやすいです。 いっぽうアプリ側はどうかと言うと、ドメインのロジックはアプリ側では持たずに最近はサーバにロジック、データをおいておきアプリはノードになることが多いので、 アプリ側のドメイン領域が肥大・複雑化しにくいと思います。

これがオフラインアプリやモバイル特有の機能(BLE/Camera/GPSなど)が複雑であるのなら分かります。 しかしそもそもサーバ連携あるのに、アプリ側のドメインが肥大するのは、サービスという視野から見るとDRY原則を破ってます。

ドメインのエンティティはライフサイクルを持っているので、サーバ側のDBに居たり、モバイルのメモリ上に居たりするので、モバイル側はドメインは完全不要ではないですが、 サーバ側と同じ複雑さに耐えられるアーキテクチャデザインをモバイル側にも考えずに適用すると、実際に手を動かしてみると非常に違和感を感じます。 違和感とは中身のないレイヤー(=メソッド)が多く、「この緩衝材(メソッド)いるの?」と感じてしまいます。

複雑さに耐えられるアーキテクチャの恩恵よりもアーキテクチャ自体の複雑さが勝ってしまい、シンプルな要求の実装がかえって複雑になってしまうケースが多いです。 アーキテクチャを提唱したライブラリを使うのも手ですが、リスクは存在します。

iOSだと追従しなければいけない

リスクとして、iOSだと常に定期的にバージョンアップが実施されスパンも短いです。 バージョンアップが実施されるだけならまだしも、最新バージョンでビルドしたものでなければリジェクト対象になるので、必然的に所謂お上についていかなければいけないです。 その環境下で、アーキテクチャをライブラリなど使って実現していると、ライブラリのバージョンアップ対応待ち、場合によっては対応されないので自分らで対応になります。

たしかにライブラリはある一定の条件下の範囲内(想定範囲内)であれば高速・安定の開発を保証できますが、その基盤(お上)が変わると、必然的に影響は避けられずビルドエラーならまだしも、ランタイムエラーや挙動変更によるライブラリ挙動変化による不具合のリスクもあります。 サーバ側であれば非推奨バージョン、非サポートバージョンはあれど緩やかで開発者のペースで移行作業が行えます。

バイルに求められるアーキテクチャ

ほとんどジャストアイデアですが、次のような要件を満たす骨組みでしょうか。 主に長期的でアプリを長く育てていこうとしている場合です。何かのイベント用であれば、好きにすればいいと思います。

  • サーバサイドとして提唱しているアーキテクチャは、脊髄反射で組み込まない。
  • 複雑さに耐えられるアーキテクチャよりも、壊しやすい組み立てやすい、プロダクトストーリーを優先できて、技術負債(=複雑さ)は空いた時間にインクリメントに改善できるライトウェイトなアーキテクチャを考える。
  • インクリメントな改善を支えられるように、シンプルな思考でテストケースを追加しやすく、実施速度が早いテスト環境を構築する。
  • (Option)UIに強いライブラリを採用する.