【フロントエンド開発】AtomicDesignを使わないドメインに注目したコンポーネントの分け方

３年前の記事だが WEB+DB PRESS Vol.112 で、コンポーネント設計について特集されていたことを知ったので読んだ

AtomicDesignのような粒度定義ベースの設計方法を使うと以下のデメリットがある

• どこからどう作って良いか迷う
• 粒度の小さいコンポーネントから作るのが難しい
• いつでもどこでも使えるように汎用性を持たせようとしてしまい複雑になる
• 不要なコンポーネントを作ってしまう

粒度のみの設計でたりないのはコンポーネントがどういう性質/役割でどこで使われているのかがわからないこと

つまりドメインの知識が反映されていないので使い勝手が悪くなってしまう恐れがある

そこで「ドメインに関わるコンポーネント」という単位で考えていく

ただ、WebアプリやモバイルアプリといったデジタルプロダクトではGUIが存在し、それらに対してユーザーは普遍的なイメージをもっているので「ドメインに関わらない見た目だけのコンポーネント」という単位もある

また、画面に対しては「どういう画面で、どこに遷移できるか」というイメージももっているのでそれも分けて考えた方が良い

このようにして関心ごとを分離していくと、結果的に以下のように分けられる

関心事	説明
ドメイン	サービスや業務にのみ関心をもつ
GUI	GUIのみに関心をもつ
画面	画面と遷移にのみ関心をもつ
レイアウト	ドメインやGUIの配置にのみ関心をもつ
コンテナ	アプリケーションの状態データの流し込みのみに関心をもつ

WEB+DB PRESS Vol.112 P578 図2

具体的なコンポーネント粒度は以下

• Screen
• Layout
• Container
• Domain Object
• Domain Element
• GUI Group
• GUI Parts

自分のプロジェクトの既存の分割単位から急には変えられないので一緒にはできないが、ざっくり「ドメインに関わるコンポーネント」と「ドメインに関わらない見た目だけのコンポーネント」という分け方にシフトしていくのはよさそうと感じた