概要
どうも、@daiki1003です!いきなりですが、Flutterプロジェクトのフォルダ構成はどんな風にしていますか?
この記事を読んでいただいていると言うことは多少なりとも
そこに課題意識があるのかもしれません。
僕も以前から悩んでいるうちの一人です。
#Flutter のフォルダ構成に関して lib フォルダ以下みんながどうしてるのかめちゃくちゃ気になる。
出来ればこのTweetがそんな知見が集まるスレになってくることを祈って…— ashdik(朝日)@Flutter, Wine, BoardGame, Investment (@daiki1003) November 9, 2020
そして、残念ながらまだ最善のフォルダ構成は見つかっていません。
とはいえ、一つの方針を決めて半年くらいやって来ました。
この記事では、
・どんな構成案があったのか?
・その中で、僕が選んだ構成は?
・その構成のメリット・デメリットは?
辺りについて書いています。
🧐どんな構成案があるのか?
🏯アプリのレイヤーに基づいた構成
MVC
lib - controllers - models - views
MVVM
lib - models - views - view_models
Clean Architecture
lib - controllers - domain - - entities - - repositories - - use_cases - presentation
辺りでしょうか。
(多少の語彙などの違いはあると思います)
すごく無難な印象ですね。
マリオシリーズでいうところのマリオ。
ストリートファイターシリーズでいうところのリュウ。
Udemyなどで紹介されるデモアプリでもこの構成が使われています。
🗻Atomic Designに基づいた構成
自分はReduxとAtomic designをよく使うので
lib以下はbusiness
actions
reducer
middleware
models
services
core
custom
ui
atoms
molecules
organisms
pages
templates
themesがメインのディレクトリかもしれないですね🤔
— たーちゃん@Flutter (@Flutter70862657) November 11, 2020
これは主にUI部分だけの話にはなってしまいますが。
Atomic Design
とは、
小さいコンポーネントを組み合わせて大きいコンポーネントにしていく設計手法のこと
です。
…この説明を聞いてピンと来たあなたは相当鋭いと思います。
実はこの思想、ウィジェットを組み合わせてUIを構成する
Flutterとすごく似ているんですよね。
なので、Flutterプロジェクトととても相性が良かったりします。
次に作る小規模なプロジェクトで試してみたいなーなんて思っています。
🔍ドメイン(関心事)に基づいた構成
私の指針としては、
* 小規模アプリは ui/ および model/ フォルダを作る。 これによりPDSだけは守る。あとの構成はご自由に
* 中規模以上で通常複数人が関わるアプリは、<機能名>/ という機能ごとの名前空間用フォルダを作り、その中に小規模アプリ用構成を適用
* 共通部品はlib/以下の浅い階層に配置— ntaoo (@ntaoo) November 9, 2020
lib - notification --- component --- model --- ui - setting - user
機能や関心事ごとにフォルダを切るやり方です。
その他Twitterで寄せていただいた例
lib/ 以下は、
pages/{各画面}/ :各画面の実装
design_system/ : アプリ内で使うfont,space,theme定義を配置
design_system/widgets/ : 共通で使うwidget群
data/ : modelやrepository,dioなどなど適切に配置
utils/ : util,ext系
l10n/: ローカライズ
gen/: 自動生成関連みたいな感じです🍀
— su-🐈 Flutter, iOS, Firebase (@_sgr_ksmt) November 9, 2020
common
helper
master
:
model
repository
:
presentation
pages
widget
:今のアプリだとざっくりこんな感じでした(・∀・)
— 西まりも@アプリ開発/Flutter&Firebase (@marimo_engineer) November 9, 2020
よく作るのは
model/
repository/
repository/entity/
services/
ui/<画面名>/みたいな感じにしてますね。BLoCで作ってるアプリはbloc/があったりします。
あとはtheme.dartみたいなのはlib/直下に置いたりです。参考になればとー。— れの / RenoInn (@renoinn) November 9, 2020
その中で、僕が選んだ構成は?
ズバリ、今は🔍ドメイン(関心事)に基づいた構成を好んで使っています。
その構成のメリット・デメリットは?
🙆♀️メリット
実装しやすいし、可読性高い
一番のメリットと言っても過言ではないです。
このメリットを享受するためのフォルダ構成かなと。
例えば、通知画面を実装する時。lib/notification
だけを見ていれば良いので非常に楽です。
また、他人のコードを読むときも同様にlib/notification
を見れば良いことが一目で分かるので可読性も高いです。
責任がはっきりしている
例えば、オンボーディングを実装済だとします。lib/onboarding
です。
ある日、話し合った結果オンボーディングが必要ないから
アプリから消そうとなったとします。
僕個人としては、やめておいた方が良いとは思いますが。
そんな個人的見解はさておき。
この構成であれば、 lib/onboarding
を消せば一発です。
もちろん、参照関係とかもあるのでコンパイルまでは通らないでしょう。
しかし、ファイルの消し漏れとかはほぼなくなります。
フォルダ毎にカスタマイズ出来る
あるドメインだけ必要なファイルがある場合。
この構成だと、そのドメイン配下にフォルダを作れるので
非常に便利だったりします。
データは用意するけど、画面はないドメインとかも
問題ありません。
そう、この構成ならね (Apple顔)
🙅♂️デメリット
個人的には結構気に入っているフォルダ構成なのですが、
デメリットがないわけではありません。
置き場所に困るときがある
複数の関心事が一つの画面に詰め込まれたりすると
結構万事休すだったりします。
あとは、
– 「友達」みたいな概念があったときに、 ユーザなの?フレンドなの?
– あるユーザの画面に投稿一覧を表示したい場合は、ユーザなの?投稿なの?
の様な悩みは結構尽きなかったりします。
縦に長くなりやすい
これは、まぁ強いて言えばレベルですが。
どうしても中規模以上のアプリになると
関心毎は増えてくるのでルートフォルダが多くなりがちです。
なので、ちょっと縦に長さが出やすくなったりはするのかなと。
最後に
いかがでしたでしょうか?
まだ、この辺は正解がないところではあると思います。
うちではこうしてるよーとか、
もっとこうしたら?的なアドバイスとかどんなものでも嬉しいので
@daiki1003までお願いいたします!
Twitterフォローお願いします
「次回以降も記事を読んでみたい!」「この辺分からなかったから質問したい!」
そんな時は、是非Twitter (@daiki1003)やInstagram (@ashdik_flutter)のフォローお願いします♪
Twitterコミュニティ参加お願いします
Twitterコミュニティ「Flutter lovers」を開設しました!参加お待ちしております😁
☕️ Buy me a coffee
また、記事がとても役に立ったと思う人はコーヒーを奢っていただけると非常に嬉しいです!
コメント