ContentsアーキテクチャのほとんどがモバイルアプリではオーバーデザインiOSだと追従しなければいけないモバイルに求められるアーキテクチャネットで見かけるアーキテクチャパターンのほとんどモバイルアプリではオーバーデザインです。私は仕事でWebのフロントエンド、バックエンドと、モバイル(iOS/Android/Xamarin)の開発を一通り経験しました。そんななか、最近のQiitaとかのアーキテクチャ記事に凄い違和感を覚えるので、頭の整理も兼ねてチラ裏としてまとめてみました。アーキテクチャのほとんどがモバイルアプリではオーバーデザイン昔からMVCの対抗案/亜種として、MVP/MVVM/Fluxとか色々と出ています。Web/Mobile問わずどのプラットフォームにも実現することか可能です。Qiitaの記事にもアーキテクチャ・設計に関する記事が結構あります。アーキテクチャの記事がサーバサイドとアプリで分け隔てなく書かれていることが多いと感じています。サーバ側はドメイン領域が大きくなりやすく、複数DB、複数サービスとの連携が当たり前になりやすいです。アプリ側のドメイン領域が肥大・複雑化しにくいと思います。これがオフラインアプリやモバイル特有の機能(BLE/Camera/GPSなど)が複雑であるのなら分かります。そもそもサーバ連携あるのに、アプリ側のドメインが肥大するのは、サービスという視野から見るとDRY原則を破ってます。サーバ側と同じ複雑さに耐えられるアーキテクチャデザインをモバイル側にも考えずに適用すると、実際に手を動かしてみると非常に違和感を感じます。違和感とは中身のないレイヤー(=メソッド)が多く、「この緩衝材(メソッド)いるの?」と感じてしまいます。複雑さに耐えられるアーキテクチャの恩恵よりもアーキテクチャ自体の複雑さが勝ってしまい、シンプルな要求の実装がかえって複雑になってしまうケースが多いです。アーキテクチャを提唱したライブラリを使うのも手ですが、リスクは存在します。iOSだと追従しなければいけないリスクとして、iOSだと常に定期的にバージョンアップが実施されスパンも短いです。バージョンアップが実施されるだけならまだしも、最新バージョンでビルドしたものでなければリジェクト対象になるので、必然的に所謂お上についていかなければいけないです。その環境下で、アーキテクチャをライブラリなど使って実現していると、ライブラリのバージョンアップ対応待ち、場合によっては対応されないので自分らで対応になります。たしかにライブラリはある一定の条件下の範囲内(想定範囲内)であれば高速・安定の開発を保証できますが、その基盤(お上)が変わると、必然的に影響は避けられずビルドエラーならまだしも、ランタイムエラーや挙動変更によるライブラリ挙動変化による不具合のリスクもあります。サーバ側であれば非推奨バージョン、非サポートバージョンはあれど緩やかで開発者のペースで移行作業が行えます。モバイルに求められるアーキテクチャほとんどジャストアイデアですが、次のような要件を満たす骨組みでしょうか。長期的でアプリを長く育てていこうとしている場合です。何かのイベント用であれば、好きにすればいいと思います。サーバサイドとして提唱しているアーキテクチャは、脊髄反射で組み込まない。複雑さに耐えられるアーキテクチャよりも、壊しやすい組み立てやすい、プロダクトストーリーを優先できて、技術負債(=複雑さ)は空いた時間にインクリメントに改善できるライトウェイトなアーキテクチャを考える。インクリメントな改善を支えられるように、シンプルな思考でテストケースを追加しやすく、実施速度が早いテスト環境を構築する。mothuleこのページはmothuleの技術ブログになります。当サイトに記載された情報により損害が発生しましても、責任は致しかねません。