DI-CODINGの考え方
たとえばデザインコンペでは、様々なデザイナーがそれぞれにWebデザインを提案しますが、そのすべてに共通して一般に「グローバルナビゲーション」と呼ばれる部品が存在していることは少なくありません。
ページの中にはいくつか見出しがあり、その見出しも一定のルールに基づいてデザインされている場合がほとんどです。
コンポーネントやモジュールと呼ばれる、Webサイトを構成する「部品」には、この「グローバルナビゲーション」のようにある程度パターン化されているものが多くあり、部品の特徴や役割を表す名称で広く認識されています。
どんなデザインでもこの「部品」ごとに切り分けてみると、どのサイトでもよく似た構造をしており、それをブラウザに再現するためのHTMLコードも似通っています。
これを逆に考えると「様々なデザインに対してHTMLコードを再利用することができ、コーディングの時間を大きく短縮できる」ということになります。
コードを再利用すれば同じ部品のコーディング計画に何度も頭を抱える必要もなく、あとはデザインに合わせていくらかコードを書き換えれば出来上がりです。
「グローバルナビゲーション」など、部品の特徴や役割を表す名称は、別のサイトを制作する際にも同じ名称で呼ばれます。
各部品に対してidやclassで「global_navigation」や「gnav」のように固有の名前を定めておき、基本となるHTML構造やCSSを作り置きすることで、別のサイトを制作する際にコードを再利用できます。
CSSフレームワークとの考え方の違い
DI-CODINGは、自分でデザインを作ることができます。
Bootstrap、Foundation、Tailwind CSS、BulmaなどのCSSフレームワーク（CSSライブラリ）を使うと、Webサイト上にコンポーネントを簡単に構築・配置することができますが、各コンポーネントのデザインはすでに存在し、CSSセレクタも記述されています。
つまり、CSSに合わせたHTMLコードを書く必要があるのです。
デザイナーがいないチームでWebシステムのUIを素早く作るには便利ですが、同じようなデザインになってしまうので、企業の公式サイトやメディアサイト、ECサイトなど、それぞれのWebサイトに個性を出したい場合にCSSフレームワークは不向きです。
さらにコンポーネントの組み合わせによっては余白やサイズに違和感が発生したりして、微調整をしたくなることがあります。
フレームワークではこういった場合に備えて余白やサイズを指定できるセレクタも用意されていますが、ちょうどいいサイズがなかったりして、もどかしい気分にさせられることもあるでしょう。
DI-CODINGでは、HTML構造に大まかなルールを定めますが、CSSはデザインに応じて書き換わる前提で考えているため、ルールの範囲内であればHTMLコードやCSSプロパティの値も柔軟に微調整したり、局所的な例外を安全に作ることができます。
そのため、どんなデザインでもDI-CODINGでコーディングすることが可能です。
Atomic Designとの違い
Atomic DesignはUI設計の考え方であり、コード設計の考え方ではありません。
Atomic Designの概念に基づいてUI設計をすることはできますが、その粒度や分類をそのままコーディングに持ち込もうとすると「これはAtomなのか？Moleculeなのか？」と頭を抱えてしまうことがあります。
コーダーの視点で見ると、たとえば以下のような場合はAtomに見えます。
しかし以下のような場合は、複数要素を組み合わせた構成となるためMoleculeに見えます。
DI-CODINGでは、これらすべてを「コンポーネント」つまり「部品」と定義し、構成や粒度によって呼び分けようとはしないため、もう「これはどこに分類するのか」「本当にこれで正しいのか」と無駄に考える時間を使う必要はありません。
「Atomic Designに基づいたデザインをDI-CODINGでコーディングする」と考えるほうが正しく、この「Atomic Designに基づいた」が「OOUXに基づいた」になっても変わらずDI-CODINGでコーディングできます。