フロントエンドのディレクトリ構造

凝集度を高めるためには、役割（component や container）ごとではなく機能（ドメインやページ）ごとにディレクトリを切っていきたい。
それにより各機能に関心を持つコードが１か所にまとまるため、見通しが良くなる、改修時の漏れを防ぎやすいといったメリットがある。

マイクロサービスとの関連性

それってマイクロサービスの文脈で出てくる「カプセル化」と同じことだよなあ、という思いが浮かんだ。
マイクロサービスでは各ドメインごとに境界を設け、その内部でレイヤー化していくわけだけど、その考え方自体は上記の機能別ディレクトリ構造と似通っている。
（マイクロサービスについての理解が浅いので、色々間違っているかもしれないが）

カプセル化した際の状態管理

マイクロサービスの場合はDB自体も分割するが、フロントエンドの場合はどうなる？
フロントエンドにとってのDB = state となるわけだが、それもカプセル化していくべきなのか？

状態をグローバルstateとして扱う必要がない場合

要するに、状態と機能が１：１になっている場合。
フロントで複雑な状態管理を行わないアプリケーションだと、このような形になっていることも多いと思う。
この場合は何の迷いもなく、カプセル化の中に含めていけばOK

状態をグローバルstateとして扱う場合

上記に対して、状態と機能が１：n になっている場合。
フロントでの状態管理が複雑化し、Redux が欲しくなってくるようなアプリケーションだと、上記のように各ドメインの状態をグローバルstateとして扱う場面も増えると思う。
この場合、状態をカプセル化の中に含めてしまうと、「このドメインの状態を複数の機能で利用する」というコンテキストが薄れてしまう。
よって、 storeはカプセル化せずに別ディレクトリとして切り出した方が自然な気がする。

ついでに汎用コンポーネントについて

ここまで書いて、「汎用コンポーネントもカプセル化できないじゃん」と思い至った。
「重複を恐れず、ドメインを超えた共通化は避ける」という考え方もあるが、それをＵＩに当てはめるのは無理がある。
ボタンや見出しといったＵＩをアプリケーション内で統一する必要がある以上、コンポーネントの完全なカプセル化は難しい。（もちろん各ドメイン固有のコンポーネントは除く）

まとめ

• 機能に沿ったカプセル化（ features ディレクトリ的なやつ）は有効だと思う
• Redux を導入した場合、 features ディレクトリとは別に管理したい
• コンポーネントは汎用コンポーネントと固有コンポーネントに分け、固有コンポーネントのみ features ディレクトリで管理したい

そういえばマイクロフロントエンドって最近どうなってるんだろうか。
上手く運用している事例があれば知りたい