俺的アプリケーション・アーキテクチャまとめ in Swift

#アプリケーション・アーキテクチャとは何か?
アプリケーション・アーキテクチャとはソフトウェア全体の設計手法のこと．UIの入出力処理とそれ以外を切り離したGUIアーキテクチャ(MVC/MVVM等)，よりマクロな視点でシステム全体としてどう設計するかに関わるシステムアーキテクチャ(Clean architecture)，モバイルアプリ特有のものでは，画面遷移のアーキテクチャ(VIPER等)がある．
(色んな文献読んでたら沼りそうだったので，ざっくりとした理解として記しておきます．詳しい人マサカリくださると助かります!)

#各手法の特徴とSwiftでの実装
それぞれの手法は，後からできたものが優れていると一概には言えず，アプリの規模や目的によってアプリケーション・アーキテクチャを使い分けることが好ましい．そこで，以下にそれぞれの手法の特徴と、Swiftで下記のようなRPGを実装した場合のサンプルコードを示す．
<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">SwiftにおけるMVC/MVVM/VIPER/Clean Architectureを整理するべく、RPGゲームチックなサンプルアプリ作ってます <a href="https://t.co/MfOnpi9ll2">pic.twitter.com/MfOnpi9ll2</a></p>&mdash; Masa (@Masa22546930) <a href="https://twitter.com/Masa22546930/status/1270630565427810304?ref_src=twsrc%5Etfw">June 10, 2020</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
##MVC
Model，View，Controllerを用いたアーキテクチャ．Swiftではキャンペーンなどの一時的な画面を気軽に組み込める一方，それぞれの部品の依存度が高く再利用性が低い「原初MVC」,Model,Viewの再利用性が高いがContorollerの再利用は諦めざるを得ない「Cocoa MVC」がある．
###原初MVC
[Small talk](https://ja.wikipedia.org/wiki/Smalltalk)にて考案されたMVCモデルがこれ．Small talk上の実装をSwiftに無理やり当てはめようとすると無理があるが，概念として表すと下図のようになる．Swift以外の言語でよく言われているMVCと同じ意味で使われるMVCモデルがこれ．

- Model:ビジネスロジックの塊のことで，具体的には機能付きの設計図
- View:Controllerオブジェクトを用いて，画面の描画を行う部分
- Controller:入力に対して，Modelオブジェクトを用いて処理を行う部分

###Cocoa MVC
SwiftでMVCと言えば一般的にこれを差す．他の言語だとMVPに当たる?(MVPは割愛)

- Model:ビジネスロジックの塊のことで，具体的には機能付きの設計図(class)
- View:ユーザーに対して画面を描画&入出力を受け付ける部分(Storyboard)
- Controller:ModelとViewの橋渡しの役割を果たす．具体的にはModelオブジェクトに処理を任せ，結果をViewオブジェクトに渡して画面に表示させる(ViewController.swift)

##MVVM
Model.View,ViewModelを用いたアーキテクチャ．ViewとViewModelをデータバインディングという手法を用いて関連付けさせることによって，ViewModelにViewに関する処理を記述しなくても，ViewModelの更新により自動的にViewが更新される．MVCにおけるControllerからViewに関する記述を除いたものがViewModelと言える.(Model/ViewはMVCと同じ役割を果たす)
MVCとは異なり，ViewとViewModelが完全に疎結合な要素になるので，メリットとして

- 別の責任者に任せることができるので生産性の向上に繋がる
- Model/View/ViewModelの更新にそれぞれリアクティブに反応できるようにするFPR(関数型リアクティブプログラミング)と相性がいい
- Model/View/ViewModelが独立しているので，小さい単位でテストを行えるようになる

というものがある．

##Clean architecture
[Clean architecture](https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html)はしばしばこちらの図で表される([The Clean Code Blog](https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html)より引用)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/595260/1f6f831d-6129-e0dd-cbc6-14c8e7d1128b.png)
特徴として，外側の要素が内側の要素に依存する，単一方向の関係のみが成り立っていることである．また，外部の要素が環境の変化を最も受けやすい構造になっている．それぞれの要素の果たす役割は

- Entity:処理方法に依存しないビジネスロジックの塊≒MVC,MVVMのModel
- Use Case:Entityを用いてアプリケーションの処理を記述し，ユーザーからの入力を出力に変更する部分．ここにはUIに関する処理は含まれない
- Interface Adapters:Entity,Use Caseで用いられているデータ表現をUIや外部サーバー用のデータに変換/UIやデータベースからのデータをEntity,Use Caseで用いられるデータ表現に変換する，外部とUse Caseの橋渡しを担う部位になる．
- FrameWorks & Drivers:データベースやAPIとの通信処理，UIの構築を行う部位

である．


##VIPER(≒Clean Swift)
VIPERはView, Interactor, Presenter, Entity, Routerの5つの要素によって構成されるアーキテクチャで，Clean architectureに画面遷移に関する処理を担うRouterを足したものになっている．それぞれの要素は,

- View:Clean architectureのFrameWorks & Driversと同じ
- Interactor:Clean architectureのUse caseと同じ
- Presenter:Clean architectureのInterface Adaptersと同じ
- Entity:Clean architectureのEntityと同じ
- Router:画面遷移に関する処理を担う部位.

である．
Routerの役割をさらに詳しくまとめると

- ViewControllerから画面遷移/画面作成処理を引き受ける
    - 遷移先のViewControllerの作成
    - 画面遷移の方法を一元管理

である．これにより，ViewControllerの責任を分離することが出来るので，Fat ViewControllerを避けることができるというメリットがある．


###参考文献
[What is Application Architecture](https://www.wisegeek.com/what-is-application-architecture.htm)
[iOSアプリ設計パターン入門](https://peaks.cc/Mah_labo/iOS_architecture )(これは文句なしのウルトラ神書籍!)
[VIPERアーキテクチャ まとめ](https://qiita.com/hicka04/items/09534b5daffec33b2bec)