どうもおはようございます、こんにちは、こんばんは。 今回は、アーキテクチャをまとめてみました。備忘録。
アーキテクチャを取り入れる理由
アーキテクチャはアプリを綺麗に開発・継続的に運用していくための設計方法。
UI（プレゼンテーション）とそれ以外のUIに関連しない処理（ドメイン）にざっくり分けられる。 分けられると何が良いのか。
- 処理が理解しやすい
- 重複コードの排除
- 分業がしやすい
- テスタビリティの向上 など。
これによって、品質や開発スピードの向上につながる。 アーキテクチャによって特徴が異なるため、開発人数や環境、期間などによってどれが最適か検討する必要がある。
各アーキテクチャごとの概要
| アーキテクチャ | 概要 | 役割 | メリット | デメリット |
|---|---|---|---|---|
| Cocoa MVC | Appleが推奨しているアーキテクチャ。 CocoaMVCの大きな特徴は、ViewとModelが完全に独立しているところ。 ModelとViewが独立していることによって、再利用性が高まり、Controllerだけ作り直せば流用できる。 |
Model - データの処理 - ビジネスロジック - Entityの保持 ViewController - UIの更新 ユーザーのアクション通知 - Modelの操作 |
- 開発スピードが早い、シンプルな構成で学習コストが低い。 - 経験が浅くても保守しやすい。 - Modelのテストが可能になる。 |
ViewControllerの肥大化や重複コードにより可読性の低下。 |
| MVP（PassiveView） | MVP の特徴はテスト容易性と作業分担のしやすさを実現させるところ。 フロー同期（対象データを更新してからUI更新する）のため データフローが追いやすく書き易い。 protocol 化して疎結合にすることで、Presenter単体でのテストが行える。 |
Model - データの処理 - データの更新 - ビジネスロジックView - タップイベントなどをPresenerへ通知 - UIの更新 Presenter - Modelの操作 - Viewを更新 - Viewの状態を保持 - UI関連のロジック |
- MVVMやCleanArchTectureなどに比べるとシンプルな構成。 - View（viewController）の肥大化が抑えられ可読性が向上する。 - 画面ごとに書き方が統一しやすい。 |
- コード量が増える。 - MVCに比べると学習が必要。 |
| MVVM | MVVM の特徴はViewとViewModelをデータバインディングと呼ばれるしくみで関連付けることで、 ViewModelの状態を更新するだけで、 Viewの状態も更新され画面に反映される。 ネットを見ていると最近よく使われているパターンの一つ。 |
Model - データの処理 - ビジネスロジックView - ユーザーのアクションをViewModelへ通知 - ViewModelの変更を元にUIの更新 ViewModel - ViewとViewModelのバインディング - Viewの状態を保持 - ViewとModelの仲介 |
- 可読性の向上 - テストの容易性 - Viewへの更新通知、指示の部部分のコードが不要。 - 学習コストが高い。 |
- 小規模、少人数のプロジェクトではコストに対してリターンが少ない。 |
| Clean Archtechture | サーバー通信や例外処理などもModelに切り分けられることが多いが、 より責務を細分化して定義することで 変更に強く可読性が高い。 Clean Architectureは依存関係に重きを置く設計であるため、 各層を単一方向につなげる。 |
Entity - データ - 使用する外部オブジェクトに依存しないロジックUseCase - ビジネスロジックRepository - データの処理 View - UIの更新 - タップイベントなどをUseCaseへ通知 - データとViewのバインディング - Viewの状態を保持 |
- OSに非依存のロジックはAndroid,iOSで同じように書きやすい。 - 「何をどこに置く」という規約として機能し、コードの粒度を揃える |
- 学習コストが高い。 - 責務を細分化するためファイル数が多くなる。 |
検討結果
各アーキテクチャを比較検討した結果、MVCのまま実装するのが良いと考えた。
理由は以下の通り。
開発人数とスキルセットの考慮
Flux,CleanArchtecureなどのレイヤーが細分化されたアーキテクチャパターンは、
「何をどこに置く」という規約として機能し、コードの粒度を揃える機能がある。
そのため開発人数が5人以上の規模かつ、アーキテクチャパターンの理解が浅いメンバーが多い場合に有用であるため
今回のような少人数の場合、MVC のようなある程度自由の効くアーキテクチャパターンが良いと感じた。
プロジェクトの期間と規模
MVVM,CleanArchtecureは、スタートアップで根本的な概念、仕様の見直しが発生するプロジェクトでは効果が出づらく
MVCやMVPのような最低限のパターンでの方が、今回のプロジェクトの場合レビュワーの負担の減少や開発スピードという点で良い。
プロジェクトの優先項目
今後商用化に向けてはテストの容易性なども必要になってくるとは思うが
開発、保守のしやすさなどからMVCで問題ないと感じる。
アーキテクチャ変更によるリスク
現状一定の品質を担保しながら開発スピードを上げるためMVCを採用している。
変更のバックログを作成し期間を確保すれば問題ないが、今後開発人数が増えないことや上記の理由などから
リスクを取る必要のある恩恵がないと判断される。
まとめ
現場のアーキテクチャはCocoa MVCを採用してますが、現在技術検証ということでMVPの反映とかやっているのでまた実際に実装した所感も書ければと思います。
ブログの投稿は基本毎日19時頃する予定です。
コメントや反応あると嬉しいです！
