featureという単位で分ける基準
何がfeatureなのか
ならば、featureとして捉える基準をわかりやすくしたい
MVCのmodelとかviewとかcontrollerが技術、というのは分かるが
TaskとかUserが技術ではない、というのも分かるが
しかし、MVCだってアプリケーション上で使っている概念で、区別が難しいかもしれない
関係性から捉える
ここで、以下の２つの登場人物を、その関係性を持って捉え直してみよう
MVCとかhooks, componentsといった「技術上の名前」と
featureという名前で表されるもの
ここで、「登場する概念には、必ず依存関係のグラフを引ける」という事実を用いよう 例えば
「Task」を実現するために、MVCフレームワークを使う
「Form」を実装するために、react のcomponentで書いたり、hooksを使う
featureを実現するために、技術（あるいはフレームワーク）を使っている
AがBを使っているとき、Aが目的であり、Bが手段である
featureとその実装技術の関係は目的と手段であるとすると理解しやすい code:txt
Task -use-> MVC
さらに、featureというものはなぜ存在するのかと言うと「webアプリケーションを作りたいから」である
例えば
Todoアプリを作りたいから
Task, User, DueDate, Assigneeというfeatureが存在する
code:txt
Todoアプリ -use-> Task, User, ...
ここでの「アプリ」と「featureの関係性」は
目的と手段とも思えるが、100%そうではない
「TODOアプリを作るという目的に対して、Task, User, DueDate, Assigneeというfeatureは、手段である」
合ってはいるが
Todoアプリを作るために必要なものは、作成者やニーズによってケースバイケース。
なので、手段の一種、である
必要ではあるが、選択肢の一つである
ここでは「設計」あるいは「戦略」と言うほうが、より適切ではないか
Todoアプリを作るために、それの構成要素としてTask, User, DueDate, Assigneeがfeatureとして必要と「設計」した
関係性のまとめ
以上の関係性をまとめるとこうなっている
作りたいアプリ
↓設計（戦略）
feature
↓実装（戦術）（上が目的で、下が手段）
ここでは、「戦略」という名前に呼応させて、実装部分の技術選択を「戦術」とも呼んでみた。
技術
この流れがあるからこそ、
コードをまとめる単位は、featureであるべきで、
以上の関係性が変わらない限りは（設計部分で、featureよりも荒い何らかの粒度が挟まらない限りは）
その関係性が、ソースコードのフォルダ構成、パッケージ構成でそのまま現れるように構成すると良い
そうしたほうが、認知コストが減らせる
リポジトリトップ、あるいはsrcフォルダ直下などに
Task, User, DueDate, Assigneeといった名前がフォルダやファイル名としてドンと見えてくるべき
code:folder
src/
task/
user/
dueDate/
assignee/
...
まとめ: featureという概念がどういうものなのか
ここでは、ここでのfeatureという言葉自体の定義はしない
あくまで、一般的な英単語の延長として使っている
ここでいうfeatureとは
「アプリを作る」という目的のための構成要素、および抽象的な設計
featureの名前自体には、それを実現するための技術的要素を含まない
featureを実装するために、諸々の技術が要請される
---
また、こういったfeatureとして現れるものはドメイン駆動設計におけるドメインオブジェクトなどとして捉えることも可能かもしれない ただし、以上の主張は、DDD特有の概念を用いてない
別の出発点から初めて、近い結論を導いている、ということが重要
参考