ドメインモデリング

Created: 2026-09-07

ドメインモデリング(domain modeling)は、開発対象となる問題領域について、意味、構造、規則、境界をドメイン・モデル (Domain Model)(domain model)として組織する活動 (Activity)です。SimpleModeling (シンプルモデリング)では、ドメイン・モデルをオブジェクト・モデル (Object Model)、知識モデル (Knowledge Model)、文芸モデル (Literate Model)と並ぶ第四の構成要素にはしません。同じ対象を表す三つの構成要素から、問題領域を理解し、判断し、開発するために必要なモデル要素を選び、対応付けた適用モデルとして扱います。

ドメイン・モデルは、整った図や一貫した用語だけで完成するものではありません。現実の業務に対して妥当であり、重要な規則と境界を正しく表している必要があります。そのため、ドメインエキスパート、開発者、生成AIが、用語、根拠、形式構造、説明を共有し、モデル (Model)の妥当性を反復的に高めます。

シリーズにおける位置付け

第5回から第7回では、SimpleModelingモデルを構成する三つの側面を扱いました。

オブジェクト・モデル(object model): 構造と振る舞い (Behavior)を形式的に表す実行可能なモデルと実行例
知識モデル(knowledge model): 概念、分類、意味関係、規則、根拠を生成AIが探索、関連付け、説明するためのモデル
文芸モデル(literate model): 文脈、意図、要求、判断、シナリオなどを自然言語中心で表すモデル

第8回からは、三つの構成要素を開発上の目的に沿って組織します。ドメインモデリングは、問題領域に何が存在し、何を意味し、どのような構造と規則を持つかを中心に扱います。状態 (State)や振る舞いも、それが対象そのものの意味を表す場合はドメイン・モデルに含まれます。次回のアプリケーションモデリング(application modeling)は、利用者の目的とユースケース (Use Case)を起点に、UIと動的な協調 (Collaboration)、相互作用によってその目的をどう実現するかを中心に扱います。

前回の記事: 📄 文芸モデリング

ドメインモデリングが組織するもの

ドメインモデリングでは、問題領域について少なくとも次の四つを明らかにします。

観点	問い
意味	その用語や概念は、この業務では何を意味するのか
構造	概念はどのように分類され、関係し、所有されるのか
規則	何が許され、何が禁止され、何が常に成立するのか
境界	どの範囲で、その意味、構造、規則が有効なのか

観点

問い

意味

その用語や概念は、この業務では何を意味するのか

構造

概念はどのように分類され、関係し、所有されるのか

規則

何が許され、何が禁止され、何が常に成立するのか

境界

どの範囲で、その意味、構造、規則が有効なのか

この四つは別々に決めるものではありません。たとえば「顧客」という用語の意味は、販売、契約、請求、サポートで同じとは限りません。どのコンテキストで用語を使うかが決まると、必要な属性 (Attribute)、関係、規則も変わります。逆に、同じ用語に異なる規則が結び付いていることから、コンテキストを分ける必要が見える場合もあります。

ドメイン・モデルは目的別に構成する適用モデル

オブジェクト・モデル、知識モデル、文芸モデルは、同じ対象の異なる側面を表すSimpleModelingモデルの構成要素です。ドメイン・モデルは、それらと同列の構成要素ではなく、問題領域を理解し開発するという目的に必要なモデル要素を三つの構成要素から選び、対応付けたモデルです。

この区別により、ドメイン・モデルをクラス図 (Class Diagram)だけに限定せず、同時に何でも含む巨大な文書にすることも避けられます。形式構造はオブジェクト・モデル、意味関係と根拠は知識モデル、文脈と説明は文芸モデルに保持したまま、共通の用語識別子とモデル要素の対応によって一つのドメイン・モデルとして扱います。

用語から概念を共有する

ドメインモデリングの入口は用語です。用語集 (Glossary)(glossary)は、名称を並べる一覧ではなく、概念を識別し、その定義、適用範囲、同義語を共有するための基点です。一般の日本語と重なる「関係」「関連」「所有」「合成」のような語も、用語集の識別子 (Identifier)を通してモデル上の概念として区別します。

用語を定義するときは、単独の一文だけで固定するのではなく、次の情報を対応付けます。

どのコンテキストで使う用語か
何を含み、何を含まないか
近い用語や対立する用語とどう違うか
どの規則、文書、モデル要素、事例が根拠になるか

同じ識別子をオブジェクト・モデル、知識モデル、文芸モデルから参照することで、人間と生成AIが同じ概念をたどれます。

コンテキストと境界

コンテキストは、用語と規則を解釈するための背景です。組織、業務目的、責任、利用者、時間、法制度などによって、同じ言葉の意味が変わります。コンテキストを明示しないまま一つの定義へ統合すると、異なる業務上の関心が衝突し、モデルが不自然に複雑になります。

境界づけられたコンテキストは、モデルの用語、構造、規則が一貫した意味を持つ範囲です。境界の目的は、システムを機械的に細分化することではありません。内部では意味を一貫させ、外部とは意味の違いを明示して接続できるようにすることです。

一つのドメイン・モデルは、必要に応じて複数の境界づけられたコンテキストを含みます。それぞれの内部で意味を一貫させ、コンテキスト間では同じ用語や情報がどのように対応するかを明示します。

境界は組織図や既存システムの分割と常に一致するわけではありません。業務上の責任、変更理由、規則のまとまり、用語の意味を手掛かりに候補を作り、実際の事例と照らして調整します。

ユビキタス言語

ユビキタス言語は、境界づけられたコンテキストの中で、ドメインエキスパート、開発者、生成AI、モデル、プログラムが共有する言語です。用語集に登録するだけでは成立しません。会話、要求、モデル、CML (Cozy Modeling Language)、レビュー、テスト (Test)、ドキュメントで同じ意味を使い、意味のずれが見つかればモデルと用語を一緒に更新します。

ユビキタス言語は、業務で使われている言葉を無条件に採用することでも、実装上の名前を業務へ押し付けることでもありません。業務上の区別を保ち、モデルとして扱える精度を持つ言語を協業によって育てます。

三つの構成要素でドメイン・モデルを表す

一つのドメイン・モデルに対して、三つの構成要素は次の役割を持ちます。

構成要素	ドメイン・モデルにおける役割
オブジェクト・モデル	概念の型、分類、関係、責務、制約、状態、振る舞いを形式的に表す
知識モデル	用語、概念、分類、意味関係、規則、根拠、出典を探索可能に結ぶ
文芸モデル	業務の文脈、意図、判断理由、事例、既存仕様、説明を自然言語で保持する

構成要素

ドメイン・モデルにおける役割

オブジェクト・モデル

概念の型、分類、関係、責務、制約、状態、振る舞いを形式的に表す

知識モデル

用語、概念、分類、意味関係、規則、根拠、出典を探索可能に結ぶ

文芸モデル

業務の文脈、意図、判断理由、事例、既存仕様、説明を自然言語で保持する

たとえば業務規則は、文芸モデルの説明だけに置くのではなく、知識モデルで根拠と適用範囲をたどれ、必要な部分はオブジェクト・モデルの制約 (Constraint)や振る舞いとして実行可能に表します。三つへ同じ文章を複製するのではなく、それぞれに適した表現を対応付けます。

ドメイン・モデルを反復的に作る

ドメインモデリングは、一度の分析で完成させる直線的な工程ではありません。次の活動を行き来しながら、モデルの妥当性を高めます。

既存文書、会話、事例、規則、用語を文芸モデルとして収集する。
用語と概念を整理し、コンテキストごとの意味を区別する。
境界づけられたコンテキストの候補と相互関係を作る。
概念、分類、関係、規則をオブジェクト・モデルとして形式化する。
意味関係、根拠、出典を知識モデルとして接続する。
生成AIがオブジェクト・モデルを生成、更新する。
開発者がtextus-cbd-supportでモデル、差分、根拠、影響範囲、検証結果をレビューする。
レビュー結果をフィードバックとして生成AIへ返し、必要に応じてドメインエキスパートと業務上の妥当性を確認する。

順序は固定ではありません。形式化したことで用語の曖昧さが見つかり、事例を確認したことで境界が変わり、根拠をたどったことで規則の例外が見つかることがあります。更新の理由と影響を追跡できることが重要です。

生成AIと開発者のモデル開発ループ

生成AIは、大量の文書と用語を読み、概念の候補、重複、矛盾、境界案、形式構造を提示できます。SimpleModelingでは、textus-bokが文芸モデルを知識モデル化して生成AIへ接続し、生成AIがオブジェクト・モデルを主として生成、更新します。オブジェクト・モデルを人間が最初から手作業で記述することよりも、生成AIによる生成と更新を開発の通常ループに組み込むことを重視します。

そのためにtextus-cbd-supportが、生成されたモデルの可視化、前回との差分、根拠、影響範囲、検証結果を開発者へ提示します。開発者はそれらを確認し、モデル構造、設計上の意図、実現可能性、変更影響を判断して、修正方針をフィードバックとして生成AIへ返します。業務上の意味や例外について判断が必要な場合は、ドメインエキスパートの確認もこのループへ接続します。

この開発ループでは、生成AIの回答をそのまま正本にしません。生成AIを主要なモデル作成主体として使いながら、開発者がレビューとフィードバックを継続できることが重要です。用語、根拠、モデル要素、変更理由、レビュー結果の対応を残すことで、AIによる更新を追跡可能な開発作業として扱います。

「注文を確定する」の例

「注文を確定する」を例に考えます。販売コンテキストでは、注文確定は、利用者が注文内容を確定し、以後の変更に制約が加わる業務上の出来事かもしれません。一方、決済コンテキストでは支払いの承認、在庫コンテキストでは在庫の引当が重要です。三つを一つの「確定」という操作 (Operation)へ押し込むと、用語と責任が曖昧になります。

文芸モデルは、利用者の目的、注文確定のシナリオ、例外、業務上の判断理由を記述します。
知識モデルは、「注文確定」の意味、適用するコンテキスト、関連する規則、根拠、決済や在庫との意味関係を結びます。
オブジェクト・モデルは、注文、注文明細、状態、制約、出来事など、販売コンテキストで必要な形式構造を表します。

この整理により、販売、決済、在庫がそれぞれのモデルを保ちながら、境界を越える情報と責任を明示できます。次回は、このドメイン・モデルを使い、利用者の目的をユースケースとして捉え、UI、サービス、操作、イベント (Event)などがどのように協調して目的を実現するかをアプリケーション・モデル (Application Model)として組織します。

まとめ

ドメインモデリングは、問題領域の意味、構造、規則、境界をドメイン・モデルとして組織します。
ドメイン・モデルは第四の構成要素ではなく、オブジェクト・モデル、知識モデル、文芸モデルから目的に必要な要素を組織した適用モデルです。
用語集、コンテキスト、境界づけられたコンテキスト、ユビキタス言語によって、意味と有効範囲を共有します。
三つの構成要素を共通の用語識別子とモデル要素の対応で接続します。
生成AIがオブジェクト・モデルを主として生成、更新し、開発者がtextus-cbd-supportで差分、根拠、影響、検証結果をレビューしてフィードバックを返します。
ドメイン・モデルは、事例、根拠、形式化、AI生成、開発者レビューを往復する開発ループで反復的に改善します。

次回

第9回「アプリケーションモデリング」では、利用者の目的とユースケースを起点に、UIと動的な協調、相互作用によって目的を実現するアプリケーション・モデルを構成します。ドメイン・モデルの状態や振る舞いを土台として利用しながら、UI、サービス、操作、イベントなどの協調を扱います。

参照

サイト内

📄 文芸モデリング

用語集

オブジェクト・モデル (Object Model): Undefined
ドメイン・モデル (Domain Model): Undefined
知識モデル (Knowledge Model): 知識モデル（Knowledge Model）とは、SimpleModelingモデルに含まれる概念、意味関係、分類、規則、根拠、出典などを、主として生成AIが参照、探索、関連付け、解釈できる形で構造化したモデルです。
活動 (Activity): アクティビティスペース内で実行される具体的な行為またはタスク。アルファをより進んだ状態へ移行させるために行われ、通常はワークプロダクトの生成や改良を伴う。
シンプルモデリング (SimpleModeling): SimpleModelingは、KnowledgeからDomain Modelを構成し、CMLで形式化し、CozyとAIによって実行可能ソフトウェアへ実現し、Textus上で動作させる、モデリング中心のソフトウェア開発方法論と技術体系です。
文芸モデル (Literate Model): Undefined
モデル (Model): Modelとは、対象を特定のPurposeとConcernに基づいて選択し、理解、判断、検証、構築に利用できる形で表した抽象です。対象そのものではなく、目的に必要な要素、関係、意味を保持する表現です。
振る舞い (Behavior): UMLにおけるBehaviorは、そのContextとなるBehaviored Classifierが時間とともにどのようにStateを変えるかを定める仕様です。可能な実行、創発する振る舞い、または特定の実行例を表せます。
協調 (Collaboration): UMLにおけるCollaborationは、専門化された機能を担う参加要素のRoleが共同して、目的とする機能を達成する構造を記述するClassifierです。
状態 (State): UMLにおけるStateは、ある不変条件が成立している状況をモデル化したものです。Objectの現在のStateによって、受け付けられるEventやOperation、成立するConstraint、次に可能なTransitionが変わります。
ユースケース (Use Case): UMLにおけるUse Caseは、対象システムがActorまたは他の利害関係者に観測可能な価値あるResultをもたらすために実行するActionの集合を定めるModel Elementです。
属性 (Attribute): Attributeとは、ClassifierのInstanceが保持し得る値または参照を表すStructural Featureです。Attributeは名前、Type、Multiplicity、既定値、Constraintなどによって特徴付けられます。
クラス図 (Class Diagram): Class Diagramとは、Class、Interface、Data Type、Association、Generalization、Dependencyなどを用いて、Modelの静的構造を示すUML Diagramです。
用語集 (Glossary): Glossaryとは、対象領域で使用する用語について、名称、意味、境界、同義語、識別子を管理する知識資源です。関係者が同じ用語を同じ意味で扱うための共通基盤になります。
識別子 (Identifier): Identifierとは、Identityを持つ対象または相関対象を参照し、他の対象から区別するために使用する値です。IdentifierはIdentityを表現できますが、対象が時間を通じて同じ対象であるというIdentityの意味そのものではありません。
テスト (Test): Testとは、指定した条件で対象を実行または評価し、観測した結果を期待する結果やConstraintと比較して、要求または契約への適合を確認する活動とその仕様です。
Cozy Modeling Language (CML): CML（Cozy Modeling Language）は、オブジェクト・モデルのうち、プログラム生成と実行へ接続する実行可能モデルを記述するSimpleModelingの形式モデリング言語です。
責務 (Responsibility): Responsibilityとは、ObjectまたはRoleが、何を知り、判断し、行い、守るべきかを表す義務です。構造上の情報だけでなく、規則とBehaviorの所有を定めます。
制約 (Constraint): UMLにおけるConstraintは、一つ以上のModel ElementのSemanticsの一部を宣言するため、自然言語または機械可読言語で表した条件または制限です。評価結果はBooleanであり、評価は副作用を持ちません。
型 (Type): Undefined
操作 (Operation): UMLにおけるOperationは、関連するBehaviorを呼び出すための名前、型、Parameter、Constraintを定めるClassifierのBehavioral Featureです。Operationは呼び出し契約を定め、MethodなどのBehaviorがその実現を担います。
イベント (Event): UMLにおけるEventは、Behaviorの実行中に発生し得る出来事を記述するものです。EventのOccurrenceを受け取ることで、StateMachineのTransitionなどのBehaviorが起動されます。
アプリケーション・モデル (Application Model): アプリケーション・モデル（Application Model）とは、ユースケースをアプリケーションがどのように実現するかを、参加者、役割、責務、協調、相互作用、状態遷移、イベント、サービス、操作、結果によって表す目的別のモデルです。