アプリケーション・モデリング

ドメイン・モデルとアプリケーション・モデルの位置付け

SimpleModeling (シンプルモデリング)モデルは、オブジェクト・モデル (Object Model)、知識モデル (Knowledge Model)、文芸モデル (Literate Model)で構成されます。ドメイン・モデルとアプリケーション・モデルは、これらの構成要素から必要なモデル要素を選び、目的に沿って組織した適用モデルです。

観点	ドメイン・モデル	アプリケーション・モデル
関心	対象世界で成り立つこと	利用者が実現したいこと
出発点	事実と観察	ニーズ・目標・ユースケース
主な役割	意味・規則・状態を定義する	ドメインの機能を組み合わせる

観点

ドメイン・モデル

アプリケーション・モデル

関心

対象世界で成り立つこと

利用者が実現したいこと

出発点

事実と観察

ニーズ・目標・ユースケース

主な役割

意味・規則・状態を定義する

ドメインの機能を組み合わせる

ドメイン・モデリングでは、事実の観察から概念や規則を帰納的に整理します。アプリケーション・モデリングでは、その語彙、規則、制約 (Constraint)を利用して、ニーズや目標を実現する振る舞いを定義します。

アプリケーションは薄いオーケストレータになる

アプリケーション・モデルは、入力を受け取り、必要なドメインのサービスやオペレーションを呼び出し、結果やイベント (Event)を次の処理や利用者への応答につなぎます。

業務上の判断、重要なデータ操作、不変条件 (Invariant)の確認、業務状態とその遷移 (Transition)の管理はドメイン側の責務 (Responsibility)です。状態機械 (StateMachine)もドメイン・モデル側で定義し、アプリケーションはサービスやイベントを通じて利用します。

この役割分担によって、アプリケーションは利用者の目的に沿った調整に集中し、ドメインの意味と規則は共通の基盤として保たれます。

分けて定義する意義

ドメイン・モデルは対象世界の理解を蓄積し、比較的長いライフサイクル (Lifecycle)を持ちます。事実の発見、理解の深化、制度や業務の変化を契機として更新します。

アプリケーション・モデルは、ステークホルダーのニーズや利用環境の変化に応じて更新します。両者を分けて定義すると、対象世界の理解を共有しながら、ニーズに応じた振る舞いを継続的に具体化できます。

一つのアプリケーションが複数のドメインを束ねる

アプリケーション・モデルの意義の一つは、複数のドメインを束ねるオーケストレータとしての役割です。利用者の目的を達成するために、各ドメインの機能を組み合わせ、呼び出し順序、結果やイベントの受け渡し、失敗時の扱いを調整します。

たとえば注文、在庫、決済をそれぞれのドメインで管理する場合、アプリケーションは一連の手続きを組み立てます。各ドメインは自身の意味、規則、状態 (State)を管理し、アプリケーションはそれらの機能を目的に沿って結びつけます。

ニーズごとのアプリケーションから共通ドメインを利用する

同じドメインに対して、異なるステークホルダーが異なるニーズを持つことがあります。この場合は、ニーズごとのアプリケーション・モデルを受け皿として、共通のドメイン・モデルを利用します。

たとえば顧客向けの注文アプリケーションと業務担当者向けの注文管理アプリケーションは、目標やユースケース (Use Case)が異なります。両者で注文ドメインの意味や規則を共有し、それぞれに必要な振る舞いを定義できます。

共有の対象には、エンティティ、バリュー、関係、規則、イベント、業務状態などのドメイン知識があります。実装時には、必要に応じてコンポーネント (Component)や実行基盤も共有します。

個別のニーズの変化は各アプリケーションで受け止めます。共通ドメインを更新する場合は、それを利用する各アプリケーションへの影響を確認します。

ユースケースシナリオから実現モデルへ

ユースケースは、アクターの目標と、その目標を達成するシナリオを記述します。アプリケーション・モデリングでは、シナリオに現れる行動を、UIとの境界、内部の参加者、処理、結果へ対応付けます。

文芸モデルのユースケースシナリオ (Use Case Scenario)からユースケース実現モデル (Use Case Realization Model)を構成し、その対応をレビューします。承認した実行可能モデル (Executable Model)をCML (Cozy Modeling Language)で記述することで、要求から実装へ至る経路を追跡できます。

「注文を確定する」を具体化する

利用者が注文内容を確認し、確定を要求し、その結果を受け取るシナリオを考えます。

UIは注文内容を提示し、確定要求をアプリケーションへ渡します。
アプリケーションは要求を受け取り、注文ドメインの確定オペレーションを呼び出します。
注文ドメインは業務規則や不変条件を確認し、注文データと業務状態を更新して、注文確定イベントを発行します。
アプリケーションは結果を受け取り、必要な後続処理につなぎ、UIへ応答します。

シナリオの各行動と、これらの処理や結果の対応を保持します。正常な流れと失敗時の扱いを確認する際にも、この対応が根拠になります。

協調と相互作用で対応を確認する

協調 (Collaboration)は、UI、アプリケーション、ドメインのサービスなどが、どの役割と責務を担って目的を実現するかを表します。相互作用は、具体的な呼び出し、結果、イベントの順序を実行例として表します。

協調で参加者の構造を整理し、相互作用でシナリオの実行例を確認します。複数のドメインを利用する場合も、アプリケーションによる調整と、各ドメインが担う判断や操作への対応を明らかにします。

プロパティによってオペレーションの性質を調整する

アプリケーション・モデルとドメイン・モデルでは、必要とされるオペレーションの性質も異なります。その性質をコンポーネント、サービス、オペレーションのプロパティとして設定し、デフォルトと個別の指定によって調整します。必要な性質を明確にすることで、実現時に適した実行形態を選び、最適化につなげられます。

コンポーネントには、アプリケーション用途、ドメイン用途、両方という用途を設定します。単一用途のコンポーネントでは、その用途がサービスのデフォルトになります。サービスには個別の用途を指定でき、オペレーションはサービスの性質を引き継ぎます。

アプリケーション用途のサービスはステートレス（stateless）、ドメイン用途のサービスはステートフル（stateful）をデフォルトとします。個別の要件に応じて、サービスやオペレーションで設定を変更できます。

ステートレスなオペレーションは、正しい実行に必要な状態を引数や外部の永続化機構から取得し、呼び出しをまたぐメモリ常駐状態に依存 (Dependency)せずに処理します。ドメインの永続化 (Persistence)データを更新する処理も、この性質を持てます。ステートフルの区別では、呼び出しをまたぐメモリ常駐状態への依存を扱います。

クラウド・ファンクションとして実現する例

ステートレスなオペレーションは、クラウド・ファンクションとしての実現候補になります。アプリケーション用途のコンポーネントやサービスでは、デフォルトの性質を引き継ぐオペレーションがその対象になります。

実装時には処理時間や資源などの実行基盤の条件を確認し、クラウド・ファンクションや通常のサーバー上のオペレーションとして実現します。利用量と料金体系の条件が合えば、クラウド・ファンクション化によって大幅なコスト削減につながります。これは、プロパティで定めた性質を実現時の最適化に生かす一例です。

生成AIによるモデル管理と人間の承認

生成AIが、ユースケースシナリオからサービス、オペレーション、イベントなどへの対応を提案し、モデル (Model)を生成・管理します。人間は、目的が達成されるか、重要な業務判断やデータ操作が適切なドメインに置かれているか、境界や失敗時の扱いが明確かをレビューして承認します。

CBD (Component-Based Development)を支援するtextus-cbd-supportは、シナリオとモデルの対応、変更の差分、根拠、検証情報を可視化します。相互作用に記述した実行例への適合も、モデルの振る舞いを確認する材料になります。

承認した実行可能モデルをCMLで記述し、Cozyによるプログラムの自動生成とTextusの実行基盤へ接続します。利用者からのフィードバックを次のニーズやモデルの更新へつなぐことで、ドメインの意味的な基盤を共有しながら、アプリケーションを継続的に進化させます。

参照

用語集

ドメイン・モデリング (Domain Modeling): Undefined
アプリケーション・モデリング (Application Modeling): アプリケーション・モデリング（Application Modeling）とは、ユースケースをアプリケーションが実現する振る舞いとして具体化し、アプリケーション・モデルを構成する活動です。ユースケースシナリオから、参加者、役割、責務、協調、相互作用、状態遷移、イベント、サービス、操作への対応を明らかにします。
ドメイン・モデル (Domain Model): Undefined
振る舞い (Behavior): UMLにおけるBehaviorは、そのContextとなるBehaviored Classifierが時間とともにどのようにStateを変えるかを定める仕様です。可能な実行、創発する振る舞い、または特定の実行例を表せます。
操作 (Operation): UMLにおけるOperationは、関連するBehaviorを呼び出すための名前、型、Parameter、Constraintを定めるClassifierのBehavioral Featureです。Operationは呼び出し契約を定め、MethodなどのBehaviorがその実現を担います。
アプリケーション・モデル (Application Model): アプリケーション・モデル（Application Model）とは、ユースケースをアプリケーションがどのように実現するかを、参加者、役割、責務、協調、相互作用、状態遷移、イベント、サービス、操作、結果によって表す目的別のモデルです。
オブジェクト・モデル (Object Model): Undefined
知識モデル (Knowledge Model): 知識モデル（Knowledge Model）とは、SimpleModelingモデルに含まれる概念、意味関係、分類、規則、根拠、出典などを、主として生成AIが参照、探索、関連付け、解釈できる形で構造化したモデルです。
シンプルモデリング (SimpleModeling): SimpleModelingは、KnowledgeからDomain Modelを構成し、CMLで形式化し、CozyとAIによって実行可能ソフトウェアへ実現し、Textus上で動作させる、モデリング中心のソフトウェア開発方法論と技術体系です。
文芸モデル (Literate Model): Undefined
制約 (Constraint): UMLにおけるConstraintは、一つ以上のModel ElementのSemanticsの一部を宣言するため、自然言語または機械可読言語で表した条件または制限です。評価結果はBooleanであり、評価は副作用を持ちません。
イベント (Event): UMLにおけるEventは、Behaviorの実行中に発生し得る出来事を記述するものです。EventのOccurrenceを受け取ることで、StateMachineのTransitionなどのBehaviorが起動されます。
責務 (Responsibility): Responsibilityとは、ObjectまたはRoleが、何を知り、判断し、行い、守るべきかを表す義務です。構造上の情報だけでなく、規則とBehaviorの所有を定めます。
遷移 (Transition): UMLにおけるTransitionは、StateMachine内のSource VertexからTarget Vertexへ進む有向関係です。Trigger、Guard、Effectなどによって、いつ遷移し何を実行するかを定めます。
不変条件 (Invariant): Invariantとは、対象が有効である間、観測可能な安定点で常に成立しなければならないConstraintです。Object、Type、または複数要素からなる構造に適用できます。
状態機械 (StateMachine): UMLにおけるStateMachineは、Eventの発生によって起動されるTransitionでStateのグラフをたどり、システム要素のevent-driven Behaviorを表すBehaviorです。
ライフサイクル (Lifecycle): Lifecycleとは、ある対象が生成されてから終了するまでに、Identityを保ちながら通過するStateとTransitionの範囲です。
状態 (State): UMLにおけるStateは、ある不変条件が成立している状況をモデル化したものです。Objectの現在のStateによって、受け付けられるEventやOperation、成立するConstraint、次に可能なTransitionが変わります。
ユースケース (Use Case): UMLにおけるUse Caseは、対象システムがActorまたは他の利害関係者に観測可能な価値あるResultをもたらすために実行するActionの集合を定めるModel Elementです。
コンポーネント (Component): 責務・契約・依存関係を明示的に定義し、再利用可能で交換可能な単位としてカプセル化されたソフトウェア構成要素。論理モデルでは抽象構造単位として、物理モデルでは実装・デプロイメント単位として扱われる。
ユースケースシナリオ (Use Case Scenario): Undefined
ユースケース実現モデル (Use Case Realization Model): UPにおけるUse Case Realizationは、ユースケースの振る舞いを、設計モデル内で協調するモデル要素によってどのように実現するかを記述します。ユースケース実現モデルは、ユースケースのシナリオと、それを実現する参加者、責務、相互作用、操作、結果の対応を表すモデルです。
Cozy Modeling Language (CML): CML（Cozy Modeling Language）は、オブジェクト・モデルのうち、プログラム生成と実行へ接続する実行可能モデルを記述するSimpleModelingの形式モデリング言語です。
実行可能モデル (Executable Model): Undefined
協調 (Collaboration): UMLにおけるCollaborationは、専門化された機能を担う参加要素のRoleが共同して、目的とする機能を達成する構造を記述するClassifierです。
永続化 (Persistence): Undefined
依存 (Dependency): UMLにおけるDependencyは、ClientとなるModel Elementの仕様または実装が、Supplierとなる別のModel Elementの定義へ意味的または構造的に依存することを表すDirected Relationshipです。
モデル (Model): Modelとは、対象を特定のPurposeとConcernに基づいて選択し、理解、判断、検証、構築に利用できる形で表した抽象です。対象そのものではなく、目的に必要な要素、関係、意味を保持する表現です。
CBD (Component-Based Development): CBD（コンポーネント指向開発）は、ソフトウェアを責務・契約・インターフェースを明確に定義したコンポーネント単位で構築・再利用する開発方式です。コンポーネントは独立性と交換可能性を備え、システムを疎結合に構成することで保守性と再利用性を高めます。論理モデルでは機能や契約を定義する抽象構造単位として、物理モデルでは実際の実装・デプロイメント単位として扱われます。
Cozy: Cozyは、CMLと各種DSLで記述されたModelを解析し、プログラム、設定、文書などの実現成果物へ変換するSimpleModelingのツールチェーンです。
Textus: Textusは、SimpleModelingによって実現されたソフトウェアを動作させるための実行基盤です。アプリケーションに共通する実行、運用、連携の機構を提供します。