SimpleModelingにおけるアーキテクチャセントリック
この記事では、Unified Processの原則であるArchitecture-Centricを、SimpleModelingがAI時代向けにどのように再解釈するかを説明します。アーキテクチャは単なる設計成果物ではなく、モデリング・実装・実行・知識管理・運用を安定化する開発フレームワークとして扱われます。
AI時代における再解釈
アーキテクチャセントリックなプロセスでは、アーキテクチャは単なる設計成果物ではありません。要求、分析モデル、設計モデル、配置構造、運用構造は、アーキテクチャビューを通して解釈・精緻化されます。
これはAI時代においてさらに重要になります。生成AIは、構造・文脈・責務・ビューが明示されているほど安定して動作するためです。
アーキテクチャは、開発全体を通して反復的に精緻化されます。各イテレーションでは、概念モデル・実装構造・実行環境・運用知識が、一貫したアーキテクチャ枠組みの中で漸進的に精緻化されます。
SimpleModelingリファレンス・プロファイル
SimpleModeling Reference Profileでは、開発を支える複数のアーキテクチャを定義しています。
SimpleModelingのStandard Profileでは、Reference Profileで定義されたすべてのアーキテクチャを採用します。実際のプロジェクトでは、利用者はこれらのアーキテクチャを参考にしながら、一部をカスタマイズ・置換・拡張して利用できます。
以下では、SimpleModelingで利用される代表的なアーキテクチャを説明します。
-
4+1ビュー・モデル
-
3層リファレンスアーキテクチャ
-
文芸的アーキテクチャ
-
知識アーキテクチャ
-
プロセスアーキテクチャ
4+1ビュー・モデル
SimpleModelingは、Unified ProcessでPhilippe Kruchtenが提唱した*4+1ビュー・モデル*を継承し、人が読める文芸的記述（SmartDox）と構造的な設計モデル（Cozy）を結びつける多視点モデリングフレームワークとして再解釈します。各ビューはシステムの異なる関心事に対応します。
| ビュー | 焦点 | 対応モデル |
|---|---|---|
ユースケースビュー |
利用者の目的とシナリオ |
UseCase, Scenario |
論理ビュー |
ドメイン概念と関係構造 |
Entity, Value, Rule |
プロセスビュー |
振る舞い・並行処理・ワークフロー |
|
開発ビュー |
コンポーネント・モジュール・インターフェース |
|
物理ビュー |
配備と実行時構成 |
Deployment, Node |
「＋1」としてのユースケースビューは、利用者の意図をシステムアーキテクチャへと結びつける起点となります。これらのビューが統合されることで、一貫したアーキテクチャベースラインが形成されます。
関連記事を以下に示します。
3層リファレンスアーキテクチャ
SimpleModelingリファレンス・プロファイルでは、アーキテクチャベースラインをPresentation（表示）、Application（応用）、Domain（ドメイン）の3つのサブシステムで構成する、現代的に再解釈された3層アーキテクチャを採用しています。この構造がモデリング・コード生成・デプロイメントの安定した基盤となります。
| サブシステム | 責務 | 主要モデル |
|---|---|---|
Presentation |
UI・API・ユーザー対話 |
View, Controller, APIComponent |
Application |
ユースケース統合・処理制御 |
Service, UseCase, Workflow |
Domain |
ビジネスロジックと中核知識 |
Entity, Value, Rule, DomainEvent |
この階層構造は4+1モデルのLogical／Development／Physicalビューと整合し、システム全体の分析容易性・進化可能性・自動化適性を高めます。
関連記事を以下に示します。
実行アーキテクチャ
SimpleModelingでは、実行時振る舞い・実行境界・運用構造を安定化するための実行アーキテクチャを定義します。
-
CNCF実行アーキテクチャ：ライフサイクル (Lifecycle)、サービス、セレクタ、実行コンテキストを標準化します。
-
CQRS＋ジョブアーキテクチャ：同期・非同期実行境界を安定化します。
-
Form API／Static Form Appアーキテクチャ：UI実行構造と画面遷移構造を標準化します。
関連記事を以下に示します。
文芸的アーキテクチャ
SimpleModelingは、アーキテクチャセントリックの概念を文芸的アーキテクチャ（Literate Architecture）へと拡張します。各アーキテクチャ決定・モデル・ビューは、人が読めるSmartDox形式で記述され、Cozyモデルとリンクします。これにより、アーキテクチャは実行可能で説明可能なものになります。
関連記事を以下に示します。
-
📄 Error:/domain-modeling/simple-object.dox
知識アーキテクチャ
SimpleModelingでは、知識の構造・表現・循環を安定化するための知識アーキテクチャを定義します。
-
文芸モデル (Literate Model)／SmartDoxアーキテクチャ：知識を半構造文書として整理します。
関連記事を以下に示します。
プロセスアーキテクチャ
SimpleModelingでは、開発活動と成果物流れを安定化するためのプロセスアーキテクチャを定義します。
-
Process／Activity／Skillアーキテクチャ：開発順序・責務・成果物流れを定義します。
関連記事を以下に示します。
アーキテクチャメカニズム
SimpleModelingでは、アーキテクチャを安定化・制約・支援するためのアーキテクチャメカニズムも定義します。これらはアーキテクチャそのものではなく、アーキテクチャセントリック開発を実践的かつ安定的に成立させるための基盤構造です。
-
型システム：構造とデータ関係を制約 (Constraint)します。
-
Executable Specification：法則や実行可能ルールによって振る舞い (Behavior)を制約します。
-
Vocabulary／Glossary：用語と意味的一貫性を安定化します。
アーキテクチャメカニズムに関する記事を以下に示します。
ハーネスエンジニアリング
Harness Engineeringの観点から見ると、SimpleModeling Reference Profileで定義されるアーキテクチャとアーキテクチャメカニズムは、全体として開発ハーネスシステムとして解釈できます。実行・知識・プロセスの境界をアーキテクチャによって構造化することで、開発全体の安定性と再現性を高めます。
これはAI時代においてさらに重要になります。生成AIは、開発環境が明示的に構造化されているほど安定して動作するためです。
まとめ
SimpleModelingにおけるアーキテクチャセントリック開発とは、モデル・実行構造・知識構造・プロセスを統合アーキテクチャの枠組みで整合させることです。SimpleModeling Reference Profileは、概念理解と実行可能システムを結びつける再利用可能なアーキテクチャ基盤を提供します。
参照
用語集
- UP (Unified Process)
-
UMLを基盤とし、反復型・ユースケース駆動・アーキテクチャ中心のプロセスモデル。Rational Unified Process (RUP) などの派生形を持ち、CBD（コンポーネント指向開発）の実践基盤となる。
- シンプルモデリング (SimpleModeling)
-
SimpleModelingは、KnowledgeからDomain Modelを構成し、CMLで形式化し、CozyとAIによって実行可能ソフトウェアへ実現し、Textus上で動作させる、モデリング中心のソフトウェア開発方法論と技術体系です。
- SimpleModelingリファレンス・プロファイル (SMRP, SimpleModeling Reference Profile)
-
SimpleModelingのリファレンス・プロファイルです。 SimpleModelingによる文芸モデル駆動開発の説明を具体的にするために、リファレンス・プロファイルを定義しています。
- モデル (Model)
-
Modelとは、対象を特定のPurposeとConcernに基づいて選択し、理解、判断、検証、構築に利用できる形で表した抽象です。対象そのものではなく、目的に必要な要素、関係、意味を保持する表現です。
- ビュー (View)
-
Viewとは、Modelを特定のPurposeとConcernに応じて選択し、理解、判断、検証、利用できる形で投影した表現です。ViewはModelの一部を見せるものであり、元のModelとは別に意味を所有しません。
- 実行アーキテクチャ (Execution Architecture)
-
モデル層と実行層を分離した技術的・実行的基盤。Scala・TypeScript・CDK・ECSなどを含む。
- Cozy
-
Cozyは、CMLと各種DSLで記述されたModelを解析し、プログラム、設定、文書などの実現成果物へ変換するSimpleModelingのツールチェーンです。
- 振る舞い (Behavior)
-
UMLにおけるBehaviorは、そのContextとなるBehaviored Classifierが時間とともにどのようにStateを変えるかを定める仕様です。可能な実行、創発する振る舞い、または特定の実行例を表せます。
- 活動 (Activity)
-
アクティビティスペース内で実行される具体的な行為またはタスク。アルファをより進んだ状態へ移行させるために行われ、通常はワークプロダクトの生成や改良を伴う。
- 状態機械 (StateMachine)
-
UMLにおけるStateMachineは、Eventの発生によって起動されるTransitionでStateのグラフをたどり、システム要素のevent-driven Behaviorを表すBehaviorです。
- インターフェース (Interface)
-
Undefined
- コンポーネント (Component)
-
責務・契約・依存関係を明示的に定義し、再利用可能で交換可能な単位としてカプセル化されたソフトウェア構成要素。論理モデルでは抽象構造単位として、物理モデルでは実装・デプロイメント単位として扱われる。
- 責務 (Responsibility)
-
Responsibilityとは、ObjectまたはRoleが、何を知り、判断し、行い、守るべきかを表す義務です。構造上の情報だけでなく、規則とBehaviorの所有を定めます。
- Cloud Native Component Framework (CNCF)
-
Cloud Native Component Framework（CNCF）は、クラウド・アプリケーションを構成するコンポーネントを、単一かつ一貫した実行モデルで実行するためのフレームワークです。 Component / Service / Operation という構造を中核とし、command、server（REST / OpenAPI）、client、script といった異なる実行形態から、同一の Operation を再利用できることを特徴とします。 ログ、エラー処理、設定、配備といったクラウド・アプリケーションに必要な品質属性をフレームワーク側に集約することで、コンポーネントはドメイン・ロジックの実装に集中できます。 CNCF は、文芸モデル駆動開発および AI 支援開発を前提に、「何を実行するか」と「どのように呼び出すか」を分離するための実行基盤として設計されています。
- ライフサイクル (Lifecycle)
-
Lifecycleとは、ある対象が生成されてから終了するまでに、Identityを保ちながら通過するStateとTransitionの範囲です。
- 文芸モデル (Literate Model)
-
Undefined
- 用語集 (Glossary)
-
Glossaryとは、対象領域で使用する用語について、名称、意味、境界、同義語、識別子を管理する知識資源です。関係者が同じ用語を同じ意味で扱うための共通基盤になります。
- BoK (Body of Knowledge)
-
SimpleModelingでは文脈共有の核となる知識体系をBoK (Body of Knowledge)と呼んでいます。 BoKの構築は、知識の共有、教育、AIによる支援、自動化、意思決定支援を可能にするための基盤です。
- 型 (Type)
-
Undefined
- 制約 (Constraint)
-
UMLにおけるConstraintは、一つ以上のModel ElementのSemanticsの一部を宣言するため、自然言語または機械可読言語で表した条件または制限です。評価結果はBooleanであり、評価は副作用を持ちません。
- DSL (Domain Specific Language)
-
DSL（ドメイン固有言語）は、特定の領域（ドメイン）に特化して設計された言語であり、その分野の概念や構造を直接的かつ簡潔に表現することを目的とします。 一般的な汎用プログラミング言語（GPL）に比べ、DSLは特定ドメインの問題解決や自動生成に適した高い抽象度を持ちます。