送金プログラムのiOSサンプル(Swift)を,様々なソフトウェアアーキテクチャで実践したものです。
他のサンプルを見てもAPIに認証が必要であったり,画面がいくつもあったりして,アーキテクチャの勉強をしているのか,それとも他の複雑なプログラムの勉強をしているのか分からなくなります。
そこで,簡単な1画面のプログラムを,オフラインで動作するように作成しました。 比較がしやすいよう,git branchで切り換えるのではなく,UISplitViewControllerを用いて1画面で確認できるようにしました。
WatanabeさんからTakahashiさんへ,一方通行にお金を送金するプログラムです。
-
RESETボタンを押すと,Watanabeさんは0に,Takahashiさんは1000に初期化されます。
-
TRANSFERボタンを押すと,Watanabeさんは-100,Takahashiさんは+100されます。
-
Watanabeさんが0の場合にTRANSFERボタンを押すとErrorのアラートが表示され,キャンセルされます。
Presentation Domain Separationの略。プレゼンテーションロジックとドメインロジックが分離されることで,
プレゼンテーションとドメインの分離 - Martin Fowler's Bliki (ja)
- プレゼンテーションロジックとドメインロジックが分かれていると、理解しやすい 同じ基本プログラムを、重複コードなしに、複数のプレゼンテーションに対応させることができる
- ユーザーインターフェイスはテストがしにくいため、それを分離することにより、テスト可能なロジック部分に集中できる
- スクリプト用のAPIやサービスとして外部化するためのAPIを楽に追加できる(選択可能なプレゼンテーション部分で見かける)
- プレゼンテーション部分のコードは、ドメイン部分のコードと違ったスキルと知識が必要
のメリットを享受することができる。
- Presentation (inherited UIViewController)
- Domain
(なし)
- PresentationDomainSeparation - Martin Fowler
- プレゼンテーションとドメインの分離 - Martin Fowler's Bliki (ja)
- MVCとかMVVMの前の自分まとめ - メモを揉め
- MOVEは望まれなかった子 - the sea of fertility
(なし)
Viewはアプリケーションの表示に関わるオブジェクトを定義し,ControllerはViewにおけるアクションの定義および遷移に関わる処理を,Modelにはデータおよびその処理を担う。 この時,ViewとModelはControllerを必ず経由し,ModelにはUIに関わるロジックは含まれない。 プレゼンテーションロジックとドメインロジックの分離に適した設計。
https://developer.apple.com/library/archive/documentation/General/Conceptual/DevPedia-CocoaCore/Art/model_view_controller_2x.png
ちなみに,
MVC is central to a good design for a Cocoa application. The benefits of adopting this pattern are numerous. Many objects in these applications tend to be more reusable, and their interfaces tend to be better defined. Applications having an MVC design are also more easily extensible than other applications. Moreover, many Cocoa technologies and architectures are based on MVC and require that your custom objects play one of the MVC roles.
と,Apple側の多くの設計はMVCに基づいていることが明記されている。
MVCの理解にはしばしば誤解があると言われる(議論を参照)。
- Model
- View
- Controller (inherits UIViewController)
(なし)
- MVC - Apple Developer
- iOS開発でのMVCとは - スタック・オーバーフロー
- これが最強のMVC(iOS) - Qiita
- iOS Architecture Patterns; Demystifying MVC, MVP, MVVM and VIPER – Medium
- MOVEは望まれなかった子 - the sea of fertility
- やはりお前らのMVCは間違っている - SlideShare
- Ruby on Railsの「えせMVC」の弊害 - Life is beautiful
- やはりおまえらの MVC は間違えている in バックボーンジェーエス - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
- Model
- View (inherits UIViewController)
- Presenter
(なし)
(なし)
- Model
- View
- ViewModel (inherits UIViewController)
(なし)
- UserInterface (inherits UIViewController)
- Application
- Domain
- Entity
- Infrastructure
(なし)
(なし)
(なし)
- ViewController (inherits UIViewController)
- Reducer
- State
- Actions
(なし)
(なし)
- ViewController (inherits UIViewController)
- Reactor
(なし)
(なし)
https://s3.amazonaws.com/ckl-website-static/wp-content/uploads/2016/04/viper_architecture-2000x720.jpg
- ViewController (inherits UIViewController)
- Interactor
- Presenter
- Entity
- Router
- Protocols
(なし)
- iOS Project Architecture : Using VIPER [和訳]
- iOS Project Architecture: Using VIPER - Cheesecake Labs
- Juanpe/Swift-VIPER-Module
(なし)
依存関係逆転の原則(Dependency Inversion Principle)によって
https://8thlight.com/blog/assets/posts/2012-08-13-the-clean-architecture/CleanArchitecture-8d1fe066e8f7fa9c7d8e84c1a6b0e2b74b2c670ff8052828f4a7e73fcbbc698c.jpg
- Application/
- Wireframe
- Builder
- Data/
- Repository
- DataStore
- Entity
- Domain/
- UseCase
- Translator
- Model
- Presentation/
- Presenter
- UI/
- View
- ViewController (inherits UIViewController)
- The Clean Architecture | 8th Light - 8th Light Blog
- クリーンアーキテクチャ(The Clean Architecture翻訳) - blog.tai2.net
- まだiOS Clean Architecture で消耗してるの? 爆速開発ツールを作ったのでご紹介 - Qiita
(なし)
https://github.com/kzaher/rxswiftcontent/raw/master/RxFeedback.png
- View
- ViewController (inherits UIViewController)
- State
- Event
(なし)
この設計で実装する最低限の機能を実装したViewController。保存処理も含めない。 「最低限動く」このVCにユーザー管理の分割や保存処理を追加したものが各アーキテクチャで構成される。
保存処理を実装していない為,値の保持や他のViewとの連携は行われない。
- ViewController (inherits UIViewController)
(なし)
(なし)
- 開発者が知っておくべき、6つのUIアーキテクチャ・パターン - @IT
- Androidアーキテクチャことはじめ ― 選定する意味と、MVP、Clean Architecture、MVVM、Fluxの特徴を理解する - エン転職
本リポジトリは,ソフトウェア設計における情報を統一しようと試みるものであり,設計そのもの及び歴史に関する誤謬を含んだものであることを断っておきます。本記事及びコードが正確であることを保証するものではありません。そもそも設計方針であって,単体で1アーキテクチャとして成立するとは言い難いものもあります。本リポジトリは全てのアーキテクチャを網羅するものではなく,それぞれを比較し,優劣をつけるような意図はありません。