機能単位パッケージング
#パッケージング
/miyamonz/戦略と戦術、目的と手段という観点からモジュール分割を捉え直し、feature単位でまとめよう
@adelie_pf: よくReactでこういう「種類別」になってるプロジェクト見かけるけど、必ず辛みがますので全て「機能別」のプロジェクトになってほしい。
https://pbs.twimg.com/media/FpU0RTzacAAmoeN.pnghttps://pbs.twimg.com/media/FpU1AgbaIAEoiqh.png
機能, 役割単位でパッケージングするやり方
フィーチャーごとに戦略を変えやすい
高凝集になるので、モジュール性やリグレッション管理もろもろメリットが大きい
安易に共通化するとカオス化しやすい
見た目は同じだけど概念上やデザイン上は別の意味を持つUIがあったりする
ディレクトリ, ファイルを細かく分けてもその境界は曖昧になりがち
最初に一気にレイヤを決めるのが(特にフロントは)は難しい
SPAでのレイヤードアーキテクチャの考察と不確実性へのマインドセット
機能ごとに独立させてある程度の重複は恐れないパッケージングがなんだかんだ、開発効率がいい
機能は追加よりも変更したり削除するほうが難しい
最初が一項目だったとしても関心の成長軸を作っておき、変化の際に既存の構造を変更せずに"追加"で対処できる構成を目指す
機能を横断した知識が重複していると誰が見ても明らかなときに初めて共通化するか検討する
共通化と抽象化
共通部分をスマートに管理するディレクトリ構成
GUIつくるときだとWeb APIがResource-based Web APIかUsecase-based Web APIによってよく考えるべし
Resource-based APIとUsecase-based APIの勘所
Resource-based Web APIだと同じリソースを使い回す場面もあるため、完全に機能別だと不都合起きがち
主語->動詞->目的語(SVO)の順に深くする
ほか
/mrsekut-p/Package by Feature
package by feature のススメ
アンチパターンを理解して package by feature へ
Feature-Sliced Design
Vertical Slice Architecture
https://www.notion.so/Vertical-Slice-Architecture-a9528578ffd74b129e3f70a7ae1df282