概念モデル/分析モデル/設計モデル
ドメイン・モデルは現実世界をソフトウェアで操作可能なモデルとして写し取ったものです。大切な点は、開発対象の問題領域の専門家が持つ「概念世界」を忠実に再現することです。
このようなモデルを構築することで、専門家とモデルを共有し、ソフトウェア開発の整合性と理解度を高めることが可能になります。
ドメイン・モデル作成の条件
もちろん、概念世界の忠実な再現だけではソフトウェア上で動かすことが難しいので、様々な工夫をします。
ドメイン・モデルの作成にあたっての条件は以下のようにまとめることができます。
-
問題領域の専門家と共有できるように問題領域の概念世界を忠実に再現すること
-
ソフトウェア上で実現可能な仕組みとして成立させること
問題領域のモデル化には粒度やモデルの切り口など色々な選択肢がありますが、ソフトウェア上で動作する構造の中に収める必要があります。
そのため、事前に定めたソフトウェアで動作するモデル体系のテンプレートに沿ってモデル化を進めるのが実践的です。
SimpleModelingにおけるモデル層
SimpleModelingではドメイン・モデルを以下の3層で実現します。
-
概念モデル
-
分析モデル
-
設計モデル
以下の図ではSimpleModelingで使用している概念モデル、分析モデル、設計モデルそれぞれのモデル要素の種類を示しています。
詳細は別記事で解説予定ですが、使用するモデル要素の種類が概念モデルから分析モデル、設計モデルと具体度が上がるに従って飛躍的に増えています。

概念モデル、分析モデル、設計モデルの各層は抽象度の違いによって目的と利用者が異なります。
ここでは、それぞれの特徴と運用方法について解説します。
概念モデル
概念モデルはビジネス分析、要求分析の作業分野で使用します。
業務の構造、登場人物、資源、ルールなど、問題領域の構成要素を抽象的・直感的に表現します。
概念モデルは以下の目的を持ちます。
-
ドメインモデルの全体像を概観し、ビジネスの構造や背景文脈を明らかにする。
-
ビジネス・オーナーなど、開発の詳細には関与しないステークホルダーとの情報共有に活用。
-
具象度を上げることで分析モデル、設計モデルにそのまま繋がる実現方式との連続性。
概念モデルではユビキタス言語の確立が重要なテーマです。
用語の定義を明確にすることで、誤解や要件のずれを防止します。
また、用語がシステム実現時のオブジェクトとの連続性を担保することで、ステークホルダー間で共有した概念モデルと実装との乖離を防ぐことができます。
用語の定義を中心に、クラスの分類構造や図表を用いて、複雑な業務の構造を可視化します。
モデルは非技術者でも理解できるよう、わかりやすい形式で提示されます。
分析モデル
分析モデルは、アプリケーションの機能と構造を明確化するためのモデルです。
実行プラットフォームや実装言語などの実行環境、性能やセキュリティといった横断的関心事、非機能要求といったものからは距離を置いたアプリケーション実現のための純粋なモデルを作成します。
PIM(Platform Independent Model)に相当します。
モデルの基本構造は概念モデルを具体化したもので、概念モデルとの連続性が重要です。
ステークホルダー間で共有した概念モデルの構造や仕組みが、システムの実現とリンクすることを担保します。
分析モデルでは実装技術に依存しない形で、ドメイン・モデルの構造を詳細化・具体化し、ドメイン・モデルの振る舞いを定義していきます。
-
エンティティとバリューを用いてドメインの基本構造を記述。
-
データ型、状態機械、パワータイプといったモデル要素を使って、エンティティの構造や振る舞いを具体化。
-
サブシステム、コンポーネントを使って、ドメイン・モデルの境界を明確化。
-
イベント、ワークフロー、サービスを用いてシステムの振る舞いを具体化。
-
ルールを用いてドメインの制約条件、規則を定義。
-
クラウド・ネイティブ要素は必要に応じて盛り込む。
分析モデルはオン・サイト・カスタマーやドメイン専門家など、システムの内部構成や非機能要件に責任を持つステークホルダーとの対話に活用されます。
設計モデル
設計モデルは、実行プラットフォームや実装言語などの実行環境を前提として、分析モデルを実行環境で動作可能な形に落とし込んだモデルです。
PSM(Platform Specific Model)に相当します。
分析モデルで作成した抽象度の高いモデルを実行環境に向けて具体化していきます。
利用するデータベース、API、Webフレームワークなどの技術スタックと整合性のある記述を行います。
SimpleModelingのリファレンス・モデルでは以下の実行環境に対する設計モデルを作成します。
-
プログラミング言語 : Scala 3
-
基本ライブラリ : Cats
-
フレームワーク : Cloud-Native Component Framework (SimpleModeling)
Scala 3/Catsを用いて本格的な関数型プログラミングをオブジェクト指向プログラミングに統合する形で導入します。
データベースなどのミドルウェアやクラウド・プラットフォームはCloud-Native Component Framework (CNCF) が吸収するので、設計時にはCNCFをターゲットにした設計を行います。
設計モデルの枠組みは分析モデルからCozyによって自動生成されるScalaプログラム群です。
設計段階では、この枠組みにScalaプログラミングで肉付けを行っていきますが、必要に応じてUMLなどを用いて補完的な情報を記述します。
設計モデルでは以下の要素の実現を行います。
-
性能やセキュリティといった非機能要求、品質属性。
-
クラウド・ネイティブを実現するためのメカニズム。
設計モデルの記述にScalaプログラムを用いますが、設計段階では枠組みの記述にとどめ、実装でScalaプログラミングによる最終的な実現を行います。
Scalaを設計モデルの記述に用いるため、設計と実装の境界が微妙な点がありますが、BDD/TDDによる仕様記述(テスト・プログラム)がコンパイルを通るところまでが設計、テスト・プログラムを全て通すようにScalaプログラミングを行う作業を実装と考えます。
分析モデル・アップ・ダウン
SimpleModelingでは概念モデル、分析モデル、設計モデルを単純に「上から下へ」と変換するものとしてはとらえません。
各モデルは目的に応じて独立・平行に扱いながら、整合性を保ちつつ並行して進化します。
中心となるのは、CML(Cozy Modeling Language)による文芸モデルで記述した分析モデルです。
この分析モデルを起点に、以下のような方向性で生成・補完が行われます。
-
上位(抽象): 概念モデルを生成(業務ステークホルダー向け)
-
下位(具体): 設計モデルを生成(開発者・実装向け)

分析モデル
分析モデル・アップ・ダウンの軸になるのが分析モデルです。
CMLで記述した分析モデルからCozyによって概念モデル、設計モデルを生成します。
-
ステークホルダー(オン・サイト・カスタマー、ドメイン専門家など)との仕様共用
-
業務的要件と技術的要件のバランスをとる調整ポイントとして機能
概念モデル
概念モデルはCMLで記述した分析モデルから自動的または半自動的に生成され、業務の全体像をステークホルダーと共有するために活用されます。
-
ビジネス・オーナーとの目的・価値・制約の共有
-
用語や構造の意味づけを明示するナビゲーションモデルとして機能