Clean Architectureとは?

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


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

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

e70a4605-e066-b0c2-5c6e-678c71d595ce

参照:http://qiita.com/koutalou/items/07a4f9cf51a2d13e4cdc

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

①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を使うことのデメリット>

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

[iPhoneアプリの制作参考テキスト]

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中