はじめに

昨今Reactなどのコンポーネントベースで作成するライブラリが普及し、コンポーネント思考での開発が一般化してきました。

本稿では、コンポーネント設計思想の一種である「AtomicDesign」の概要について説明します。
コンポーネント設計時の構成や粒度などの悩みの一助になれば幸いです。

この記事で得られること

AtomicDesignの概要を理解できる。

そもそもコンポーネントベースで開発をすると何がうれしいのでしょうか。
代表的なものとして、下記があげられます。

先に述べた「コンポーネントベースで開発を行うメリット」を享受するためには、コンポーネントが下記のような状態である必要があります。

ある機能をコンポーネント化した際、インタフェースの使い方のみを意識すればよく、コンポーネント内部の実装を意識せずに使うことができます。

まったく実装が異なるコンポーネントでも、置き換え対象のコンポーネントと同じインタフェースであれば、システムの動作を損なうことなく置き換えることができます。

コンポーネントが担っている責任に対して過不足なく機能を提供していれば、多くのコンポーネントで追加実装なく機能を実装できます。

コンポーネントを設計する際に、下記の原則を踏まえることで、コンポーネントを理想的な状態に保つことができます。

コンポーネントが担う責任は、1つに絞った方がよい。
　→複数の責任を担っていると、変更による影響がわかりにくくなり不具合を生む要因になります。
　→1つの責任にだけ集中することで、変更による影響を予測しやすくなり、再利用性も高くなります。

コンポーネントの機能を目的別に分離した方がよい。
　→アプリに変更が発生した場合でも、特定の1部分のみを修正すれば済みます。

#AtomicDesignとは
小さいUIコンポーネントを組み合わせて、より大きなコンポーネントを作っていくためのデザインフレームワークのことです。

特徴として、下記が挙げられます。

各要素について説明します。

ボタンといった最小の要素を表します。

例として、下記が挙げられます。

Atomsを組み合わせ、一機能を構成する要素を表します。

ユーザの動機に対して作成されることが多いです。

例として、下記が挙げられます。

独立して成立するコンテンツ(コンポーネント内で完結する)をあらまします。
AtomsやMoleculesを組み合わせて作成され、独立して存在することができます。(ヘッダー等)

【Moleculesとの見分け方】
Organisms→独立して存在できるスタンドアローンなコンポーネント
Molecules→他のコンポーネントの機能を助けるコンポーネント

ページのひな形を表します。
具体的なデータ(状態)を保持せず、Organisms層などを組み合わせて作成されます。
Templatesが依存するコンポーネントが、適切に連携して動作することを確認するために用いられます。

Templatesにデータを流し込んだものを表します。
レイアウトデザインを実コンテンツから分離することができます。
これにより、実コンテンツに依存せず、レイアウトテストを実施できます。

本稿ではデザイン(UI)に寄せて説明をしましたが、ロジック面でのコンポーネント設計についても思想は同じです。

また、AtomicDesignはあくまで抽象的な設計思想であり、実際の開発する環境(メンバー習熟度・チーム風土)によりカスタマイズされることが多いらしいです。
具体的には、MOLECULESとORGANISMSを廃止し、COMPONENTという単位でまとめる。などなど。

いい感じのカスタマイズがあれば教えていただきたいです！