AtomicDesignに対してコンポーネント志向デザインを10年前から行っていた人のコメントと議論
kotarok まあそれはさすがに言い過ぎとしても。今や益より害の方が勝るのでは感はある。あんなのふんわりコンセプトなんだから真面目にその通り考えたらだめだ。 tenjuu99 これって実務に応用してみての感想でしょうか?このあたりお話伺ってみたいです。 kotarok そうですね、実際作っていく中で堅固な階層化による整理は無理があると感じました。いや、ある程度粒度の大きなコンポーネントは概ね可能かつ有効だと思いますが、Atom とか言う小さい概念までこの方向性で整理するのは無理かつ無意味だと思います。 kotarok そういう、ブロックの組み合わせによって何かが出来上がるという考え方は抽象度が高く(デザインコンポーネントの場合は逆と言うべきかとさもだけど)、domain specific なレベルではいいと思いますが、ファンダメンタルなレベルではそれはブロックではなく環境を作るルールとして定義されるのが好まし tenjuu99 なるほど、ありがとうございます。Atomic Designのアプローチを検討していて実務レベルでどうなのかまだ想定できていないので参考になります。 tenjuu99 domain specific なレベルでは問題ない、というのは逆を想像していました。Atomic Designの問題定義の仕方が、いままではページというメタファからすべてが出発してきたがこれは現状に即していない、分割して最小要素に還元すればdomain specificではないコンポーネントができるはずだ、 tenjuu99 という前提だとおもっていたので、ドメイン知識を排除したものをコンポーネントとして定義しようというはなしかなと考えていました。 kotarok あー、それは作るものがデザインシステム自体かそれを利用して作るプロダクトか、というケースの違いがあって、デザインシステムは言語を作ること、プロダクトはその言語で何かを語ること、のように区別してます。 kotarok そうそう、具体的にいうとタイポグラフィックなエレメントとか文字サイズと色の組み合わせとかを全部 Atom として定義するのがやり方として現実的で意味があるのだろうか? という話で、それは「文字サイズのバリエーション*色のパレット」というルールにしたほうがわかりやすく運用しやすい。 kotarok またルール化されてるということはそれに対する評価や批判や拡張も可能ということだけど、そこが明文化されずその成果物としての Atom だけ並べられるとどの様に拡張可能なのか見えにくくなったりする。 kotarok なので、ルールや成約に基づいた成果物をハンディに使いやすくために Atomic Design のようなメタファで整理するのはいいと思うけど、作っていく過程や作り方としてはあまり良いと思ってない。やはり作るには「記述」していくことが重要なんじゃないかと。 tenjuu99 なるほどなるほど。むちゃくちゃ参考になります。定義された語彙群に対してシンタックスが提供されていないという問題、たぶんOOPでも同じ問題があると思っていて、それがDDDだとサービス、Clean ArchitectureだとUseCaseと呼ばれているものだと考えています。