Atomic Designとデータの複雑性

Atomic Designは万能ではない

知っとるわという感じですね。

Atomic Designを採用することで、コンポーネントの粒度に対する共通認識が生まれます。さらにはデザイナーとエンジニアの連携がよりシームレスになり、チームとしての連帯感が高まります。

しかし、Atomic Designはデザイン時・コーディング時にコンポーネントをなんの淀みもなく作成する絶対的なアーキテクチャではなく（そもそもそんなものないけど）、ただの方法論。Brad FrostさんのAtomic Design本でも、`Architecture`とか書いてなくて、`Methodology`と表現しています。

Atomic Design by Brad Frost

もちろん、あくまでこの方法論があることで、コミュニケーション面、メンテナンス面で多々メリットがある。チーム全体でのDXが非常に良くなることに関しては異論ありません。DXはUXと等しく重要。

DX: Developer Experience （開発体験）は重要だ - Islands in the byte stream

Atomic Designで生じる問題

ページの複雑性が増したら、素晴らしい方法論があっても自分で悩み解決しなくてはいけないことがあります。主な問題は次の通り。

・Atomから作るボトムアップ型が成立しにくい
・デフォルトスタイルの決定の難しさ
・Molecule、Organismの分割しにくさ
・Pageの必要性への疑問

だと思うのだけれど、これらに加えて最近感じるのは

・Atomic Designにはデータの複雑性を吸収しきる力はない

という問題があります。

Atomic Designで作られた、共通化可能なのを前提としたコンポーネントは、例外に弱い。例えば、とある管理画面を作っているときに、入稿データを管理する画面があったとする。入稿データ一覧はテーブルで確認できるのが基本として、同じようなデザインのテーブルでも、別のページでは画像や、モーダルのフォームが表示されるとする。

そうすると、基本的なOrganismの構造はテキスト情報が入るテーブルなのに、そこからさらにテーブル要素をデータ構造に応じて拡張する必要がでてれくる事になる。この例だとうまく設計すれば回避できるかもしれないが、一個のフィールドが追加されるだけで、ほぼ同等の構造を持った、コンポーネント群が生まれうる可能性は十分にあります。

少しわかりにくかったけど、つまりここで言いたいのは、十分に共通化したつもりでも、些細なデータ構造の変化によってAtomic Designのあり方がブレることがある、ということです。

まとめ

結構当たり前の話だったのだけれど、Atomic Designを採用するとコンポーネントが基本的に綺麗に分けられるので、最初は油断してしまう。ただ、途中からOrganismあたりで不穏な歪みが出てくるので、「デフォルトのデザインはなんなのか」というのを常に考え、それを最小のコンポーネント単位に止めるよう、努力するべきだなと思わされます。これを念頭に置いておかないと、データ構造にコンポーネント設計が大きく左右されて、旨味が得られなくなり、メンテ工数が増えて困りそうだなあ、と思いながら日々を過ごしています。