原子の再定義 - Atomic ReDesign -

Atomic ReDesign とは

「Atomic ReDesign」 は、かの有名な「Atomic Design」の拡張概念です。React や Vue.js を用いたコンポーネント設計において、私たちはしばしば頭を抱えることがありました。UI 粒度の分類制約は、コンポーネント設計最適化を阻むことがあるからです。

「この粒度のコンポーネントはどこに属するものなのか？」という疑問に対し統一された解はなく、プロダクト毎の性質によって定める必要がありました。また、文脈が散在することにより、コードに対する集中力低下を招きました。

Atomic ReDesign は顕在化した 「Atomic Design とアプリケーション設計の乖離」 をとらえ、現実的な設計指針となることを目指します。

Atomic Design とアプリケーション設計の乖離

本家 Atomic Design はデザインシステム構築のための設計概念です。モジュラーな UI で再利用性を高めることを目的とし、規律あるデザインシステム構築に適しています。この設計概念をそのまま採用する前に、確認するべき事項があります。

「設計対象はデザインシステムであるか？」

設計対象がアプリケーションである場合、この問いに対する回答は「No」です。Atomic Design がうまく運用できている・いない、の分かれ目はここにあると考えています。

「原子 = モジュール最小単位」という規約はそのままで 「原子を再定義」 する Atomic ReDesign。これは、アプリケーションを構築する場合 「不可分なモジュール最小単位は UI ではない」 という観点にもとづきます。コンポーネントの構成要素は UI 意匠にとどまりません。Atomic ReDesign が提唱するモジュール最小単位は 「依存」 です。

原子の再定義

最小単位である原子を「依存」と再定義することで、どの様な変化があるのか見ていきます。

Atoms

Atoms はモジュールを構築するうえでの最小単位です。デザインシステムの場合、不可分な最小単位 はボタン UI 等になりますが、Atomic ReDesign における最小単位は Props などの一方向な参照依存です。これはすなわち「button・card・layout」など 「コンポーネント粒度」による分類は行わない ことを意味します。

Molecules

本家 Molecules は意味ある粒度の UI を表します。例えば「タイトル・ボタン・入力エリア」が揃うことで、ひとつの機能を提供する UI として成立します。アプリケーションに利用するコンポーネントの場合 Props だけではなく、コンポーネント内部に Local State を保持し、状態と値が相互依存することがあります。Atomic ReDesign では、このコンポーネント内に閉じられた相互依存を一つの Molecules とみなします。

Organisms

Organisms は Atoms と Molecules をもって構築された複合体です。Atomic ReDesign の場合、依存因子として Global State が含まれます。ここでは React の標準 API である Context を例に取り上げていますが、サードパーティライブラリによってもたらされる Global State であっても構いません。

ここで本家 Atomic Design 定義の大分類「System・Product」を振り返ってみます。この大分類は「汎用的であるか・否か」の重要な境界線です。

この境界線も Atomic ReDesign は踏襲しています。Organisms に属するコンポーネントは 横断的に再利用可能な Global State「System Context」 に依存していることを意味します。

これはすなわち、どの様な粒度のコンポーネントであっても「System Context」に依存している場合、Organisms に分類されるということです。「button・card・layout」など 「コンポーネント粒度」による分類は行いません。 この制約開放により、コンポーネント設計において、再描画設計の最適化を促します。

ここまでの話を総括すると、図示する ◉ は状態と値を共有するステークホルダーの相関図に見えてきます。特定の Sytem Context を共有する共同体ともいえるでしょう。

Templates

Atomic ReDesign において template は 「Product Context」 の依存が含まれていることを表します。「System Context」に依存する Organisms とは対象的で、page と対になる「特定のユースケース」が Product Context です。Product Context は page 特有の情報を保持している、とも言うことができます。

「Product Context」に依存するものの他「System」として再利用を目的としない小さなコンポーネントも template を構築するパーツとして、そのモジュール内に納めます。コンポーネントを小さく分割していく工程は何よりも尊く、文脈を分散させない規約はコーディングの集中力を維持します。

Pages

Next.js などの FW では、ルーティングとともに page を定義します。fetch API や serverside から授受する値をテンプレートへ注入することが責務です。「System・Product」それぞれの Context Provider との結合点でもあります。

最後に

Atomic ReDesign は原子の単位を「UI」から「依存」に差し替えていますが、最終成果物を構築するフロー・区分シソーラスは、本家 Atomic Design をそのまま踏襲しています。原子へ分割していく工程は、段階的に依存を剥がしていくリファクタリングの工程と等しいです。

解説した様に「原子の再定義」を行うことで、開発対象に適した設計規約とすることが可能です。本稿では「デザインシステム設計・アプリケーション設計」における原子の違いにフォーカスして解説しましたが、原子を「状態依存」以外へ再定義することでも、モジュラーな設計全般に適用できる概念になるのではないでしょうか。