第237章　Model工程

237.1 提出背景

第236章建立了 Controller 工程，明确了 Controller 的主要职责是：

$Request→Controller→Service→Result→ResponseRequest \rightarrow Controller \rightarrow Service \rightarrow Result \rightarrow Response$

Controller 负责请求控制，但真正承载 ICAI 内部对象、业务流程、领域计算和数据持久化的，是 Model 工程。

传统 MVC 中经常将 Model 简单理解为“数据库模型”。但对于 ICAI 而言，这种理解是不完整的。

ICAI 的 Model 工程必须能够表达：

现实个体对应的 Domain Object；
Domain Object 的业务处理；
Engine 的领域计算；
Repository 的数据持久化；
这些对象之间的调用和依赖关系。

因此，本章将 ICAI Model 定义为一个完整的工程模型：

$Model=DomainObject+Service+Engine+RepositoryModel= DomainObject+ Service+ Engine+ Repository$

其核心关系为：

$Controller→Service→Engine→DomainObject→Repository→MySQL\boxed{ Controller \rightarrow Service \rightarrow Engine \rightarrow DomainObject \rightarrow Repository \rightarrow MySQL }$

其中 Service、Engine、Domain Object、Repository 并不是同一个层次的同一种对象，而是 Model 工程中的不同职责。

237.2 Model工程定义

**Model工程（Model Engineering）**是指将 ICAI 理论模型、领域对象、业务流程、领域计算和数据持久化组织成可以独立运行的软件结构。

定义：

$ModelEngineering=DomainObject+Service+Engine+RepositoryModelEngineering= DomainObject+ Service+ Engine+ Repository$

其中：

$DomainObject→表示对象DomainObject \rightarrow 表示对象$ $Service→组织业务流程Service \rightarrow 组织业务流程$ $Engine→执行领域计算Engine \rightarrow 执行领域计算$ $Repository→负责数据持久化Repository \rightarrow 负责数据持久化$

因此 Model 不是一个简单的 PHP 文件，也不是单独的一张数据库表。

$Model≠DatabaseTableModel\neq DatabaseTable$ $Model≠OnePHPClassModel\neq OnePHPClass$ $Model≠RepositoryModel\neq Repository$

而是：

$Model=多个具有明确职责的工程对象及其关系\boxed{ Model= 多个具有明确职责的工程对象及其关系 }$

237.3 Model与MVC

ICAI MVC 可以表示为：

$MVC=Controller+Model+ViewMVC= Controller+ Model+ View$

其中 Model 内部进一步展开：

$Model=DomainObject+Service+Engine+RepositoryModel= DomainObject+ Service+ Engine+ Repository$

因此：

MVC
│
├── Controller
│
├── Model
│   ├── Domain Object
│   ├── Service
│   ├── Engine
│   └── Repository
│
└── View
    └── Smarty

完整请求链：

Request
↓
Controller
↓
Model
├── Service
├── Engine
├── Domain Object
└── Repository
↓
MySQL

MySQL
↓
Repository
↓
Domain Object
↓
Engine
↓
Service
↓
Controller
↓
View
↓
Smarty
↓
HTML

因此：

$Controller→Model→ViewController\rightarrow Model\rightarrow View$

构成 ICAI MVC 的基本结构。

237.4 Domain Object

**Domain Object（领域对象）**是 ICAI 理论中的领域实体在程序中的对象化表达。

第156章已经建立：

$DomainObject=Identity+Structure+State+Relation+ResponsibilityDomainObject= Identity+ Structure+ State+ Relation+ Responsibility$

因此 Domain Object 不是数据库记录的简单复制。

例如机器个体：

$MachineIndividual={ID,Type,Object,Attribute,State,Relation,Knowledge,Goal,Capability,Method,Behavior,Memory,Maintenance}MachineIndividual= \{ ID, Type, Object, Attribute, State, Relation, Knowledge, Goal, Capability, Method, Behavior, Memory, Maintenance \}$

PHP 中可以表示为：

class MachineIndividual
{
    protected $id;
    protected $type;
    protected $objects;
    protected $attributes;
    protected $states;
    protected $relations;
    protected $knowledge;
    protected $goals;
    protected $capabilities;
    protected $methods;
    protected $behaviors;
    protected $memory;
    protected $maintenance;
}

Domain Object 的主要职责是表达：

$WhatIsTheObjectWhatIsTheObject$

即：

这个对象是什么、具有什么结构、处于什么状态、与什么对象存在关系。

237.5 Domain Object与数据记录

Domain Object 和数据库记录必须区分。

数据库记录：

$DatabaseRecord=Fields+ValuesDatabaseRecord= Fields+Values$

Domain Object：

$DomainObject=Identity+Structure+State+Relation+ResponsibilityDomainObject= Identity+ Structure+ State+ Relation+ Responsibility$

例如数据库：

machine_individuals

id
type
name
status
created_at

这只是数据记录。

而：

MachineIndividual

则可以拥有：

identity
type
state
relations
knowledge
capabilities
methods
behaviors
memory

因此：

$DomainObject≠DatabaseRecordDomainObject\neq DatabaseRecord$

正确转换：

$DatabaseRecord→Repository→DomainObjectDatabaseRecord \rightarrow Repository \rightarrow DomainObject$

而不是：

$DatabaseRecord=DomainObjectDatabaseRecord=DomainObject$

237.6 Service

**Service（服务）**负责组织一个完整的业务过程，将 Controller 请求转换为一个可以执行的业务流程。

定义：

$Service=BusinessProcessService= BusinessProcess$

例如机器个体创建：

$CreateIndividualServiceCreateIndividualService$

可能组织：

$Parameter→Validation→DomainObject→Engine→Repository→ResultParameter \rightarrow Validation \rightarrow DomainObject \rightarrow Engine \rightarrow Repository \rightarrow Result$

Service 的核心职责不是保存一张表，而是组织多个操作。

例如：

class IndividualService
{
    protected $engine;
    protected $repository;

    public function create($params)
    {
        // 参数检查
        // 创建领域对象
        // 调用领域计算
        // 保存对象
        // 返回结果
    }
}

因此：

$Service≠ControllerService\neq Controller$ $Service≠EngineService\neq Engine$ $Service≠RepositoryService\neq Repository$

Service 负责的是：

$ProcessProcess$

而不是单个计算。

237.7 Service与Domain Object

Service 可以创建、读取、修改和协调 Domain Object。

例如：

$Service→MachineIndividualService \rightarrow MachineIndividual$

创建过程：

$Request→Service→MachineIndividualRequest \rightarrow Service \rightarrow MachineIndividual$

更新过程：

$Request→Service→MachineIndividual→ModifyRequest \rightarrow Service \rightarrow MachineIndividual \rightarrow Modify$

因此 Service 是业务流程与 Domain Object 之间的重要协调者。

但是：

$Service≠DomainObjectService\neq DomainObject$

Domain Object 表示：

对象是什么。

Service 表示：

系统要对这个对象完成什么业务过程。

237.8 Engine

**Engine（引擎）**负责执行特定领域的计算、判断、匹配、状态转换或规则处理。

定义：

$Engine=DomainCalculation+RuleProcessing+StateProcessing+ResultGenerationEngine= DomainCalculation+ RuleProcessing+ StateProcessing+ ResultGeneration$

例如：

CognitiveEngine
CapabilityEngine
MatchingEngine
DecisionEngine
BehaviorEngine
RiskEngine
LifecycleEngine

例如 CapabilityEngine：

$Goal→CapabilityRequirement→CapabilityMatching→CapabilityResultGoal \rightarrow CapabilityRequirement \rightarrow CapabilityMatching \rightarrow CapabilityResult$

DecisionEngine：

$Goal→Candidate→Risk→Constraint→DecisionGoal \rightarrow Candidate \rightarrow Risk \rightarrow Constraint \rightarrow Decision$

LifecycleEngine：

$Create→Initialize→Load→Run→Modify→Save→Update→DestroyCreate \rightarrow Initialize \rightarrow Load \rightarrow Run \rightarrow Modify \rightarrow Save \rightarrow Update \rightarrow Destroy$

因此：

$Engine≠ServiceEngine\neq Service$

Service 负责组织过程：

$Service→Engine1→Engine2→Engine3Service\rightarrow Engine_1\rightarrow Engine_2\rightarrow Engine_3$

Engine 负责执行具体领域计算。

237.9 Engine与Domain Object

Engine 通常以 Domain Object 作为计算对象。

例如：

$CapabilityEngine→CognitiveCapabilityCapabilityEngine \rightarrow CognitiveCapability$ $DecisionEngine→CognitiveDecisionDecisionEngine \rightarrow CognitiveDecision$ $BehaviorEngine→CognitiveBehaviorBehaviorEngine \rightarrow CognitiveBehavior$ $RiskEngine→CognitiveRiskRiskEngine \rightarrow CognitiveRisk$

因此：

$DomainObject↔EngineDomainObject \leftrightarrow Engine$

但二者职责不同：

$DomainObject=ObjectDomainObject=Object$ $Engine=CalculationEngine=Calculation$

例如：

class CognitiveCapability
{
    protected $id;
    protected $object;
    protected $condition;
    protected $state;
    protected $range;
}

而：

class CapabilityEngine
{
    public function match($goal, $capability)
    {
        return null;
    }

    public function evaluate($capability, $condition)
    {
        return null;
    }
}

前者表达能力对象，后者计算能力状态和匹配结果。

237.10 Repository

**Repository（仓储）**负责 Domain Object 与持久化系统之间的数据转换和访问。

定义：

$Repository=DomainObject↔PersistenceRepository= DomainObject \leftrightarrow Persistence$

典型结构：

$DomainObject→Repository→MySQLDomainObject \rightarrow Repository \rightarrow MySQL$

读取：

$MySQL→Repository→DomainObjectMySQL \rightarrow Repository \rightarrow DomainObject$

例如：

class IndividualRepository
{
    public function find($id)
    {
        return null;
    }

    public function save($individual)
    {
        return false;
    }

    public function update($individual)
    {
        return false;
    }

    public function delete($id)
    {
        return false;
    }
}

Repository 的核心职责是：

查询；
新增；
保存；
更新；
删除或归档；
数据映射。

因此：

$Repository≠ServiceRepository\neq Service$ $Repository≠EngineRepository\neq Engine$

Repository 不应该负责：

$Goal→Capability→DecisionGoal\rightarrow Capability\rightarrow Decision$

这类领域计算。

237.11 Repository与MySQL

Repository 是 Domain Object 与数据库之间的边界。

错误结构：

$DomainObject→MySQLDomainObject \rightarrow MySQL$

正确结构：

$DomainObject→Repository→MySQLDomainObject \rightarrow Repository \rightarrow MySQL$

例如：

MachineIndividual
↓
MachineIndividualRepository
↓
machine_individuals

多个领域对象：

CognitiveObject
↓
CognitiveObjectRepository
↓
cognitive_objects

CognitiveCapability
↓
CapabilityRepository
↓
cognitive_capabilities

因此：

$Repository→PersistenceRepository \rightarrow Persistence$

而不是：

$Repository→BusinessLogicRepository \rightarrow BusinessLogic$

237.12 Model内部五类关系

虽然 Model 工程主要包含四类核心对象：

$DomainObject+Service+Engine+RepositoryDomainObject+ Service+ Engine+ Repository$

但在实际运行中还存在 Model 与 Controller 的入口关系，以及 Model 与 View 的输出关系。

完整关系：

$Controller→ServiceController \rightarrow Service$ $Service→DomainObjectService \rightarrow DomainObject$ $Service→EngineService \rightarrow Engine$ $Engine→DomainObjectEngine \rightarrow DomainObject$ $DomainObject→RepositoryDomainObject \rightarrow Repository$ $Repository→MySQLRepository \rightarrow MySQL$

最终：

$Model→Result→Controller→ViewModel \rightarrow Result \rightarrow Controller \rightarrow View$

237.13 Model关系总图

ICAI Model 可以统一表示为：

                  Controller
                       │
                       ↓
                    Service
                   ↙       ↘
                  ↓         ↓
          Domain Object    Engine
                  │         │
                  └────┬────┘
                       ↓
                  Repository
                       ↓
                    MySQL

其中：

$Controller→ServiceController\rightarrow Service$

表示请求进入业务流程。

$Service→DomainObjectService\rightarrow DomainObject$

表示业务流程操作领域对象。

$Service→EngineService\rightarrow Engine$

表示业务流程调用领域计算。

$Engine→DomainObjectEngine\rightarrow DomainObject$

表示计算围绕领域对象进行。

$DomainObject→RepositoryDomainObject\rightarrow Repository$

表示对象需要持久化。

$Repository→MySQLRepository\rightarrow MySQL$

表示最终进入数据库。

237.14 Service与Engine关系

Service 和 Engine 的关系是 ICAI Model 中非常重要的一组关系。

Service：

$Service=ProcessService=Process$

Engine：

$Engine=CalculationEngine=Calculation$

因此：

$Service→EngineService \rightarrow Engine$

例如：

CapabilityService
↓
CapabilityEngine

Service 可以组织：

读取目标
↓
读取能力
↓
调用能力匹配
↓
调用状态检查
↓
调用条件检查
↓
保存结果

Engine 分别负责：

$CapabilityMatchingCapabilityMatching$ $StateCheckingStateChecking$ $ConditionCheckingConditionChecking$

因此：

$Service≠EngineService\neq Engine$

而是：

$Service=组织Service=组织$ $Engine=计算Engine=计算$

237.15 Service与Repository关系

Service 可以通过 Repository 获取和保存 Domain Object。

$Service→RepositoryService \rightarrow Repository$

例如：

class IndividualService
{
    protected $repository;

    public function find($id)
    {
        return $this->repository->find($id);
    }
}

更完整的过程：

$Request→Service→Repository→DomainObjectRequest \rightarrow Service \rightarrow Repository \rightarrow DomainObject$

修改：

$DomainObject→Service→Repository→MySQLDomainObject \rightarrow Service \rightarrow Repository \rightarrow MySQL$

因此 Service 可以同时协调：

$EngineEngine$

和：

$RepositoryRepository$

形成：

$Service→EngineService \rightarrow Engine$

以及：

$Service→RepositoryService \rightarrow Repository$

237.16 Domain Object与Repository关系

Domain Object 是业务对象，Repository 是持久化边界。

$DomainObject↔RepositoryDomainObject \leftrightarrow Repository$

读取：

$Repository→DomainObjectRepository \rightarrow DomainObject$

保存：

$DomainObject→RepositoryDomainObject \rightarrow Repository$

更新：

$DomainObjectt→Repository→DomainObjectt+1DomainObject_t \rightarrow Repository \rightarrow DomainObject_{t+1}$

这种关系可以避免 Domain Object 直接依赖数据库实现。

因此：

$DomainObject≢MySQLDomainObject\not\equiv MySQL$

而是：

$DomainObject→Repository→PersistenceDomainObject \rightarrow Repository \rightarrow Persistence$

237.17 Engine与Repository关系

Engine 通常不应该直接承担数据库持久化职责。

不推荐：

$Engine→MySQLEngine \rightarrow MySQL$

更合理：

$Service→EngineService \rightarrow Engine$

计算完成：

$Engine→ResultEngine \rightarrow Result$

然后：

$Service→Repository→MySQLService \rightarrow Repository \rightarrow MySQL$

例如：

CapabilityService
↓
CapabilityEngine
↓
CapabilityMatchResult
↓
CapabilityRepository
↓
MySQL

这样可以保持：

$Calculation≠PersistenceCalculation \neq Persistence$

237.18 Model关系中的依赖方向

ICAI Model 工程需要明确依赖方向。

237.19 Model与Domain Object组合

一个 ICAI Model 通常不是一个 Domain Object，而是由多个 Domain Object 组成。

例如机器个体：

MachineIndividual
│
├── CognitiveObject
├── CognitiveState
├── CognitiveRelation
├── CognitiveKnowledge
├── CognitiveNeed
├── CognitiveGoal
├── CognitiveCapability
├── CognitiveMethod
├── CognitiveDecision
├── CognitiveBehavior
├── CognitiveAction
├── CognitiveResult
├── CognitiveFeedback
├── MachineMemory
└── MachineMaintenance

因此：

$MachineIndividual=Composition(DomainObjects)MachineIndividual = Composition(DomainObjects)$

Service 再围绕这些对象组织业务流程：

$MachineIndividualService→DomainObjectsMachineIndividualService \rightarrow DomainObjects$

Engine 执行这些对象上的计算：

$CognitiveEngine→CognitiveObjectsCognitiveEngine \rightarrow CognitiveObjects$

Repository 对这些对象进行持久化：

$Repository→MySQLRepository \rightarrow MySQL$

237.20 Model目录结构

在 PHP OOP 工程中，可以将 Model 工程明确组织为：

app/
├── controllers/
│
├── services/
│
├── engines/
│
├── domain/
│   ├── individual/
│   ├── cognitive/
│   ├── behavior/
│   ├── memory/
│   └── maintenance/
│
├── repositories/
│
└── models/

其中：

controllers/

负责 Controller。

services/

负责 Service。

engines/

负责 Engine。

domain/

负责 Domain Object。

repositories/

负责 Repository。

models/ 可以用于放置更高层的 Model 组合对象、数据映射对象或特定 MVC Model，而不能把所有职责重新堆进一个 Model 类。

237.21 Model不是“大Model类”

ICAI 工程中不应该建立一个包含所有功能的：

class Model
{
    // 所有功能全部放这里
}

因为这种设计会导致：

$Model=Object+Service+Engine+Repository+Database+BusinessLogicModel= Object+ Service+ Engine+ Repository+ Database+ BusinessLogic$

最终形成巨型类。

这种结构会造成：

职责混乱；
代码难以维护；
业务计算与数据库操作混合；
Domain Object 无法独立；
Engine 无法复用；
Service 无法清晰组织。

正确方式是：

$Model=Composition(DomainObject,Service,Engine,Repository)Model = Composition( DomainObject, Service, Engine, Repository )$

即：

Model 是工程结构，不是一个巨型类。

237.22 Model与理论模型

ICAI 的理论模型必须能够进入 Model 工程。

第157章建立：

$Theory→MathematicalModel→LogicalModel→DataObject→DomainObjectTheory \rightarrow MathematicalModel \rightarrow LogicalModel \rightarrow DataObject \rightarrow DomainObject$

现在进一步形成：

$DomainObject→Service→Engine→RepositoryDomainObject \rightarrow Service \rightarrow Engine \rightarrow Repository$

因此完整工程转换：

$ICAI理论→数学模型→逻辑模型→数据结构→DomainObject→Service→Engine→Repository→MySQL\boxed{ ICAI理论 \rightarrow 数学模型 \rightarrow 逻辑模型 \rightarrow 数据结构 \rightarrow DomainObject \rightarrow Service \rightarrow Engine \rightarrow Repository \rightarrow MySQL }$

这意味着理论中的对象、关系、状态、能力、方法、决策、行为等概念，都必须能够找到对应的工程实现位置。

237.23 ICAI认知Model示例

以认知处理为例。

理论：

$Object→Attribute→State→Relation→Scene→KnowledgeObject \rightarrow Attribute \rightarrow State \rightarrow Relation \rightarrow Scene \rightarrow Knowledge$

Domain Object：

CognitiveObject
CognitiveAttribute
CognitiveState
CognitiveRelation
CognitiveScene
CognitiveKnowledge

Engine：

CognitiveEngine
ObjectEngine
StateEngine
RelationEngine
KnowledgeEngine

Service：

CognitiveService

Repository：

CognitiveObjectRepository
CognitiveStateRepository
CognitiveKnowledgeRepository

最终：

$CognitiveRequest→CognitiveController→CognitiveService→CognitiveEngine→CognitiveDomainObject→CognitiveRepository→MySQLCognitiveRequest \rightarrow CognitiveController \rightarrow CognitiveService \rightarrow CognitiveEngine \rightarrow CognitiveDomainObject \rightarrow CognitiveRepository \rightarrow MySQL$

237.24 ICAI决策Model示例

决策理论：

$Goal→Capability→Method→DecisionGoal \rightarrow Capability \rightarrow Method \rightarrow Decision$

Domain Object：

CognitiveGoal
CognitiveCapability
CognitiveMethod
CognitiveDecision

Engine：

GoalEngine
CapabilityEngine
MethodEngine
DecisionEngine

Service：

DecisionService

Repository：

GoalRepository
CapabilityRepository
MethodRepository
DecisionRepository

完整流程：

$DecisionRequest→DecisionController→DecisionServiceDecisionRequest \rightarrow DecisionController \rightarrow DecisionService$

然后：

$DecisionService→GoalEngine→CapabilityEngine→MethodEngine→DecisionEngineDecisionService \rightarrow GoalEngine \rightarrow CapabilityEngine \rightarrow MethodEngine \rightarrow DecisionEngine$

最终：

$DecisionResult→DecisionRepository→MySQLDecisionResult \rightarrow DecisionRepository \rightarrow MySQL$

237.25 ICAI行为Model示例

行为理论：

$Decision→Behavior→Action→Result→FeedbackDecision \rightarrow Behavior \rightarrow Action \rightarrow Result \rightarrow Feedback$

Domain Object：

CognitiveDecision
CognitiveBehavior
CognitiveAction
CognitiveResult
CognitiveFeedback

Engine：

DecisionEngine
BehaviorEngine
ActionExecutionEngine
BehaviorResultEngine
BehaviorFeedbackEngine

Service：

BehaviorService

Repository：

DecisionRepository
BehaviorRepository
ActionRepository
ResultRepository
FeedbackRepository

完整结构：

$BehaviorRequest→BehaviorController→BehaviorServiceBehaviorRequest \rightarrow BehaviorController \rightarrow BehaviorService$

然后：

$BehaviorService→BehaviorEngine→ActionEngine→ResultEngine→FeedbackEngineBehaviorService \rightarrow BehaviorEngine \rightarrow ActionEngine \rightarrow ResultEngine \rightarrow FeedbackEngine$

最终：

$Feedback→Repository→MySQLFeedback \rightarrow Repository \rightarrow MySQL$

237.26 Model与对象生命周期

第159章建立了 ICAI 对象生命周期：

现在 Model 工程必须承载这一生命周期。

因此：

$Service→LifecycleEngine→DomainObjectService \rightarrow LifecycleEngine \rightarrow DomainObject$

Repository 负责：

$LoadLoad$ $SaveSave$ $UpdateUpdate$

因此：

$ObjectLifecycle=Service+Engine+RepositoryObjectLifecycle = Service+ Engine+ Repository$

例如：

IndividualService
↓
ObjectLifecycleEngine
↓
MachineIndividual
↓
MachineIndividualRepository
↓
MySQL

237.27 Model运行过程

一个完整的 ICAI Model 请求可以表示为：

请求
↓
Controller
↓
Service
↓
读取Domain Object
↓
Repository
↓
MySQL
↓
Domain Object
↓
Engine计算
↓
Domain Object变化
↓
Service组织结果
↓
Repository保存
↓
Controller
↓
Response

形式化：

$Request→Controller→Service→Repository→DomainObject→Engine→DomainObject′→Repository→Result→ControllerRequest \rightarrow Controller \rightarrow Service \rightarrow Repository \rightarrow DomainObject \rightarrow Engine \rightarrow DomainObject’ \rightarrow Repository \rightarrow Result \rightarrow Controller$

这是一个完整的 Model Runtime。

237.28 Model中的数据流

ICAI Model 的数据流可以分为三个方向。

第一：读取

$MySQL→Repository→DomainObjectMySQL \rightarrow Repository \rightarrow DomainObject$

第二：计算

$DomainObject→Engine→ResultDomainObject \rightarrow Engine \rightarrow Result$

第三：保存

$DomainObject′→Repository→MySQLDomainObject’ \rightarrow Repository \rightarrow MySQL$

因此：

$Read→Calculate→Modify→Save\boxed{ Read \rightarrow Calculate \rightarrow Modify \rightarrow Save }$

形成 Model 的基本运行循环。

237.29 Model关系与对象关系模型

第158章的对象关系模型包括：

$AssociationAssociation$ $CompositionComposition$ $InheritanceInheritance$ $DependencyDependency$ $LifecycleLifecycle$

这些关系同样存在于 Model 工程中。

例如：

Service与Engine

$Service→DependencyEngineService \xrightarrow{Dependency} Engine$

Service与Repository

$Service→DependencyRepositoryService \xrightarrow{Dependency} Repository$

MachineIndividual与CognitiveObject

$MachineIndividual→CompositionCognitiveObjectMachineIndividual \xrightarrow{Composition} CognitiveObject$

RobotIndividual与MachineIndividual

$RobotIndividual→InheritanceMachineIndividualRobotIndividual \xrightarrow{Inheritance} MachineIndividual$

Domain Object生命周期

$DomainObject→LifecycleCreate→Run→DestroyDomainObject \xrightarrow{Lifecycle} Create\rightarrow Run\rightarrow Destroy$

因此：

$ObjectRelation→ModelRelationObjectRelation \rightarrow ModelRelation$

237.30 Model工程统一关系

综合本章五项内容：

$DomainObject+Service+Engine+Repository+ModelRelation\boxed{ DomainObject + Service + Engine + Repository + ModelRelation }$

其中：

$DomainObject=领域对象DomainObject=领域对象$ $Service=业务流程Service=业务流程$ $Engine=领域计算Engine=领域计算$ $Repository=持久化Repository=持久化$ $ModelRelation=对象之间的工程依赖与组合ModelRelation=对象之间的工程依赖与组合$

完整关系：

$Controller→Service→Engine→DomainObject→Repository→MySQL\boxed{ Controller \rightarrow Service \rightarrow Engine \rightarrow DomainObject \rightarrow Repository \rightarrow MySQL }$

但在实际工程中 Service 也可以直接协调 Repository：

$Service→RepositoryService \rightarrow Repository$

因此更准确的结构是：

                 Controller
                     ↓
                  Service
                 ↙       ↘
                ↓         ↓
             Engine    Repository
                ↓         ↓
          Domain Object  MySQL
                ↓
           Repository

核心不是固定的单一路径，而是：

$ServiceService$

作为业务流程协调中心，在合法的职责边界内协调：

$EngineEngine$ $DomainObjectDomainObject$ $RepositoryRepository$

237.31 Model工程的核心原则

ICAI Model 工程应遵循以下原则。

第一，对象独立

$DomainObject≠DatabaseRecordDomainObject\neq DatabaseRecord$

第二，业务独立

$Service≠ControllerService\neq Controller$

第三，计算独立

$Engine≠ServiceEngine\neq Service$

第四，持久化独立

$Repository≠EngineRepository\neq Engine$

第五，数据库隔离

$DomainObject≠MySQLDomainObject\neq MySQL$

第六，职责单一

$OneObject→OnePrimaryResponsibilityOneObject\rightarrow OnePrimaryResponsibility$

第七，关系明确

$Object→Relation→RuntimeObject \rightarrow Relation \rightarrow Runtime$

第八，理论与工程对应

$Theory→DomainObject→Service→Engine→RepositoryTheory \rightarrow DomainObject \rightarrow Service \rightarrow Engine \rightarrow Repository$

237.32 本章总结

ICAI 的 Model 工程不能简单理解为“数据库 Model”。

Model 是一个完整的工程结构：

$Model=DomainObject+Service+Engine+Repository\boxed{ Model= DomainObject+ Service+ Engine+ Repository }$

其中：

$DomainObject=表达领域对象DomainObject=表达领域对象$ $Service=组织业务流程Service=组织业务流程$ $Engine=执行领域计算Engine=执行领域计算$ $Repository=负责持久化Repository=负责持久化$

它们之间形成：

$Controller→Service→Engine→DomainObject→Repository→MySQL\boxed{ Controller \rightarrow Service \rightarrow Engine \rightarrow DomainObject \rightarrow Repository \rightarrow MySQL }$

同时：

$Service→RepositoryService \rightarrow Repository$

用于直接组织数据读取和保存。

完整的 ICAI MVC 工程体系因此可以表示为：

$Request→Controller→Model→View\boxed{ Request \rightarrow Controller \rightarrow Model \rightarrow View }$

其中 Model 内部继续展开为：

$Model=DomainObject+Service+Engine+Repository\boxed{ Model = DomainObject+ Service+ Engine+ Repository }$

最终形成完整工程映射：

$ICAI理论→形式化模型→DomainObject→Service→Engine→Repository→MySQL→Runtime\boxed{ ICAI理论 \rightarrow 形式化模型 \rightarrow DomainObject \rightarrow Service \rightarrow Engine \rightarrow Repository \rightarrow MySQL \rightarrow Runtime }$

因此，Model 的本质不是一个“存数据的类”，而是把 ICAI 理论中的对象、状态、关系、计算、业务流程和持久化机制组织成为可运行工程结构的核心部分。

至此，Controller 解决了“请求如何进入系统”，Model 解决了“进入系统以后对象、业务、计算和数据如何协同运行”，二者共同构成 ICAI MVC 工程的基础。

第237章 Model工程

第237章 Model工程

237.1 提出背景

237.2 Model工程定义

237.3 Model与MVC

237.4 Domain Object

237.5 Domain Object与数据记录

237.6 Service

237.7 Service与Domain Object

237.8 Engine

237.9 Engine与Domain Object

237.10 Repository

237.11 Repository与MySQL

237.12 Model内部五类关系

237.13 Model关系总图

237.14 Service与Engine关系

237.15 Service与Repository关系

237.16 Domain Object与Repository关系

237.17 Engine与Repository关系

237.18 Model关系中的依赖方向

237.19 Model与Domain Object组合

237.20 Model目录结构

237.21 Model不是“大Model类”

237.22 Model与理论模型

237.23 ICAI认知Model示例

237.24 ICAI决策Model示例

237.25 ICAI行为Model示例

237.26 Model与对象生命周期

237.27 Model运行过程

237.28 Model中的数据流

第一：读取

第二：计算

第三：保存

237.29 Model关系与对象关系模型

Service与Engine

Service与Repository

MachineIndividual与CognitiveObject

RobotIndividual与MachineIndividual

Domain Object生命周期

237.30 Model工程统一关系

237.31 Model工程的核心原则

第一，对象独立

第二，业务独立

第三，计算独立

第四，持久化独立

第五，数据库隔离

第六，职责单一

第七，关系明确

第八，理论与工程对应

237.32 本章总结