iOS CleanArchitecture(クリーンアーキテクチャー)

Clean Architectureとは、一言で言うとドメイン駆動開発（DDD）やユースケース駆動開発（UCDD）を意識して、ビジネスロジックをUIやFrameworkから引き離し、それぞれの層毎に役割と責任を分離したArchitectureになります。

DDD（ドメイン駆動開発）のDomain層・Data層のレイヤーを細分化したモデルです。

Clean ArchitectureはFlux Architectureと同様にデータの流れが一方向性にし、 曖昧なModelという概念をさらに明確に役割分解し、変更機会が多い、UIや外部ソースを一番外側に置き、Entityを一番内側に置いた考え方です。 これならViewControllerがもつロジックも、例えばUse CaseとViewController の間にPresenterを間に入れてそれを実行すれば解決します。

■各レイヤーの役割と説明

①Presentation Layer(UIの表示、イベントのハンドリングを行う)

・View→UIを指す。タッチや操作のイベントをPresenterへ渡す。 ・Presenter→Viewのイベントに応じたUseCaseを実行する

②Domain Layer(IOS依存のロジックを記述)

・UseCase→どのデータをどのように取得するかを記述する(Viewから参照されない) ・Translater→UseCaseから取得したEntityをPresentation層で使用するModelへ変換する。 ・Repository→UseCaseで取得したデータのCRUD相当のI/Fを記述

③Data Layer(通信やデータ管理のロジックを記述)

・DataStore→データを実際に取得・更新する処理を記述。iosではAPI通信やRealmの実装に該当する。 ・Entity→DateStoreで扱うことができるデータの静的モデル

Clean Architectureを使うことのメリット

• ビジネスロジックが明確になる
• フレームワークに依存しない
• UIに依存しない
• ビジネスロジックを変えずにUIのみ変更することができる
• Data Storeに依存しない
• データ連携先がサーバでも、端末内のDBでもビジネスロジックに影響が無い
• ビジネスロジックは、データの保存先や取得先を知らないくて良い
• テストの容易性
• 全ての層でテストが導入しやすい

Clean Architectureを使うことのデメリット

• コード量が多い
• 役割毎に層が多くなるため、必然的にコード量が多くなります。

詳細！Swift 4 iPhoneアプリ開発 入門ノート Swift 4+Xcode 9対応

[改訂新版]Swift実践入門 ── 直感的な文法と安全性を兼ね備えた言語 (WEB+DB PRESS plus)