はじめに
Atomic Designとはこのリンクに書いてある感じの奴です
最近のコンポーネント指向のフロントエンドでAtomic Designで失敗するチームの話をちらほら聞きます
自分も1度は失敗しました。そりゃプロトタイピングもしたことなかった状態でAtomic Designでこった画面を作ったので当然ですが。(逆に1つ目の画面で失敗に気づけてよかった
では、なぜ我々はAtomic Designでフロントの開発が上手くいかないのかを説明しようと思います。(誤字脱字その他各種修正の編集リクエスト待ってます!
指摘1. 世に出回っている多くの日本語資料のAtomic Designスライドは間違っている
そもそもオリジナルのAtomic Design読んだことありますか？
読んでないなら読みましょう。英語を読むのがめんどくさいなら私のざっくりな和訳記事を読んでください。
なぜオリジナルを読む必要があるのか
多くの日本語のAtomic Designのスライドは間違っています。むしろ正しい内容のスライドを見つけられませんでした。なぜならそれらのスライドを読んでもプロジェクトが上手く行くとは到底思えなく、実際にやってみたら上手くいきませんでした。なので原書に当たろうと思い、読んでみたらやはり全然違う事が書かれていましたが、納得の行く内容でした。
指摘2. ボトムアップで作ろうとしてませんか？
多くの日本語のAtomic Designのスライドはボトムアップで作ると言っています。しかし、それは間違いです。
理由
皆さんプログラムを書く時、クラスや関数作ったりしますよね。
関数型で行く場合は純粋に関数を量産するかと思います。
しかし、この関数とこの関数を作ってこの関数を作る。それらは全て汎用的な関数にして再利用性を最大限にすして単体テストを書く。それで、それらの関数を組み合わせて1つの機能やアプリを作る。っって考えないですよね。きっとそのように作った場合は不要な関数やクラス、使われていないメソッドが出来上がっているでしょう。
我々はコードを書く時はAの値をとってきて、その値を加工して返却してAPIを作成するって感じにコード書きますよね。
それでそこからこの部分のコードはこうしようとか、こうカプセル化できるとかって発見したら再利用できる何かに切り出すはずです。
その時思考はトップダウンになっているはずです。
しかしそのコードがどうなっているのかも把握しているはずです。アトミックデザインのatom, molecules, organismsも同じです。
オリジナルにも書かれてありますが、そのデザインがどのようなアトム、要するに関数やクラスで構成されているのかも知る必要がありますが、トップダウンからの視点もすごく重要であり、それがなくして良いものは作れないでしょう。なぜなら我々はElementUIやVuetifyのような、UIライブラリではなく、デザイナーが用意した組み合わせ済みのデザインを作るのが仕事だからです。
デザインを作る上でまずは適当でも良いのでガリガリ画面側を作っていって、あ、これは外でも使われそうだからatom、moleculesに切り出しとくか！とかって判断する順番が大切です。普段プログラミングしてるときもそのように思考するはずです。
指摘3. Atom Moleculesに無理に切り出す必要はない
某大手フロントチームとかそういったチームでない、数人のチームぐらいの場合、無理に全てのコンポーネントをAtomやMoleculesとかに切り出す必要はありません。
大切なのはOrganismsです。
理由
自分達がちょっとした値とかを計算する時にいちいちSumやちょっとした演算も全て関数使ったりメソッド使ってそれらの組み合わせだけで作らないでしょう？それと同じ事です。
用法用量守ってプロジェクトに合う粒度で作っていきましょう。
指摘4. Atomic DesignのTemplate、Pagesの要素は現在のコンポーネント指向には合わない
そもそものAtomic Designはデザイナーの為のもので、現代のコンポーネント指向には合っていません。フロントエンドエンジニアがコンポーネント開発でAtomic Designの設計から学べるものはせいぜいAtom, Molecules, Organismsです。
じゃあどうやってそれらを組み合わせてアプリを作るの？
A brief look at Atomic Componentsの設計を学ぶか、Apollo ClientのQuery Component等でContainerを作ってOrganismsにデータを流して上げましょう。
よく見るAtomic Designの1番大きな取り返しのつかない失敗
Pagesから全部のデータを流し込むみたいな事をAtomic Designでは書かれています。
しかし、それはデザイナー側の都合です。デスクトップUIでそんな事しようものならPagesは一瞬でハイパーファットなデータ管理庫兼ハイパーファットなインタラクター兼ハイパーファットな依存コントローラーにもなります。そうなって相談を受けたことは何度もありますし、話を聞いたこともあります。
これは伝統的なサーバーサイドレンダリングなら少なくとも今のフロントエンドより上手く行くでしょう。しかし、我々は沢山のデータを扱う1つ1つのコンテナーを作り、それらを協調させて1つのアプリを開発しています。なのでそれに合うように設計を工夫する必要があるのに、他分野の設計をその言葉通りに挑戦して失敗してるのをよく見ます。そもそもpageの責務が多すぎ、1つ1つの責務も重すぎるのでこれは上手くいかないのはすぐわかるでしょう。しかし、スマホUI限定でデザインも考慮されている場合これでなんとかはできるケースもありますが、それはかなり特殊なケースで綱渡りのようなものでデザイナーがかなり優秀で考慮してくれる場合の高等テクニックです。素直に境界を引いて、UIコンポーネントを丁寧に作る方がほとんどの場面の問題を解決できます。
指摘5. Organismsによくある勘違い
Atomic DesignのオリジナルにはOrganismsはOrganismsを利用していいって明記されています。つまり、OrganismsはOrganismsに依存して良いです。
巡回参照どうするの？
巡回参照は起きません。起きたらそれはよっぽど凄いデザインでしょう。プログラムじゃないビジュアルデザインなんだからそんな変な心配はしなくて良いです。
Organismsの粒度って何？
この質問はよく聞かれます。
Organismsで作るかどうかは、そのOrganisms1つで1つのデザイン上でのセクションを担当しうるかどうかです。
もし担当しているのでしたらそれは絶対にOrganismsです。なぜならそう定義されているからです。担当していないのならOrganismsではありません。多分moleculesかモデリングミスでしょう。それ以上も以下もありません。
Atomic DesignとかAtomic Componentの実コードサンプルない？
現在以下のリポジトリをVue.js + VuexでAtomic Componentの設計で書いています。
https://github.com/k-okina/book-management
多少サボってる所もありますが、少人数の場合はこのぐらいの粒度で良い気がします。
多分大体フルタイムが5人以上ぐらいで作るプロジェクトの場合はもうちょっと境界を作ったり粒度がそれに合うように頑張ると思います。