---
# System prepended metadata

title: Atomic Design

---

Atomic Design
===

![](https://cdn-ak.f.st-hatena.com/images/fotolife/t/tic40/20181007/20181007213756.png)


## 目次
[TOC]


## 基礎
5つの分類から構成されている
左であるほど抽象度が高く、汎用的で再利用できる

![](https://uxdaystokyo.com/articles/wp-content/uploads/2018/12/abstract.png)

## なぜAtomic Designを使うのか
**チームでUIデザインのシステムを構築するための共通言語をチームで確立することで効果的なコミュニケーションを図るため**である

そのためには必ずしも5つの分類を遵守する必要はなく、原則に基づいて独自の階層構造を定義しても良い


## 🙆ごとの具体例
### Atoms
- AppButton
- AppLabel
- AppInputForm

などのように、`App*.vue`というファイル名で構成されている

### Molecules
Atomsの集合体でできている

- InputFormControll(Molecules)
    - AppInputLabel(Atoms)
    - AppInputForm(Atoms)
    - AppInputValidateError(Atoms)


### Organisms
- LoginForm(Organisms)
    - InputFormControll(Molecules)
    - LoginButton(Molecules)


### Template
🙆ごとではほぼすっ飛ばされている感
layoutsが近い役割を背負っている

個人的には`layouts`がほぼ生きてないのでもっと生かしても良いのでは、という感じ

### Pages
nuxt内の`pages`ディレクトリが割り当たっている

`pages/login.vue`など


## まとめておもったこと
- `なぜAtomic Designを使うのか`の項に書いたようなメリットを享受できる運用にしていく必要がある
- (具体的には)デザイナーの考え方に近いのでシナジーが大きそうだけどあんまり生きてないような感じ
    - パーツだけ先に作るとか
    - どうやって作ってるかデザ側に簡単にでもシェアしたらお互いやりやすくなるかも


## 役立つ記事
- [Atomic Design を分かったつもりになる | DeNA DESIGN BLOG](https://design.dena.com/design/atomic-design-%E3%82%92%E5%88%86%E3%81%8B%E3%81%A3%E3%81%9F%E3%81%A4%E3%82%82%E3%82%8A%E3%81%AB%E3%81%AA%E3%82%8B/)
- [Nuxt.js × Atomic Designのサービスデザインフロー](https://speakerdeck.com/keisukeimura/nuxt-dot-js-x-atomic-designfalsesabisudezainhuro?slide=28)