SVO型のパッケージングで機能的凝集を目指すオニオンアーキテクチャ
from
2023/05/26時点のNext.jsでパッケージングするならこうかな〜、というイメージ 前提
システムによって味づけ具合は異なる
原則
命名規則はプロジェクトごとによしなに
page, layoutと(たまにcontainer)で交通整理しておくと、ユースケースごとに関心を独立させられる
リソース直下のベース系
code: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
思想メモ
全体を俯瞰して捉えるときは主語が先にあるとわかりやすく、文脈が含まれる場合は目的が先にあると理解しやすい
RDBの構造と似てる。まず独立したエンティティを定義し、特定の文脈での関係性については後から別の領域で定義する
主語はWeb APIやモデル単位になることが多いかも(論理的にも物理的にも一致してる方がメンテしやすいよね) @d151005: components のディレクトリ構成のベストは？Next.js の中の人的には今のところ ・全体で共有するものは /app の _components におく
・ページ固有のものはページディレクトリ内の _components におく
というのが良いらしい。_ 接頭辞によりルーティングから除外できる。
https://pbs.twimg.com/media/Fwc2-EraEAED5zR.jpg
>Usecaseやdomainにどのような責務を持たせるかの議論は、まさにDDDのトリレンマの話ですべては両立できないので、チームで意志を持って決定する大切なポイントだと思います
CQSっぽくmutations, queriesで分けることもある 綺麗にやろうとするとフレームワークのサポート必須なので難しいところはある
関連
ほか、参考
--