SVO型のパッケージングで機能的凝集を目指すオニオンアーキテクチャ
from
2023/05/26時点のNext.jsでパッケージングするならこうかな〜、というイメージ
ベースはオニオンアーキテクチャ (≒ 機能単位パッケージング)
前提
システムによって味づけ具合は異なる
Webサイト的か、Webアプリ的か、ツール的か
ドメインのことは考えながら作る(Write code thinking)ことを念頭においておく
原則
主語->動詞->目的語(SVO)の流れを遵守する
命名規則はプロジェクトごとによしなに
Layoutコンポーネントが、
Root がついてるserver componentコンポジションして配置の関心を閉じ込めるpage, layoutと(たまにcontainer)で交通整理しておくと、ユースケースごとに関心を独立させられる
リソース直下のベース系
クライアントサイドでのキャッシュ管理でTanStack Queryを使う時は
_api を配置するts /app
/Customers // 主語(リソース), URLに使われる
Customers.page.tsx // エントリポイント
Customers.layout.tsx // レイアウトコンポーネント (各領域ごとのコンテナの配置の関心を逃す
/_components // ユースケース横断で再利用するベースコンポーネント
/_form // ユースケース横断で再利用するベースフォーム
/show // 動詞(railsの7actionsに従うことが多い)
ShowCustomerRoot.tsx // server component, ユースケースのエントリポイント
/_components // client component, ユースケース内専用のコンポーネント
/api
/form
/new
NewCustomerRoot.tsx
/_components
/api
/form
/edit
...
/Products
Products.page.tsx
Products.layout.tsx
/_components
/_form
/show
/list
/new
/edit
/destory思想メモ
bulletproof-reactっぽさはあるけど個人的にfeatures的な切り方はしっくりこない
featureとユーザーのエントリポイント(集約(Aggregate))の単位は違うことが多くて、関心の千切りが起こりやすい
レイヤ横断実装をなるべく減らしたい思いがある
プロジェクト全体の構造としては、主語->動詞->目的語(SVO)の流れを遵守しつつ、機能固有の構造はBCD Designのように使い分けてるするのが大事
全体を俯瞰して捉えるときは主語が先にあるとわかりやすく、文脈が含まれる場合は目的が先にあると理解しやすい
RDBの構造と似てる。まず独立したエンティティを定義し、特定の文脈での関係性については後から別の領域で定義する
この原則さえ守っていれば、それ以外の内側は実装詳細(private)になるので、厳しくルール化しない
_components はVercelの人がよくやってる慣習>@d151005: components のディレクトリ構成のベストは？Next.js の中の人的には今のところ
>・全体で共有するものは /app の _components におく
>・ページ固有のものはページディレクトリ内の _components におく
>というのが良いらしい。_ 接頭辞によりルーティングから除外できる。
>
>>Usecaseやdomainにどのような責務を持たせるかの議論は、まさにDDDのトリレンマの話ですべては両立できないので、チームで意志を持って決定する大切なポイントだと思います
CQSっぽくmutations, queriesで分けることもある
この辺の思想はDomain Modeling Made Functionalに多大な影響を受けている
綺麗にやろうとするとフレームワークのサポート必須なので難しいところはある
Cloudflare、App Routerならそろそろ大丈夫そう??
関連
ほか、参考
--