3年前の記事だが WEB+DB PRESS Vol.112 で、コンポーネント設計について特集されていたことを知ったので読んだ
AtomicDesignのような粒度定義ベースの設計方法を使うと以下のデメリットがある
粒度のみの設計でたりないのはコンポーネントがどういう性質/役割でどこで使われているのかがわからないこと
つまりドメインの知識が反映されていないので使い勝手が悪くなってしまう恐れがある
そこで「ドメインに関わるコンポーネント」という単位で考えていく
ただ、WebアプリやモバイルアプリといったデジタルプロダクトではGUIが存在し、それらに対してユーザーは普遍的なイメージをもっているので「ドメインに関わらない見た目だけのコンポーネント」という単位もある
また、画面に対しては「どういう画面で、どこに遷移できるか」というイメージももっているのでそれも分けて考えた方が良い
このようにして関心ごとを分離していくと、結果的に以下のように分けられる
関心事 | 説明 |
---|---|
ドメイン | サービスや業務にのみ関心をもつ |
GUI | GUIのみに関心をもつ |
画面 | 画面と遷移にのみ関心をもつ |
レイアウト | ドメインやGUIの配置にのみ関心をもつ |
コンテナ | アプリケーションの状態データの流し込みのみに関心をもつ |
具体的なコンポーネント粒度は以下
自分のプロジェクトの既存の分割単位から急には変えられないので一緒にはできないが、ざっくり「ドメインに関わるコンポーネント」と「ドメインに関わらない見た目だけのコンポーネント」という分け方にシフトしていくのはよさそうと感じた