Flutterを利用していて、クリーンアーキテクチャ(Clean Architecture)に触れる機会が多く、まとめてみました。
あくまで私なりの理解で備忘録として記載していますので、クリーンアーキテクチャ(Clean Architecture)の理解を深めるための参考程度にご覧いただき、どなたかの参考になれば幸いです。
目次
クリーンアーキテクチャとは(Clean Architecture)
- Robert C. Martinが提唱した
- DBやフレークワークから独立性を確保するため
- 複数のレイヤーに分割して設計するアーキテクチャ
- 有名な図がある
- アプリなどのソフトウェアを実装するのに
- クラスや モジュールなどをどのように分割すればいいのかを考えたモノ・ヒント
- テストが簡単にできる
- 効率的に仕様変更ができる
- 少ない工数で機能追加やコード修正可能か
- クラスや モジュールなどをどのように分割すればいいのかを考えたモノ・ヒント

クリーンアーキテクチャにおける依存関係
- 依存の関係は「内側」にある、向いている
- 4つのレイヤー
- Enterprise Business Rules
- Applicaiton Business Rules
- Interface Adapters
- Frameworks & Drivers
- 分割方法より「依存関係を整理すること」が大切

クリーンアーキテクチャにおける4つのレイヤー
Enterprise Business Rules
- 円の一番内側に存在する
- Entity
- アプリで利用するデータ用のオブジェクト
- User,Accountなど
- アプリで利用するデータ用のオブジェクト
Applicaiton Business Rules
- ユースケースの層
- アプリ特有のビジネスロジック
- フレームワークやデータベース等の外部に依存しない
- Entityに依存する
Interface Adapters
- DBやAPIから取得したデータを使いやすいように整理
- 次のレイヤーであるユースケースが使いやすいように
Frameworks & Drivers
- 一番外側に存在するレイヤー
- UIに関するコード
- フレームワークに関するコード
Flutterに置き換えた時の参考例
理解を深めるために簡単にFlutterを使用する場合の参考例をまとめました。
Presentaion層
- UIに関するディレクトリを配置
- Providers
- Widget
- Page
Domain層
- ビジネスロジックとEntityを配置
- Usecase
- Entity
- Repositories
- DomainとDataの繋ぎ役
- 両方に置いておく
Data層
- データに関するもの
- Model
- データの型
- DataSouse
- APIやDBの呼び出し
- Repositories
- DomainとDataの繋ぎ役
- 両方に置いておく
- Model
全体について
- 3つの層をはっきりさせる
- RepositoriesでDataとDomainをうまく繋ぐ
- Usecaseを直接呼ぶのではなく
- Providersを経由して
- UIを表示する
2つのルールについて
「ビジネスルール」と「アプリのビジネスルール」についていちばん引っ掛かり気になったのでまとめました。
ビジネスルール
- そのアイデアやプロダクト全体のルール
- システムのルールや手続きのこと
- お店を例に挙げると商品、カート、注文、ユーザーなど
アプリのビジネスルール
- アプリ独自のルール
- ユーザー情報を保存する機能の場合
- アプリで利用するデータ用のオブジェクト
- 全ての値が正常値か検証
- 正常であればユーザーを更新 、生成するなど
- アプリで利用するデータ用のオブジェクト
最後に
簡単にクリーンアーキテクチャ(Clean Architecture)についてまとめてみましたが、もう少し具体で深掘りたいので今後も記事の改善と関連記事も書けたらと思います。
ではまた。
コメント