Atomic Designの採用にあたりよく思う「これをどのレイヤーで実装するか」という考えが「BEMでいうとBlockにするかElementにするか迷う」に近いと感じることがあります。この記事はその思考のメモにあたるものです。

Atomic Design | Atomic Design by Brad Frost

Organisimsに放り込んだ方が楽

適当なチャンクで有機体という認定をすることはそう難しくはありません。

特に実装時はロジックが入り混じる時点で「別の責任を持つ別の有機体」であると判断ができ、それらはコンポーネントとして別々にしてしまう判断が容易にできます。

そしてそれらのロジックの実現を満たすためのパーツは、いちいちAtomsにせずOrganismsで持ってしまうと管理コストはかかりません。ただし、似たようなI/Oを持つパーツが独立していない以上、再利用したい時は「Atomsにしておけばよかったな」と思ってしまうこともあります。

これはCSSを書くときに、ある有機体を構成する要素を「Element」として装飾してしまったときに同じことを思います。ああ、Blockとして書いておけばよかったな、と。

Atomsを管理できるなら、将来的な拡張性はあがる

例えば「検索フォーム」を構成する「インプットフィールド」「検索ボタン」はそれぞれ本当にAtomsとする必要があるのだろうか、という思いがよく付き纏います。もちろん、それらをそれぞれ適切なI/Oを持たせておけば、スケールに耐えうるデザインシステムにはなります。

一方で、分割不可能な最小単位でAtoms、CSSではBlockを量産することは、それらの把握と拡張についてつねに考慮し続ける必要があります。デザインシステムを運用する気概があれば、それらは資産ですが、その計画なくして同じことをやったとき、管理不可能な負債になりうることはよくあることです。

Modifierは少しずつ増える

現実は少しずつ破綻させず慎重に拡張を続けることが多いという事実があります。CSSでいうと「Modifierを生やす」という行為に近いものが当たります。それは、Atomsが徐々に拡張を続けた結果、必要以上の責務を背負ってしまう現象を引き起こすことにもなります。

CSSにおいては、コンテキストに合わせて別の機能を持たせる上では、Modifierではなくコンテキストに合わせたオーバーライドという方法も取れます。それはもはや既存のBlockが追うべき責務ではないこともあります。

Atomic Designでは、同じような見た目だが全うする責務が異なる場合、Organismsなど高階層でロジックを定義することでそれらを独立させて実現します。どう使われるかは有機体が知るべきことで、これはコンテキストに合わせた役割を与える上でオーバーライドに近い考え方といえます。

最後に

原理原則に則るとすると、もしもアーキテクチャとしてAtomic Designを採用する上ではそれぞれはAtomsとして分離していくのがスジなのかな、と感じます。しっかりと管理できればデザイン・実装ともにスピードが出せる一方で、管理コストと天秤にかけたときにスキルやリソースがそこに伴うのかは一番に考慮しなければなりません。

多くの技術記事などで、こう簡略化した、こういう理由で管理をやめた（=Atomic Designをやめた）などの情報が散見されますが、どれも適切な天秤で量った結果であることがわかります。

この記事を読んでいる方にとって何か参考になれば嬉しく思います。