はじめに
- CyberAgentのインターンで触れたアーキテクチャである、Flux, Clean Architectureについての個人的な見解を述べるだけです
- 「アーキテクチャはこうあるべき」みたいな原理主義的な話はしません
この記事で書くこと
- Fluxの特徴
- Clean Architectureの特徴
- MVVM × Clean Architecture
Fluxの特徴
FluxはFacebook社が作成したアーキテクチャパターンで、もともとはJSで使われていたものです。
各要素の役割として以下の通りです。
-
Dispatcher: 発火されたActionをStoreに通知するもの -
Action: Viewなどから発火されたEventをDispatcherに通知するもの -
Store: Dispatcher経由できたActionに応じて、データを管理するもの -
View: StoreのデータをUIに反映させるもの、ユーザー操作に応じてActionを発火するもの
メリット
- データの流れが単一方向であること
- DispatcherやActionがシングルトンで表される
デメリット
- 規模が大きくなると、Actionが肥大化する
- Recycler Viewなど動的にリストビューを作成する処理をActionに書かなければならないため、関心の分離を満たせない場合がある？
- ビジネスロジックのみを完全に分離できない
- KMM(Kotlin Multiplatform Mobile)等への対応が難しい
- CyberAgentでもKMMへの対応
MVCとの違い
よく比較されるアーキテクチャとして、MVC(Model View Controller)があります。Model, View, Controllerの役割としては以下の通りです。
-
Model: システムの中でビジネスロジックを担当する -
View: データ表示や入出力の処理をする -
Controller: ユーザーの入力に基づき、ModelとViewを制御する
しかし、MVCには規模が大きくなるにつれ、ViewとModelの依存関係が複雑になる問題点があります。例えば、A画面ですでに生成されたModelを参照しながら、A画面内でもう一度同じModelを参照したい場合もあるかもしれません。そういった場合の依存関係は複雑になります。規模が大きくなればなるほど、この問題は顕著になります。
以下の画像がわかりやすかったので参考までに載せておきます。
Clean Architectureの特徴
Clean Architectureはレイヤードアーキテクチャ（責務のまとまりをレイヤーとし、それらを組み合わせて構成されるアーキテクチャ）の一つです。以下の画像で表されることが多いです。
ですが、この図は個人的にとてもわかりづらいのでAndroidアプリを作成する際によく採用される、MVVM×Clean Architectureの図を作ってみました。このアーキテクチャはClean ArchitectureにMVVM（特にViewModel）を組み込んだアーキテクチャです。
各レイヤーの役割としては以下の通りです。
-
プレゼンテーションレイヤー: UIなどユーザーにどう見せたいか制御する責務を持ちます（上の図ではUIレイヤーとしています） -
アプリケーションレイヤー: ドメインレイヤーの抽象化された振る舞いを具象化し、アプリケーションで使用しやすい形に変換する責務を持ちます。 -
ドメインレイヤー: データレイヤーで取得したデータをドメインに変換する責務を持ちます -
データレイヤー: 上位のレイヤーで使用するデータやライブラリを扱う責務を持ちます
メリット
- 機能改善がしやすくなる
- 関心の分離の原則により、関心事がしっかりと分かれているので機能改善・追加がしやすい
- テストがやりやすくなる
- はじめにEntitiesだけをテスト→UseCaseだけをテスト→Presentation層のテストみたいな感じに、テストを細かい粒度で行えるようになる
デメリット
- 実装コストが高い
- 書くコード量はMVCの1.5倍くらい？
- →早く実装しなければならないチーム・プロジェクトには向かないかも？
まとめ
CyberAgentのインターンで触れたFlux、Clean Architectureについてまとめてみました。
今回自分なりに言語化してまとめてみたことで、それぞれのアーキテクチャへの理解が深まった気がします。また、それぞれ特徴があり「こっちの方が絶対に良い」のようなことはないということを感じました。
今後もこのような記事を投稿し、多くのアーキテクチャに関して比較・検証をしていきたいと思います 💪