概念モデル/分析モデル/設計モデル

Created: 2025-08-11

ドメイン・モデル (Domain Model)は現実世界をソフトウェアで操作可能なモデル (Model)として写し取ったものです。大切な点は、開発対象の問題領域の専門家が持つ「概念世界」を忠実に再現することです。

このようなモデルを構築することで、専門家とモデルを共有し、ソフトウェア開発の整合性と理解度を高めることが可能になります。

ドメイン・モデル作成の条件

もちろん、概念世界の忠実な再現だけではソフトウェア上で動かすことが難しいので、様々な工夫をします。

ドメイン・モデルの作成にあたっての条件は以下のようにまとめることができます。

  • 問題領域の専門家と共有できるように問題領域の概念世界を忠実に再現すること - ソフトウェア上で実現可能な仕組みとして成立させること

問題領域のモデル化には粒度やモデルの切り口など色々な選択肢がありますが、ソフトウェア上で動作する構造の中に収める必要があります。

そのため、事前に定めたソフトウェアで動作するモデル体系のテンプレートに沿ってモデル化を進めるのが実践的です。

SimpleModelingにおけるモデル層

  • 概念モデル - 分析モデル - 設計モデル

以下の図ではSimpleModelingで使用している概念モデル、分析モデル、設計モデルそれぞれのモデル要素の種類を示しています。

詳細は別記事で解説予定ですが、使用するモデル要素の種類が概念モデルから分析モデル、設計モデルと具体度が上がるに従って飛躍的に増えています。

概念モデル / 分析モデル / 設計モデル
図 1. 概念モデル / 分析モデル / 設計モデル

概念モデル、分析モデル、設計モデルの各層は抽象度の違いによって目的と利用者が異なります。

ここでは、それぞれの特徴 (Feature)と運用方法について解説します。

概念モデル

概念モデルはビジネス分析、要求分析の作業分野で使用します。

業務の構造、登場人物、資源、ルールなど、問題領域の構成要素を抽象的・直感的に表現します。

概念モデルは以下の目的を持ちます。

  • ドメインモデルの全体像を概観し、ビジネスの構造や背景文脈を明らかにする。 - ビジネス・オーナーなど、開発の詳細には関与しないステークホルダーとの情報共有に活用。 - 具象度を上げることで分析モデル、設計モデルにそのまま繋がる実現方式との連続性。

概念モデルではユビキタス言語の確立が重要なテーマです。

用語の定義を明確にすることで、誤解や要件のずれを防止します。

また、用語がシステム実現時のオブジェクト (Object)との連続性を担保することで、ステークホルダー間で共有した概念モデルと実装との乖離を防ぐことができます。

用語の定義を中心に、クラス (Class)の分類構造や図表を用いて、複雑な業務の構造を可視化します。

モデルは非技術者でも理解できるよう、わかりやすい形式で提示されます。

分析モデル

分析モデルは、アプリケーションの機能と構造を明確化するためのモデルです。

実行プラットフォームや実装言語などの実行環境、性能 (Performance)セキュリティ (Security)といった横断的関心事、非機能要求といったものからは距離を置いたアプリケーション実現のための純粋なモデルを作成します。

PIM(Platform (プラットフォーム) Independent Model)に相当します。

モデルの基本構造は概念モデルを具体化したもので、概念モデルとの連続性が重要です。

ステークホルダー間で共有した概念モデルの構造や仕組みが、システムの実現とリンクすることを担保します。

分析モデルでは実装技術に依存 (Dependency)しない形で、ドメイン・モデルの構造を詳細化・具体化し、ドメイン・モデル振る舞い (Behavior)を定義していきます。

分析モデルはオン・サイト・カスタマーやドメイン専門家など、システムの内部構成や非機能要件に責任を持つステークホルダーとの対話に活用されます。

設計モデル

設計モデルは、実行プラットフォームや実装言語などの実行環境を前提として、分析モデルを実行環境で動作可能な形に落とし込んだモデルです。

PSM(Platform Specific Model)に相当します。

分析モデルで作成した抽象度の高いモデルを実行環境に向けて具体化していきます。

利用するデータベース、API、Webフレームワークなどの技術スタックと整合性のある記述を行います。

SimpleModelingのリファレンス・モデルでは以下の実行環境に対する設計モデルを作成します。

  • プログラミング言語 : Scala 3 - 基本ライブラリ : Cats - フレームワーク : Cloud-Native Component Framework (SimpleModeling)

Scala 3/Catsを用いて本格的な関数型プログラミングをオブジェクト指向プログラミングに統合する形で導入します。

データベースなどのミドルウェアやクラウド・プラットフォームはCloud-Native Component Framework (CNCF (Cloud Native Component Framework)) が吸収するので、設計時にはCNCFをターゲットにした設計を行います。

設計モデルの枠組みは分析モデルからCozyによって自動生成されるScalaプログラム群です。

設計段階では、この枠組みにScalaプログラミングで肉付けを行っていきますが、必要に応じてUML (Unified Modeling Language)などを用いて補完的な情報を記述します。

設計モデルでは以下の要素の実現を行います。

設計モデルの記述にScalaプログラムを用いますが、設計段階では枠組みの記述にとどめ、実装でScalaプログラミングによる最終的な実現を行います。

Scalaを設計モデルの記述に用いるため、設計と実装の境界が微妙な点がありますが、BDD (Behavior-Driven Development)/TDD (Test-Driven Development)による仕様記述(テスト・プログラム)がコンパイルを通るところまでが設計、テスト・プログラムを全て通すようにScalaプログラミングを行う作業を実装と考えます。

ドメイン・メカニクス

分析モデルでは、ドメイン・モデルそのものの構造と振る舞いにフォーカスしますが、設計モデルではターゲットのプラットフォーム上で具体的な操作 (Operation)を行うメカニズムを考えなければなりません。

SimpleModelingではドメイン・モデル操作する仕組みをドメイン・メカニクスと呼び、ドメイン・モデル本体とは分離して設計します。

代表的なドメイン・メカニクス・オブジェクト:

SimpleModelingでは概念モデル、分析モデル、設計モデルを単純に「上から下へ」と変換するものとしてはとらえません。

各モデルは目的に応じて独立・平行に扱いながら、整合性を保ちつつ並行して進化します。

中心となるのは、CML (Cozy Modeling Language)Cozy Modeling Language)による文芸モデル (Literate Model)で記述した分析モデルです。

この分析モデルを起点に、以下のような方向性で生成・補完が行われます。

  • 上位(抽象): 概念モデルを生成(業務ステークホルダー向け) - 下位(具体): 設計モデルを生成(開発者・実装向け)

SimpleModelingでのモデルの運用
図 2. SimpleModelingでのモデルの運用

分析モデル

分析モデル・アップ・ダウン (Analysis Model Up/Down)の軸になるのが分析モデルです。

CMLで記述した分析モデルからCozyによって概念モデル、設計モデルを生成します。

  • ステークホルダー(オン・サイト・カスタマー、ドメイン専門家など)との仕様共用 - 業務的要件と技術的要件のバランスをとる調整ポイントとして機能

AIによる支援

概念モデルはCMLで記述した分析モデルから自動的または半自動的に生成され、業務の全体像をステークホルダーと共有するために活用されます。

  • ビジネス・オーナーとの目的・価値・制約の共有 - 用語や構造の意味づけを明示するナビゲーションモデルとして機能

AIによる支援

  • 概念モデルの素案作成 - 概念モデルの構築支援 - モデル内用語の説明生成、用語集 (Glossary)との連携補助 === 設計モデル

設計モデルはCozyやAIが自動生成したコードを中心に構築されます。

設計モデルの情報もCMLで記述できるものもあるので、分析モデルのCMLに設計モデル情報として追記することができます。

基本的な枠組みはCozyが生成するので、その枠組みの妥当性の検証と、具体的な肉付けを行います。

AIによる支援

  • BDD/TDDによる仕様記述(テスト・プログラム)の生成 - APIスケルトン、ユニットテスト、ログ出力、例外処理の自動生成 - フレームワーク特化の設計補助・コード提案 === 実装

CozyやAIによって自動生成されたScalaプログラムに対して、具体的な実装や外部連携などを加えて最終的なプログラムに仕上げていきます。

AIによる支援

  • ルールやロジックの実装支援 - 外部API呼び出しコードの生成支援 - コンフィグレーション設定の設定支援 - パフォーマンス改善、セキュリティ設定などの実装補助 == 参照

用語集

モデル (Model)

Modelとは、対象を特定のPurposeとConcernに基づいて選択し、理解、判断、検証、構築に利用できる形で表した抽象です。対象そのものではなく、目的に必要な要素、関係、意味を保持する表現です。

ドメイン・モデル (Domain Model)

Undefined

シンプルモデリング (SimpleModeling)

SimpleModelingは、KnowledgeからDomain Modelを構成し、CMLで形式化し、CozyとAIによって実行可能ソフトウェアへ実現し、Textus上で動作させる、モデリング中心のソフトウェア開発方法論と技術体系です。

特徴 (Feature)

UMLにおけるFeatureは、ClassifierのInstanceを特徴付ける構造上または振る舞い上の性質です。AttributeなどのStructural Featureと、OperationなどのBehavioral Featureがあります。

オブジェクト (Object)

Objectとは、Classまたは他のClassifierによって分類され、構造、State、Behaviorを持ち得るInstanceです。Objectは、同じClassifierの他のInstanceと区別して参照できる個体として扱われます。

クラス (Class)

Undefined

セキュリティ (Security)

Securityとは、情報と機能を正当な権限に従って保護し、不正な閲覧、利用、変更、破壊、否認を防ぐ性質です。Confidentiality、Integrity、Authenticity、AccountabilityなどのConcernを含みます。

性能 (Performance)

Performanceとは、指定された条件と資源のもとで、システムが処理時間、応答時間、Throughput、容量などの時間的要求を満たす性質です。

プラットフォーム (Platform)

Platformとは、ソフトウェアを構築、配置、実行、運用するために共通して利用する技術的な基盤とサービスの集合です。

依存 (Dependency)

UMLにおけるDependencyは、ClientとなるModel Elementの仕様または実装が、Supplierとなる別のModel Elementの定義へ意味的または構造的に依存することを表すDirected Relationshipです。

振る舞い (Behavior)

UMLにおけるBehaviorは、そのContextとなるBehaviored Classifierが時間とともにどのようにStateを変えるかを定める仕様です。可能な実行、創発する振る舞い、または特定の実行例を表せます。

パワータイプ (Powertype)

Undefined

データ型 (Data Type)

UMLにおけるData Typeは、InstanceがIdentityではなく値によって識別されるClassifierです。Data TypeのInstanceは、同じ値を持つ場合に区別されません。

イベント (Event)

UMLにおけるEventは、Behaviorの実行中に発生し得る出来事を記述するものです。EventのOccurrenceを受け取ることで、StateMachineのTransitionなどのBehaviorが起動されます。

状態機械 (StateMachine)

UMLにおけるStateMachineは、Eventの発生によって起動されるTransitionでStateのグラフをたどり、システム要素のevent-driven Behaviorを表すBehaviorです。

コンポーネント (Component)

責務・契約・依存関係を明示的に定義し、再利用可能で交換可能な単位としてカプセル化されたソフトウェア構成要素。論理モデルでは抽象構造単位として、物理モデルでは実装・デプロイメント単位として扱われる。

Scala

Undefined

Cloud Native Component Framework (CNCF)

Cloud Native Component Framework(CNCF)は、クラウド・アプリケーションを構成するコンポーネントを、単一かつ一貫した実行モデルで実行するためのフレームワークです。 Component / Service / Operation という構造を中核とし、command、server(REST / OpenAPI)、client、script といった異なる実行形態から、同一の Operation を再利用できることを特徴とします。 ログ、エラー処理、設定、配備といったクラウド・アプリケーションに必要な品質属性をフレームワーク側に集約することで、コンポーネントはドメイン・ロジックの実装に集中できます。 CNCF は、文芸モデル駆動開発および AI 支援開発を前提に、「何を実行するか」と「どのように呼び出すか」を分離するための実行基盤として設計されています。

Cozy

Cozyは、CMLと各種DSLで記述されたModelを解析し、プログラム、設定、文書などの実現成果物へ変換するSimpleModelingのツールチェーンです。

UML (Unified Modeling Language)

オブジェクト指向分析・設計のための統一モデリング言語。クラス図、シーケンス図、ユースケース図などを通じてシステム構造と動作を表現する。UPおよびCBDの基盤言語。

品質属性 (Quality Attribute)

Quality Attributeとは、ソフトウェアが機能を実行できることに加えて、どの程度の品質で要求を満たすかを表す特性です。Security、Performance、Availability、Reliability、Resilience、Observability、Maintainabilityなどが含まれます。

TDD (Test-Driven Development)

Test Driven Development(TDD, テスト駆動開発)とは、実装に先立ってテストを記述し、そのテストを通すことを起点として実装とリファクタリングを繰り返す開発手法である。

BDD (Behavior-Driven Development)

Behavior Driven Development(BDD, 振る舞い駆動開発)とは、システムの振る舞いをシナリオとして記述し、関係者間で共有可能な形で仕様を明確化する開発アプローチである。

操作 (Operation)

UMLにおけるOperationは、関連するBehaviorを呼び出すための名前、型、Parameter、Constraintを定めるClassifierのBehavioral Featureです。Operationは呼び出し契約を定め、MethodなどのBehaviorがその実現を担います。

永続化 (Persistence)

Undefined

ドメイン・オブジェクト (Domain Object)

ドメイン・オブジェクトとは、ソフトウェアシステムが対象とする現実世界の領域(ドメイン)を表現するためのオブジェクトであり、ビジネスロジックや概念的構造を内包します。 これは、エンティティ、バリュー・オブジェクト、サービス、ルール、イベントなどの要素を含む、ドメイン・モデルを構成する中核的な構造です。 ドメイン・オブジェクトは、システム内でのデータ構造や処理の単なる表現ではなく、問題領域の意味や振る舞いを反映するモデルの一部です。

Cozy Modeling Language (CML)

CML(Cozy Modeling Language)は、オブジェクト・モデルのうち、プログラム生成と実行へ接続する実行可能モデルを記述するSimpleModelingの形式モデリング言語です。

文芸モデル (Literate Model)

Undefined

分析モデル・アップ・ダウン (Analysis Model Up/Down)

分析モデル・アップ・ダウンとは、分析モデルを中核に据え、そこから概念モデルや設計モデルを「上(アップ)」へ導出し、また具体的なコードやデータ定義などを「下(ダウン)」に展開する双方向的なモデリング手法です。

属性 (Attribute)

Attributeとは、ClassifierのInstanceが保持し得る値または参照を表すStructural Featureです。Attributeは名前、Type、Multiplicity、既定値、Constraintなどによって特徴付けられます。

用語集 (Glossary)

Glossaryとは、対象領域で使用する用語について、名称、意味、境界、同義語、識別子を管理する知識資源です。関係者が同じ用語を同じ意味で扱うための共通基盤になります。