コンポーネント指向のディレクトリ構成・命名・役割の分担について

実現したいこと

小説・漫画などの書籍をまとめた本棚アプリを作るにあたっての
・ディレクトリ構成、命名についての理解
・ディレクトリ単位の役割の分担についての理解

前提

features ->novel（小説） 　->components 　　->pages 　　　->list.ts 　　　（一覧ページ） 　　　->retrieve.ts 　　　（単体ページ） 　　　 　　->containers 　　　->list.ts（一覧ページ） 　　　->retrieve.ts（単体ページ） 　　　->retrieve-detail-relation-cards.ts（単体ページの関連小説一覧） 　　　　※API実行 　　　->retrieve-comments.ts（単体ページの小説コメント一覧） 　　　　※API実行 　　　　※トップページからも利用 　　　->list-cards.ts（小説一覧） 　　　　※API実行 　　　->list-cards-pagination.ts（小説一覧+ページング） 　　　　※トップページからも利用 　　　->list-cards-filter.ts（小説一覧+フィルタリング） 　　　->list-cards-pagination-filter.ts（小説一覧+ページング+フィルタリング） 　　　 　　->presenters 　　　->list-card.ts（一覧ページ用の簡易な小説情報） 　　　->retrieve-detail-card.ts（単体ページ用の詳細な小説情報） 　　　->comment.ts（コメント） 　　　 ->comic（漫画） 　->...省略 　 ->home（トップページ） 　->...省略

役割

◆ pages
・ルーティング

◆ containers
・APIからデータの取得・状態管理
・ロジック、データ加工

◆ presenters
・UI

質問内容

1. 「ページ名 + 機能 + 機能 + ...」の命名規則でファイル名を定義しているのですが、ただただ冗長で融通の効かない印象なのですがこういうものなのでしょうか？それとも根本的に間違っているのでしょうか？

2. 「小説一覧」「ページング」「フィルタリング」の各コンポーネントを組み合わせて一つのコンポーネントとして作成する際に、都度似たようなコンポーネントを作っていくのでしょうか？
   たとえば、ページングを無限スクロールにする・小説一覧の並びを「grid」「table」「marsonry」にするなどCSSだけでは対応できない場合もあるのでロジックを含んだcontainerを新しく作る必要にかられるのでしょうか？
   そしたら芋づる式にどんどんとコンポーネントが増えていく解釈で恐怖があります。
   （対応させるレイアウトのプロパティフラグを持って可変のレイアウト対応もできるでしょうが、テンプレートを膨らませると碌なことにならないので避けたい所存です。）

3. 役割の考え方は上述の考え方であっているのでしょうか？他のコンポーネントからも利用できるように[containers]でのみAPIからデータを取得する想定とすると、[pages]がただのルータ・ラッパーにしかならない解釈で、[containers]にページのためだけの・実際に出力されるページデザインのコンポーネントを余計に作る必要が生じます。
   ただ、[page]側でapiデータを取得すると今度はコンポーネントの再利用性という観点からも外れてしまう気もしますので、自分の中でどちらにも納得がつかない状況です。

補足情報（FW/ツールのバージョンなど）

angular 18

まとめ

コンポーネント指向の考え方について理解が不十分な上での質問となってしまい、的を得ていない・基本を理解できていない質問になっていたら申し訳ありません。
ただ、個人開発ですのでせっかくなら納得の行く構成にしたいと思い質問させていただきました。
もちろん、この類の設計思想に明確な答えがないことは重々承知ですが、どうか方向性を理解するためにも回答を頂けるとありがたいです。