ディレクトリ・パッケージの分割方法の議論

[Yamasaki-pan961]

関連PR

• docs: ARCHITECTURE.md の更新 #92

現状

coresの中にcoreがある状態で、違和感がある。（言語化がむずかしい、、）

packages
├── cores
│   ├── core
│   │   └── lib
│   │       └── src
│   │           ├── exception
│   │           └── ui
│   ├── data
│   │   └── lib
│   │       └── src
│   │           ├── network
│   │           └── shared_preferences
│   ├── designsystem
│   │   ├── lib
│   │   │   └── src
│   │   │       ├── components
│   │   │       └── themes
│   │   └── test
│   └── init
│       └── lib
│           └── src
│               └── provider
└── features
    ├── debug_mode
    └── github_repository

提案

now in androidに合わせて
cores/coreをcore/commonに変更する。

core/commonの中には汎用的な拡張関数などが入ると思われます。

now in androidを理由に提案していますが、わかっていないところもあり、、
ただより改善できるかもしれないというところで提案してみました！

packages
├── core
│   ├── common // プリミティブ型の拡張関数などが含まれれ、core内の他のパッケージに依存しない
│   ├── model // アプリ特有のモデルを持つ
│   ├── domain // アプリのUseCaseなどのビジネスロジックを持つ
│   ├── data // リポジトリ的な役割？
│   ├── network // API呼び出しの定義
│   ├── localdata // ローカルデータとして保存するロジックを持つ ??
│   ├── ui // 意味のあるアプリ情報を持つコンポーネントが含まれる
│   ├── designsystem // アプリ情報を持たないコンポーネントが含まれる
│   └── init // appに移して良いかも？
└── features
    ├── debug_mode
    └── github_repository

[warahiko]

提案ありがとうございます！

大枠としてはよさそうに感じました 👍
cores/ 内の全てのパッケージが core だよね、って感じですかね
そこの名前付けたの自分ですが、こだわりがあったわけではないですし、個人的には特に問題なさそうです

以下数点、もしかしたらただの例で本筋とは関係ないかもしれないですが気になった点として

• cores にはしないのか気になりました
  • ディレクトリ名に関して単複どちらにするのかは決めかな、とは思うのですが、プロジェクト内で一貫してないのは気になります
  • （now in android を見ると混じってるので、英語圏にとってはどっちでもいいかもしれないですが......
• data, network, localdata であるとか、model, domain なんかをこのように別々にするかは悩ましい気がしました
  • 粒度が細かすぎると管理が難しくなりますし、ビルドが複雑になって逆に時間がかかってしまう、ということも考えられます
  • ゆめみでのプロジェクトは基本的にそんなに大きくないはず？ということを考えるとある程度統合されているほうがメリットが大きいかもしれません？
• ui, designsystem の違いがいまいち掴めませんでした
  • ui のほうはこのアプリ特有のレイアウト、みたいな感じ？
• init に関しては消せるように検討するとよさそうですね 🙆

[Yamasaki-pan961]

@warahiko
早速ありがとうございます！！
質問ごとに分けてコメントしようとおもいます！
質問ごとに返信先を分けていただければ助かります。

（ディスカッションをあまり使い慣れてないです orz）

[Yamasaki-pan961]

cores にはしないのか気になりました

自分の感覚ではcoreの方がしっくりきます
自分の感覚を説明すると、coresだとその配下はそれぞれ「コア」と呼べる状態であると思いました。
以下のような構成になると、modelやdomain単体では「コア」ではなく「コアを構成する1要素」だと思っていることがcoresではないと思う理由となります

packages
├── cores
│   ├── common
│   ├── model
│   ├── domain

[tatsutakein]

私は core s にするかどうかは強い意志があるわけではないので、認識が統一できればいいなくらいの温度感です 🙆

[blendthink]

@Yamasaki-pan961 CC: @tatsutakein
個人的には cores の方がしっくりきます。
というのも features の方と同じで cores だとコアなパッケージが複数あるということがわかり、いいかなと思いました。
core 自体がパッケージであれば core で良さそうで、core の中にパッケージが複数あるのであれば cores のほうが個人的にはしっくりきまうs。

[Yamasaki-pan961]

data, network, localdata であるとか、model, domain なんかをこのように別々にするかは悩ましい気がしました

ほんとに悩ましいですよね、、、
どの方法を取っても「完璧」とはならないと思っています。

以下の視点は考え付かなかったので、より悩ましくなりましたね。

• 粒度が細かすぎると管理が難しくなりますし、ビルドが複雑になって逆に時間がかかってしまう、ということも考えられます
• ゆめみでのプロジェクトは基本的にそんなに大きくないはず？ということを考えるとある程度統合されているほうがメリットが大きいかもしれません？

この視点が増えたことでcores/coreのメリットが見えてきました。

例えば、自分の提案のディレクトリ構成で、「ビルドが複雑になって逆に時間がかかってしまう問題」を解決しようとすると、、

1. coreを一つのパッケージにしようとする
2. coreが肥大化するのである程度は別パッケージに分けたい
3. cores/coreとcores/otherとなる

悩ましいですね、、、

増やした時のmelos bsの時間を計測してみるのが良さそうですね

[blendthink]

@Yamasaki-pan961

│ ├── common // プリミティブ型の拡張関数などが含まれれ、core内の他のパッケージに依存しない
│ ├── model // アプリ特有のモデルを持つ
│ ├── domain // アプリのUseCaseなどのビジネスロジックを持つ
│ ├── data // リポジトリ的な役割？
│ ├── network // API呼び出しの定義
│ ├── localdata // ローカルデータとして保存するロジックを持つ ??
│ ├── ui // 意味のあるアプリ情報を持つコンポーネントが含まれる
│ ├── designsystem // アプリ情報を持たないコンポーネントが含まれる
│ └── init // appに移して良いかも？

core ではなく common という命名でもいいと思います！（どちらがわかりやすいのか微妙なところですね、、）

プロジェクトの規模などによってどこまでパッケージ分割するか悩ましいところかなと思うので、あまり最初から細かく分けすぎない方が個人的にはいいかなと思いました。

[Yamasaki-pan961]

ui, designsystem の違いがいまいち掴めませんでした

• ui のほうはこのアプリ特有のレイアウト、みたいな感じ？

説明が難しいですが、以下のように認識しています
designsystem: material uiのwidgetのように単体ではアプリ上の情報や意味を持たないWidget群
ui: Widgetを組みあわせてmodelクラスの情報を表示するようなWidget群

[tatsutakein]

起票ありがとうございます！
パッケージを分割した結果、多くなって混乱してしまうという事態もあるのかなと思い、ある程度役割が同じものはまとめたり削除したりしてもいいかもと思いました。

具体的には、最初にご提案いただいた内容から以下の変更を加えると良さそうかなと考えています。

• ui パッケージは除外
  • ややこしくなってしまうくらいであれば、各 feature パッケージで実装するのでも良いのかなと
• data, network, localdata パッケージを data パッケージとして集約する
  • データ操作をこちらに集約してしまっても良いかもです

packages
├── core
│   ├── common // プリミティブ型の拡張関数などが含まれれ、core内の他のパッケージに依存しない
│   ├── model // アプリ特有のモデルを持つ
│   ├── domain // アプリの UseCase などのビジネスロジックを持つ
│   ├── data // network, localdata の実装を内部に持ちつつ、パッケージ外にはリポジトリのみ公開
│   └── designsystem // アプリ情報を持たないコンポーネントが含まれる
│ 
└── features
    ├── debug_mode
    └── github_repository

依存関係を図で表すとこんな感じになるので、わりとスッキリしそうだなと思っています。

[Yamasaki-pan961]

@tatsutakein
議論に関係ないですが、
この依存関係図ってツールとかで作れるんでしょうか？気になります

[Yamasaki-pan961]

@tatsutakein cc @warahiko
丁寧に提案していただきありがとうございます。
めちゃめちゃ良いと思いました。

ただ、uiパッケージはあったほうがいいかな、、と個人的には思います。
浅い経験ですが、複数のfeatureでモデル情報を表示するWidgetなどを使い回す可能性は多いかなと思ったり。

以下の説明があればWidgetの分別できるとは思っていて、ややこしさは少ないと思っていたりします。

designsystem: material uiのwidgetのように単体ではアプリ上の情報や意味を持たないWidget群
ui: Widgetを組みあわせてmodelクラスの情報を表示するようなWidget群

[tatsutakein]

この依存関係図は職人のお手製（）です。笑
個人プロジェクトで作ってたので、ちょこっと手を加えて作成していました！

ui パッケージについても、混乱するくらいならば…くらいの温度感でしたので私は賛成です 🙆

[blendthink]

@Yamasaki-pan961

以下の説明があればWidgetの分別できるとは思っていて、ややこしさは少ないと思っていたりします。
designsystem: material uiのwidgetのように単体ではアプリ上の情報や意味を持たないWidget群
ui: Widgetを組みあわせてmodelクラスの情報を表示するようなWidget群

たしかにこのようにすれば混乱も発生しなくていいかもしれませんが、 こちら の話と同じで、最初はあまり分割せずに、必要になったタイミングでパッケージとして切り出してもいいかなと思いましたが、いかがでしょう？
というのも、初めから切り出してしまうと、実は１つの feature パッケージでしか結局使わなかったとか出てきそうで、、

もちろん、案件のデザインシステムのようなものができて、そこで取り決められたものがあれば、提案していただいたようなパッケージ分割したほうがいいかなと考えています、、！

[Yamasaki-pan961]

@warahiko @tatsutakein @blendthink
議論していただきありがとうございます！
皆さんの意見をまとめると次のように方針になると思います。認識が合っているかご確認お願いします。

1. パッケージを細かく分けすぎない

• プロジェクトの規模などによってどこまでパッケージ分割するか悩ましいため
• 粒度が細かすぎると管理が難しくなる
• ビルドが複雑になって逆に時間がかかってしまう可能性がある

2. package/coresとする

core 自体がパッケージであれば core で良さそうだが、中にパッケージが複数あるのであれば coresとなりそう

フォルダ構成

以上の方針をフォルダ構成に適応すると @tatsutakein さんが提案してくださった形がしっくりくると思ったのですがどうでしょうか？

coreかcommonはどちらがわかりやすか？というところは、
内容が「プリミティブ型の拡張関数などが含まれれ、core内の他のパッケージに依存しない」ものであればcommonが適切だと思われます。

packages
├── cores
│   ├── common // プリミティブ型の拡張関数などが含まれれ、core内の他のパッケージに依存しない
│   ├── model // アプリ特有のモデルを持つ
│   ├── domain // アプリの UseCase などのビジネスロジックを持つ
│   ├── data // network, localdata の実装を内部に持ちつつ、パッケージ外にはリポジトリのみ公開
│   └── designsystem // アプリ情報を持たないコンポーネントが含まれる
│ 
└── features
    ├── debug_mode
    └── github_repository

[blendthink]

@Yamasaki-pan961
取りまとめありがとうございます！

１・２については認識あっています 🙆‍♂️

ただ、個人的にフォルダ構成については現状のままでいいかなと思いました。
というのも、１の理由からです。

cores 配下のパッケージは参照される数が一番多くなる場所なので、できる限り増やさずに、app や features 内に実装して、各プロジェクトで必要になったら cores 配下に実装して、 cores の core などのパッケージが肥大化してきたらパッケージ分割することを検討していったほうが余計なコストをかけずにいいかなと思いました。

[Yamasaki-pan961]

@blendthink
ありがとうございます！
「現状のフォルダ構成を引き続き使う」という結論で良いと思います。

提案のようなフォルダ構成になった理由は、このテンプレートを「設計や方針の指針となるもの」と自分が勝手に考えていたからです。

各プロジェクトで必要になったら cores 配下に実装して、 cores の core などのパッケージが肥大化してきたらパッケージ分割することを検討して

例えば、上記のような検討をする際に「どのように分けるか」がわかりやすく示されていたらいいなと思い、分け方を詳細にドキュメント化できたらいいな〜と思っていました。

[Yamasaki-pan961]

[結論] フォルダ構成は現状のまま

[理由] 以下の方針で進めるため

1. パッケージを細かく分けすぎない

• プロジェクトの規模などによってどこまでパッケージ分割するか悩ましいため
• 粒度が細かすぎると管理が難しくなる
• ビルドが複雑になって逆に時間がかかってしまう可能性がある
• 分けすぎると手間だけが増える可能性もある

2. package/coresとする

core 自体がパッケージであれば core で良さそうだが、中にパッケージが複数あるのであれば coresとなりそう

感謝

@tatsutakein @warahiko @blendthink
議論に参加していただきありがとうございます。
おかげで、新たな視点を得ることができました🙇‍♂️