前提条件として 、 Atomic Design はデザイナーであるブラッド・フロスト氏が考えた デザインシステム だ。
フロントエンド開発者は、Atomic Design の概念をソフトウェア開発に持ち込み、デザイナーとのユビキタス言語とすることで、アジャイル開発におけるデザイナーとの早期コラボレーションを 実現している 目指している。
一方で、Atomic Design の考え方は、開発者なら誰もが耳にしたことがある DDD (ドメイン駆動開発 ) や クリーンアーキテクチャを強く想起させる。
※上記ブログより引用
こちらのブログで紹介されている Onion Architecture がまさに、 Atomic Design の概念に親しい。
※ブラッド・フロスト氏の記事より引用
よって、以下のような記事は、非常に合理的な考え方に見える。
だがしかし、見逃しがちな Atomic Design と Onion Architecture の違いは、ブラッド・フロスト氏の別なブログで記載されている以下の一文に集約される。
Organisms are relatively complex UI components composed of groups of molecules and/or atoms and/or other organisms.
日本語訳すると 「Organismsは、Molecules・Atoms・他の Organismsから構成された、比較的複雑なUIコンポーネント」 だ 。つまり、 Organisms は Organisms に依存される可能性がある。これではクリーンアーキテクチャと言うことは難しい。これが、意外と知られておらず、実装者の理解によって、 Organisms が Organisms を依存している構造が許容されたりされなかったりする。
正直、この点はよく目にする「このコンポーネント、Molecules にすべきか Atoms にするか論」よりも、よっぽど問題だと思っている。
もちろん、このルールを拡張して、Organismsは他のOrganismsを利用しないようにするという規約で縛ることでクリーンアーキテクチャ然に使うことはできるかもしれないが、基礎的な設計では Atomic Design はクリーンアーキテクチャにはなりえないと言える。
にもかかわらず、バズワード的に Atomic Design という言葉が広まったことで、属人的な理解の側面が強いまま、コンポーネント分類手法として広く定着してしまった。
このことから、食べログの note で紹介されたような、独自のコンポーネント分割を行うアプローチの事例も散発的に目に留まることが増えてきた。
再掲になるが、上記記事でも言及されている通り、 Atomic Design はあくまで デザインシステム であり、ロジック実装に関する事柄には触れられていない。
この辺の、どう捉えるべきかに余地がある（抽象度の高い）概念は拡張性がある一方、誤解を生みやすく、開発を始める前や、新規メンバーが参画した際の適切なインストールを行う必要がある。また、カスタマイズする場合はなおさらインストールが大変になることに注意した方がよさそうだ。
（特に、使う言葉が同じなので、言葉の上では「理解したつもり／共有したつもり」という誤解が生まれやすいのでなおさら厄介なのです）
なので、ぼんやり思っているのが、 Atomic Design の概念を拡張する 場合でも、格コンポーネントの分類をする際に名称を変えた方がいいのではないかということだ。
例えば、Atomic Designが原子物理学の比喩表現なので、工学の比喩表現（特にクルマ）を使ってみると、こんな感じに言い換えることができる。
| 原子物理学 | 工学 | 備考 |
|---|---|---|
| Atoms | Parts | これ以上分解できない部品（例：ギア・ギアボックスケース・タイヤ・ホイール） |
| Molecules | Assemblies | 部品が組み合わさって構築されたそれ単体では機能が提供できない組み合わせ（＝ASSY）（例：トランスミッション・タイヤがホイールに取り付けられた状態） |
| Organisms | Mechanisms | 部品やASSYが組み合わされてできた、それら単体で動作する機構（例：エンジン） |
| （該当なし） | Units | 部品、ASSY、機構で構成された、もう少し大きい粒度（例：エンジン＋トランスミッション＋プロペラシャフト＋デフ＋ドライブシャフト＋タイヤ） |
| Templates | Templates | この辺は提供する媒体（Webなのか紙なのか、はたまたクルマなのか）に引っ張られる。フロントエンドなので、Templateのまま |
| Pages | Pages | 同上 |
とまぁこんな感じ。
結論は、ラベリングし直しただけなんだが、 Units 層を加えたことで、クリーンアーキテクチャとまでは言わないが、依存関係は一方通行にすることができるようになった。
個人的にこの比喩表現が気に入ったのは、アプリケーションもまた工業製品であり、工学との相性のほうがいいのではないか、というところ。
デザイナーと会話する際はAtomic Designに翻訳して会話し、エンジニア間はまた別な意味合いのレイヤリングで会話することになるので万事が解決するわけではないが、対応表まで用意してあげればある程度問題にはならないのではないかと思う。
他にも、天体物理学の比喩表現も考えたが、「Atoms（チリ）が集まって高密度になったところが恒星になる（核融合反応で炎上する）」というのがあまりソフトウェア工学との相性が良くないので考えるのをやめた。（燃えるという点が縁起が悪い。なにより、わかりづらく、燃えた後に冷えていくというのはソフトウェア工学的に悪手の考え方。。。まぁ、炎上プロジェクトを冷やしにかかる時は有効かもね。。。）
11/22 追記
BCD Design というコンポーネント分類手法があるらしい。
atoms (Base) と molecules (Common) という粒度だけを共通の基底コンポーネントとし、命名規則とユースケースでDomain 別のコンポーネントを作る概念。新たに携わるプロジェクトで試してみよう。
