ドメインとは?
イントロダクション:ドメインを一言で言うと? 🌏
ドメインとは、ソフトウェアが向き合っている 「現実世界の仕事・問題・ルールのまとまり」 のことです。
ECサイトなら「商品・注文・在庫・配送・決済」、家計簿アプリなら「収入・支出・残高・月締め」のように、 システムが扱う「世界観」や「ビジネスルール」をひとまとめにしたものがドメインだとイメージしてください。
なお、ここでいう「ドメイン」は インターネットのドメイン名(example.com など)とは別物 で、 「どんな世界のルールをコードにしているのか?」 という問題領域を指す、設計の基本用語です。
1. なぜこの「ドメイン」という考え方が大事なの? 🎯
ドメインを意識せずにコードを書いていると、 次のような「現場あるある」の原因になりがちです。
-
ビジネスルールが散らばる
重要なルールが画面・バッチ・SQL・コメントなど、あちこちにバラバラに埋め込まれていき、 「このルールってどこで決まってるの?」が分からなくなる。 -
用語がバラバラになる
同じ概念を、ドキュメントでは「会員」、DBでは「user」、画面では「お客様」など 違う言葉で呼んでしまい、認識合わせに毎回コストがかかる。 -
変更の影響範囲が読めない
「この仕様変更はどのコードを直せばいい?」が分かりにくくなり、 直してはいけないところまで壊してしまうリスクが高まる。
逆に、 「このシステムのドメインは何か」「どんな概念とルールがあるか」 を整理しておくと、 アーキテクチャやモジュール分割の軸がはっきりし、 「仕様に沿って自然にコードが生える」 状態に近づけます。
2. どこからどこまでが「ドメイン」なの?(境界のイメージ)
ドメインは、システムの中でも特に 「現実世界のルール・状態・用語」を表す部分 に対応します。
-
ドメインに含まれるもののイメージ
「顧客」「注文」「請求書」「在庫」「支払い」などの 概念(名詞)、 「注文を確定する」「在庫を引き当てる」「請求額を計算する」などの 振る舞い(動詞・ルール)、 「注文はキャンセル済みに戻せない」などの制約。 -
ドメインに含まれないもののイメージ
画面のデザインやボタンの位置、DBのインデックス、ログ出力のフォーマット、 HTTP リクエストのパース処理などは、 ドメインを支える「仕組み側(インフラ・UI)」 であって、 ドメインそのものではありません。
アーキテクチャの文脈で、 「ドメイン層」「ドメインモデル」「ドメインサービス」 といった言葉が出てきたら、それは 「この業務のルールを表現するためのコードを置く場所」 だと捉えると分かりやすくなります。
3. 具体例でイメージする:ECサイトと家計簿アプリ 📦💰
抽象的なままだとつかみにくいので、代表的な例でドメインをイメージしてみましょう。
例1:ECサイトの場合
-
ドメインにあたるもの
商品、カート、注文、在庫、配送、キャンペーン、決済などの概念と、 それらの関係・ルール(在庫数の計算、送料の条件、ポイント付与の計算など)。 -
ドメインではないもの
商品一覧画面のレイアウト、DB接続プールの設定、外部APIクライアントの実装、Webサーバの設定などは 「どう見せるか・どう動かすか」の仕組み側。
例2:家計簿アプリの場合
-
ドメインにあたるもの
収入・支出・カテゴリ・口座・残高・月締め・予算などの概念と、 「支出には必ずカテゴリが必要」「月をまたぐときは締め処理が必要」などのルール。 -
ドメインではないもの
「円グラフで表示するか棒グラフにするか」「ダークモードの色」「CSVエクスポートのUI」などは、 ドメイン情報をどう表示・出力するかという仕組み側の話です。
このように、「何を扱い、どんなルールで動く世界なのか」 に注目すると、 ドメインの輪郭が見えやすくなります。
図解:プログラミングにおける「ドメイン」
「ドメイン」は、ソフトウェアが扱う現実世界の問題領域そのものです。 UI や DB といった技術要素とは切り離して、「何の仕事をするシステムか?」という中心部分を表します。
ドメイン中心で考える 3 つの観点
1. ドメイン層の分離
UI やインフラのコードから、業務ルールを切り出して「ドメイン層」として独立させます。 技術変更に振り回されないよう、「何を解くか」と「どう動かすか」を分けるイメージです。
2. ドメインモデルの表現
エンティティ・値オブジェクト・ドメインサービスなどを使って、 現場の用語とルールをそのままコードとして表現します。
まとめ:ドメインを意識して設計するためのポイント
- ドメインとは、システムが向き合う 「現実世界の仕事・問題・ルールのまとまり」 を指す、設計の基本用語です。
- 「どんな世界のどんな概念・ルールを扱っているか?」を整理すると、 モジュール分割やアーキテクチャ(レイヤー構造など)の軸が見えやすくなります。
- ドメインとそれを支える「仕組み側(UI・DB・インフラ)」を分けて考えることで、 変更に強く、読みやすい設計(高凝集・低結合) に近づけます。
- 「ドメインモデル」「ドメイン層」「ドメイン駆動設計(DDD)」といった用語は、 ドメインを中心にコードを組み立てようという発想の延長線上にあります。
まずは、 「このシステムのドメインは何か?」 と一度言葉にしてみることが、 設計力を一段引き上げる入口になります。
関連原則 🔗
このページの著者
経験:Webアプリ/業務システム
得意:PHP・JavaScript・MySQL・CSS
個人実績:フォーム生成基盤/クイズ学習プラットフォーム 等
詳しいプロフィールはこちら! もちもちみかんのプロフィール