ドメインとは?

公開日:
最終更新日:

イントロダクション:ドメインを一言で言うと? 🌏

ドメインとは、ソフトウェアが向き合っている 「現実世界の仕事・問題・ルールのまとまり」 のことです。

ECサイトなら「商品・注文・在庫・配送・決済」、家計簿アプリなら「収入・支出・残高・月締め」のように、 システムが扱う「世界観」や「ビジネスルール」をひとまとめにしたものがドメインだとイメージしてください。

なお、ここでいう「ドメイン」は インターネットのドメイン名(example.com など)とは別物 で、 「どんな世界のルールをコードにしているのか?」 という問題領域を指す、設計の基本用語です。

1. なぜこの「ドメイン」という考え方が大事なの? 🎯

ドメインを意識せずにコードを書いていると、 次のような「現場あるある」の原因になりがちです。

  • ビジネスルールが散らばる
    重要なルールが画面・バッチ・SQL・コメントなど、あちこちにバラバラに埋め込まれていき、 「このルールってどこで決まってるの?」が分からなくなる。
  • 用語がバラバラになる
    同じ概念を、ドキュメントでは「会員」、DBでは「user」、画面では「お客様」など 違う言葉で呼んでしまい、認識合わせに毎回コストがかかる。
  • 変更の影響範囲が読めない
    「この仕様変更はどのコードを直せばいい?」が分かりにくくなり、 直してはいけないところまで壊してしまうリスクが高まる。

逆に、 「このシステムのドメインは何か」「どんな概念とルールがあるか」 を整理しておくと、 アーキテクチャやモジュール分割の軸がはっきりし、 「仕様に沿って自然にコードが生える」 状態に近づけます。

2. どこからどこまでが「ドメイン」なの?(境界のイメージ)

ドメインは、システムの中でも特に 「現実世界のルール・状態・用語」を表す部分 に対応します。

  • ドメインに含まれるもののイメージ
    「顧客」「注文」「請求書」「在庫」「支払い」などの 概念(名詞)、 「注文を確定する」「在庫を引き当てる」「請求額を計算する」などの 振る舞い(動詞・ルール)、 「注文はキャンセル済みに戻せない」などの制約。
  • ドメインに含まれないもののイメージ
    画面のデザインやボタンの位置、DBのインデックス、ログ出力のフォーマット、 HTTP リクエストのパース処理などは、 ドメインを支える「仕組み側(インフラ・UI)」 であって、 ドメインそのものではありません。

アーキテクチャの文脈で、 ドメイン層」「ドメインモデル」「ドメインサービス」 といった言葉が出てきたら、それは 「この業務のルールを表現するためのコードを置く場所」 だと捉えると分かりやすくなります。

3. 具体例でイメージする:ECサイトと家計簿アプリ 📦💰

抽象的なままだとつかみにくいので、代表的な例でドメインをイメージしてみましょう。

例1:ECサイトの場合

  • ドメインにあたるもの
    商品、カート、注文、在庫、配送、キャンペーン、決済などの概念と、 それらの関係・ルール(在庫数の計算、送料の条件、ポイント付与の計算など)。
  • ドメインではないもの
    商品一覧画面のレイアウト、DB接続プールの設定、外部APIクライアントの実装、Webサーバの設定などは 「どう見せるか・どう動かすか」の仕組み側。

例2:家計簿アプリの場合

  • ドメインにあたるもの
    収入・支出・カテゴリ・口座・残高・月締め・予算などの概念と、 「支出には必ずカテゴリが必要」「月をまたぐときは締め処理が必要」などのルール。
  • ドメインではないもの
    「円グラフで表示するか棒グラフにするか」「ダークモードの色」「CSVエクスポートのUI」などは、 ドメイン情報をどう表示・出力するかという仕組み側の話です。

このように、「何を扱い、どんなルールで動く世界なのか」 に注目すると、 ドメインの輪郭が見えやすくなります。

図解:プログラミングにおける「ドメイン」

ドメイン」は、ソフトウェアが扱う現実世界の問題領域そのものです。 UI や DB といった技術要素とは切り離して、「何の仕事をするシステムか?」という中心部分を表します。

ドメインを中心にした設計
利口すぎない UI / アプリケーション層

ドメイン中心で考える 3 つの観点

1. ドメイン層の分離

UI やインフラのコードから、業務ルールを切り出してドメイン層」として独立させます。 技術変更に振り回されないよう、「何を解くか」と「どう動かすか」を分けるイメージです。

ドメイン層の分離

インフラ / 技術
  • DB・ネットワーク
  • フレームワーク設定
  • ログ・監視 など
アプリケーション層
  • ユースケース
  • 画面の流れ
  • API 入出力

現場のルール・用語・制約をまとめたシステムの「核」

2. ドメインモデルの表現

エンティティ・値オブジェクト・ドメインサービスなどを使って、 現場の用語とルールをそのままコードとして表現します。

ソフトウェアによるドメインモデルの表現

エンティティ
値オブジェクト
ドメインサービス
モジュール / パッケージ

3. ライフサイクルの管理

集約・リポジトリ・ファクトリで、ドメインオブジェクトの 生成・保存・再構築の責務を整理します。

ドメインオブジェクトのライフサイクル

集約
ファクトリ
リポジトリ
UI やインフラの都合から切り離して、 現場の知識・ルールを中心にソフトウェアを組み立てていく領域が「ドメイン」です。 エンティティや値オブジェクトなどのドメインモデルと、そのライフサイクルを支える仕組みをセットで設計していきます。

まとめ:ドメインを意識して設計するためのポイント

  • ドメインとは、システムが向き合う 「現実世界の仕事・問題・ルールのまとまり」 を指す、設計の基本用語です。
  • 「どんな世界のどんな概念・ルールを扱っているか?」を整理すると、 モジュール分割やアーキテクチャ(レイヤー構造など)の軸が見えやすくなります。
  • ドメインとそれを支える「仕組み側(UI・DB・インフラ)」を分けて考えることで、 変更に強く、読みやすい設計(高凝集・低結合) に近づけます。
  • ドメインモデル」「ドメイン層」「ドメイン駆動設計(DDD)」といった用語は、 ドメインを中心にコードを組み立てようという発想の延長線上にあります。

まずは、 「このシステムのドメインは何か?」 と一度言葉にしてみることが、 設計力を一段引き上げる入口になります。

このページの著者

もちもちみかん(システムエンジニア)

社内SEとしてグループ企業向けの業務アプリを要件定義〜運用まで一気通貫で担当しています。

経験:Webアプリ/業務システム

得意:PHP・JavaScript・MySQL・CSS

個人実績:フォーム生成基盤クイズ学習プラットフォーム

詳しいプロフィールはこちら!  もちもちみかんのプロフィール

もちもちみかん0系くん
TOPへ

もちもちみかん.comとは


このサイトでは、コーディングがめんどうくさい人向けのお助けツールとして、フォームやCSSをノーコードで生成できる、
 もちもちみかん.forms
 もちもちみかん.css1
 もちもちみかん.css2
と言ったジェネレーターを用意してます。

また、このサイトを通じて、「もちもちみかん」のかわいさを普及したいとかんがえてます!