第241章　Engine→Domain Object

241.1 提出背景

第240章建立了：

$Service→EngineService\rightarrow Engine$

Service 负责组织业务流程，Engine 负责执行领域计算。

但是 Engine 计算完成以后，计算结果并不会停留在 Engine 内部。

ICAI 是一个以“机器个体”为运行对象的系统。

因此，Engine 的计算最终必须作用于具体的 Domain Object，使对象的属性、状态、关系、能力、行为或其他领域数据发生变化。

于是形成：

$Engine→DomainObject\boxed{ Engine\rightarrow DomainObject }$

其基本过程为：

$InputObject→Engine→ObjectCalculation→ObjectModification→StateUpdateInputObject \rightarrow Engine \rightarrow ObjectCalculation \rightarrow ObjectModification \rightarrow StateUpdate$

本章重点研究四个核心过程：

$InputObjectInputObject$ $ObjectCalculationObjectCalculation$ $ObjectModificationObjectModification$ $StateUpdateStateUpdate$

即：

Engine 接收什么对象，如何计算对象，对象哪些内容可以修改，以及修改以后如何形成新的对象状态。

241.2 Engine→Domain Object定义

Engine→Domain Object是指 Engine 接收或使用领域对象作为计算输入，根据领域规则和当前状态执行计算，并将计算结果作用于对应 Domain Object，使对象的属性、关系或状态发生合法变化的工程关系。

基本关系：

$Engine→DomainObject\boxed{ Engine\rightarrow DomainObject }$

完整过程：

$DomainObjectt→Engine→Calculation→Modification→DomainObjectt+1DomainObject_t \rightarrow Engine \rightarrow Calculation \rightarrow Modification \rightarrow DomainObject_{t+1}$

其中：

$DomainObjecttDomainObject_t$ ：计算前的领域对象；
$EngineEngine$ ：领域计算引擎；
$CalculationCalculation$ ：对象计算过程；
$ModificationModification$ ：对象修改；
$DomainObjectt+1DomainObject_{t+1}$ ：计算后的领域对象。

因此：

$DomainObjectt+1=F(DomainObjectt,Input,Rule)\boxed{ DomainObject_{t+1} = F(DomainObject_t,Input,Rule) }$

241.3 输入对象

**输入对象（Input Object）**是 Engine 执行领域计算时使用的 Domain Object。

例如机器个体：

$individual

可能包含：

id
type
name
state
attributes
relations
capabilities
goals
memory

Engine 接收：

$InputObject=IndividualInputObject=Individual$

例如：

$result = $engine->calculate(
    $individual
);

这里：

$Individual→EngineIndividual \rightarrow Engine$

但是 Engine 不应该把 HTTP Request 当作领域对象。

错误：

HTTP Request
↓
Engine

正确：

HTTP Request
↓
Controller
↓
Service
↓
Domain Object
↓
Engine

因此：

$Engine的输入应该是领域数据，而不是原始HTTP请求\boxed{ Engine的输入应该是领域数据，而不是原始HTTP请求 }$

241.4 输入对象与Domain Object

Domain Object 是对现实业务对象或 ICAI 内部领域对象的程序化表示。

例如：

class Individual
{
    protected $id;
    protected $type;
    protected $name;
    protected $state;
}

该对象代表：

$IndividualIndividual$

而不是数据库中的一行记录本身。

因此：

$DomainObject≠DatabaseRecordDomainObject\neq DatabaseRecord$

数据库记录经过 Repository 加载以后，可以形成 Domain Object：

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

然后：

$DomainObject→EngineDomainObject \rightarrow Engine$

形成完整的数据转换过程。

241.5 Engine读取输入对象

Engine 首先需要读取对象当前的数据。

例如：

class StateEngine
{
    public function calculate($individual)
    {
        $state = $individual->getState();

        // 根据当前状态继续计算
    }
}

这里 Engine 读取：

$StatetState_t$

也可以读取：

$AttributetAttribute_t$ $RelationtRelation_t$ $CapabilitytCapability_t$ $GoaltGoal_t$

因此：

$InputObject={Identity,Attribute,State,Relation,…}InputObject= \{Identity,Attribute,State,Relation,\ldots\}$

Engine 根据实际业务选择所需对象信息，而不是无条件读取全部对象数据。

241.6 对象计算

**对象计算（Object Calculation）**是 Engine 根据 Domain Object 当前结构、输入条件和领域规则，对对象进行判断、比较、匹配、转换或状态计算的过程。

基本模型：

$Calculation=F(Object,Input,Rule,Condition)\boxed{ Calculation= F(Object,Input,Rule,Condition) }$

例如状态计算：

$Statenext=F(Statecurrent,Action,Rule)State_{next} = F(State_{current},Action,Rule)$

能力判断：

$CapabilityResult=F(Individual,Need,Condition)CapabilityResult = F(Individual,Need,Condition)$

匹配计算：

$MatchResult=F(ObjectA,ObjectB,Relation,Rule)MatchResult = F(Object_A,Object_B,Relation,Rule)$

决策计算：

$DecisionResult=F(Goal,Capability,Method,Risk)DecisionResult = F(Goal,Capability,Method,Risk)$

241.7 对象计算不是对象修改

必须区分：

$ObjectCalculationObjectCalculation$

和：

$ObjectModificationObjectModification$

Engine 可以先计算，再决定是否修改对象。

例如：

Individual
state = idle
↓
Engine计算
↓
发现可以启动
↓
CalculationResult = allowed

此时只是获得：

$CalculationResult=AllowedCalculationResult=Allowed$

对象仍然可能保持：

$state=idlestate=idle$

只有经过业务规则确认以后，才执行：

$idle→runningidle\rightarrow running$

因此：

$Calculation≠Modification\boxed{ Calculation\neq Modification }$

241.8 对象计算输入

一个完整对象计算可以表示为：

$Input={Object,Attributes,State,Relations,Condition,Rules}Input= \{ Object, Attributes, State, Relations, Condition, Rules \}$

例如：

对象：Individual#15
状态：idle
动作：start
条件：system_ready
规则：idle允许start

Engine：

$F(Individual,State,Action,Condition,Rule)F( Individual, State, Action, Condition, Rule )$

输出：

allowed
next_state = running

即：

$EngineInput→EngineCalculation→EngineResultEngineInput \rightarrow EngineCalculation \rightarrow EngineResult$

241.9 对象计算结果

Engine 可以返回对象计算结果：

$ObjectResult={Status,Value,NextState,Changed,Reason}ObjectResult= \{ Status, Value, NextState, Changed, Reason \}$

例如：

return array(
    'status' => 'success',
    'value' => true,
    'next_state' => 'running',
    'changed' => true,
    'reason' => 'start_allowed'
);

其中：

$Status=successStatus=success$

表示计算成功。

$Value=trueValue=true$

表示计算结果为允许。

$NextState=runningNextState=running$

表示计算得到的目标状态。

$Changed=trueChanged=true$

表示预计产生对象变化。

241.10 对象修改

**对象修改（Object Modification）**是指 Engine 计算完成后，根据计算结果对 Domain Object 的属性、状态、关系或其他可变领域数据进行合法更新。

基本关系：

$CalculationResult→ObjectModification\boxed{ CalculationResult \rightarrow ObjectModification }$

例如：

$individual->setState('running');

表示：

$Statebefore=idleState_{before}=idle$

变为：

$Stateafter=runningState_{after}=running$

因此：

$ObjectModification:idle→runningObjectModification: idle\rightarrow running$

241.11 对象修改必须遵循领域规则

Engine 不能因为能够调用：

setState()

就任意修改 Domain Object。

对象修改必须满足：

$ModificationCondition=TrueModificationCondition=True$

例如：

$CurrentState=idleCurrentState=idle$

且：

$Action=startAction=start$

并且：

$StartAllowed=TrueStartAllowed=True$

才允许：

$State=runningState=running$

因此：

$Modify(Object) ⟺ RuleSatisfied\boxed{ Modify(Object) \iff RuleSatisfied }$

对象修改不是普通的数据覆盖，而是领域状态变化。

241.12 Domain Object提供修改接口

Domain Object 应该通过明确的方法修改自己的数据。

例如：

class Individual
{
    protected $state;

    public function getState()
    {
        return $this->state;
    }

    public function setState($state)
    {
        $this->state = $state;
    }
}

Engine：

$individual->setState(
    $result['next_state']
);

这样可以避免 Engine 直接操作对象内部结构。

不推荐：

$individual->state = 'running';

241.13 Engine修改对象的边界

Engine 可以修改 Domain Object，但必须明确修改范围。

例如 StateEngine 负责：

state

而不应该同时负责：

knowledge
memory
repository
view
html

因此：

$StateEngine→StateStateEngine \rightarrow State$ $MemoryEngine→MemoryMemoryEngine \rightarrow Memory$ $KnowledgeEngine→KnowledgeKnowledgeEngine \rightarrow Knowledge$ $BehaviorEngine→BehaviorBehaviorEngine \rightarrow Behavior$

每一个 Engine 应该围绕自己的领域责任工作。

241.14 状态更新

**状态更新（State Update）**是对象修改完成以后，将对象从当前状态转换为新的合法状态。

基本关系：

$Statet→Statet+1\boxed{ State_t \rightarrow State_{t+1} }$

例如：

idle
↓
running

数学表示：

$Statet+1=F(Statet,Input,Rule)State_{t+1} = F(State_t,Input,Rule)$

例如：

$Statet=idleState_t=idle$ $Input=startInput=start$ $Rule:idle+start→runningRule: idle+start\rightarrow running$

因此：

$Statet+1=runningState_{t+1}=running$

241.15 状态更新与属性更新

对象更新并不一定都是状态更新。

例如：

name
type
description

属于对象属性。

而：

idle
running
blocked
completed

属于状态。

因此：

$AttributeUpdate≠StateUpdateAttributeUpdate\neq StateUpdate$

例如：

$individual->setName('Robot A');

属于：

$AttributeUpdateAttributeUpdate$

而：

$individual->setState('running');

属于：

$StateUpdateStateUpdate$

二者都可以属于 Object Modification，但概念不能混淆。

241.16 状态更新与状态机

ICAI 的对象状态可以采用状态转换模型。

例如：

created
   ↓
initialized
   ↓
idle
   ↓
running
   ↓
completed
   ↓
archived

可以表示为：

$Si→EventSjS_i\xrightarrow{Event}S_j$

例如：

$idle→startrunningidle\xrightarrow{start}running$ $running→completecompletedrunning\xrightarrow{complete}completed$

如果转换条件不满足：

$idle→invalidblockedidle\xrightarrow{invalid}blocked$

因此 Engine 可以负责计算：

$CurrentState+Event→NextStateCurrentState+Event \rightarrow NextState$

241.17 状态更新前后比较

状态更新以后应该能够比较前后状态。

定义：

$StateChange=Compare(Statebefore,Stateafter)StateChange= Compare(State_{before},State_{after})$

例如：

$idle≠runningidle\neq running$

所以：

$StateChange=TrueStateChange=True$

如果：

$running=runningrunning=running$

则：

$StateChange=FalseStateChange=False$

代码：

$before = $individual->getState();

$individual->setState(
    $result['next_state']
);

$after = $individual->getState();

$changed = ($before !== $after);

这样可以明确判断 Engine 是否真正改变了对象状态。

241.18 Engine→Domain Object完整过程

可以建立：

Engine Input
↓
读取Domain Object
↓
读取对象属性
↓
读取当前状态
↓
读取关系
↓
读取条件
↓
执行领域计算
↓
产生EngineResult
↓
判断是否允许修改
↓
修改Domain Object
↓
更新状态
↓
比较前后状态
↓
返回结果

数学模型：

$DOt→Engine→Result→DOt+1\boxed{ DO_t \rightarrow Engine \rightarrow Result \rightarrow DO_{t+1} }$

其中：

$DOtDO_t$

是计算前 Domain Object。

$DOt+1DO_{t+1}$

是计算后的 Domain Object。

241.19 Engine修改Domain Object的两种模式

Engine 对 Domain Object 的处理可以存在两种基本模式。

第一种：计算后由Service修改

Engine
↓
Result
↓
Service
↓
Domain Object

这种方式中 Engine 主要负责计算。

即：

$Engine=PureCalculationEngine=PureCalculation$

适合需要严格控制业务流程的场景。

第二种：Engine直接修改领域对象

Engine
↓
Domain Object
↓
State Update

这种方式适合 Engine 本身就是某一领域状态处理单元的情况。

例如：

StateEngine
↓
Individual
↓
State Update

但即使 Engine 可以直接修改对象，也必须遵循明确的领域规则。

因此两种模式都可以存在：

$Engine→Result→ObjectEngine\rightarrow Result\rightarrow Object$

或者：

$Engine→ObjectEngine\rightarrow Object$

具体采用哪一种，应根据领域职责确定。

241.20 Engine直接修改对象的条件

如果 Engine 直接修改 Domain Object，需要满足几个条件：

第一，Engine拥有明确领域责任

例如：

$StateEngine→StateStateEngine \rightarrow State$

第二，修改行为属于该领域

例如 StateEngine 修改状态，而不是修改 HTML。

第三，修改必须满足规则

$RuleSatisfied=TrueRuleSatisfied=True$

第四，修改过程可以被记录

$Before→AfterBefore \rightarrow After$

第五，修改后的对象能够继续被 Service 使用

$ModifiedObject→ServiceModifiedObject \rightarrow Service$

241.21 Engine与对象方法

Domain Object 自身可以提供领域方法。

例如：

class Individual
{
    protected $state;

    public function canStart()
    {
        return $this->state === 'idle';
    }

    public function start()
    {
        if (!$this->canStart()) {
            return false;
        }

        $this->state = 'running';

        return true;
    }
}

Engine：

class StateEngine
{
    public function start(
        Individual $individual
    ) {
        if (!$individual->canStart()) {
            return array(
                'status' => 'blocked'
            );
        }

        $changed =
            $individual->start();

        return array(
            'status' => 'success',
            'changed' => $changed,
            'state' => $individual->getState()
        );
    }
}

这里形成：

$Engine→DomainMethod→StateEngine \rightarrow DomainMethod \rightarrow State$

Engine 负责领域流程计算，而 Domain Object 保持自身状态规则的一部分。

241.22 Engine与对象不变条件

Domain Object 可能存在一些不能随意破坏的不变条件。

例如：

$ID>0ID>0$ $Type≠∅Type\neq\varnothing$ $State∈ValidStatesState\in ValidStates$

如果：

$State∉ValidStatesState\notin ValidStates$

则对象处于非法状态。

因此对象修改必须满足：

$Invariant(Object)=TrueInvariant(Object)=True$

更新过程：

$Objectt→ModifyObjectt+1Object_t \xrightarrow{Modify} Object_{t+1}$

必须保证：

$Invariant(Objectt+1)=TrueInvariant(Object_{t+1})=True$

这意味着 Engine 不是简单地“改变一个字段”，而是必须保证修改后的 Domain Object 仍然是合法对象。

241.23 对象计算与对象生命周期

Engine 对象的计算可能发生在 Domain Object 生命周期中的不同阶段。

例如：

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

Engine 主要参与：

$RunRun$

以及：

$ModifyModify$

和：

$UpdateUpdate$

例如：

Load
↓
Domain Object
↓
Engine
↓
Calculate
↓
Modify
↓
Update
↓
Save

因此第159章的对象生命周期与本章 Engine→Domain Object 形成直接联系。

241.24 Engine与状态历史

状态发生变化以后，需要保留变化历史。

定义：

$StateHistory={Object,Before,After,Reason,Time}StateHistory= \{Object,Before,After,Reason,Time\}$

例如：

individual_id = 15
before = idle
after = running
reason = start
time = 2026-09-05 18:20:00

形成：

$Engine→StateChange→StateHistoryEngine \rightarrow StateChange \rightarrow StateHistory$

状态历史可以由 Service 或专门的 Repository 保存。

因此：

$DomainObject→StateHistoryRepository→MySQLDomainObject \rightarrow StateHistoryRepository \rightarrow MySQL$

这样以后可以恢复：

$State0→State1→State2→…State_0 \rightarrow State_1 \rightarrow State_2 \rightarrow …$

241.25 Engine计算与对象记忆

状态变化可以成为 ICAI 的记忆输入。

例如：

$Engine→StateChange→MemoryEngine \rightarrow StateChange \rightarrow Memory$

完整过程：

Domain Object
↓
Engine
↓
状态变化
↓
行为结果
↓
记忆
↓
经验

因此 Engine→Domain Object 不只是一次数据修改，还可能形成：

$CurrentState→NewState→History→ExperienceCurrentState \rightarrow NewState \rightarrow History \rightarrow Experience$

这为 ICAI 后续的经验和学习机制提供数据基础。

241.26 Engine修改对象后的验证

对象修改以后，需要进行结果验证。

基本过程：

$Calculate→Modify→VerifyCalculate \rightarrow Modify \rightarrow Verify$

例如：

$before = $individual->getState();

$individual->setState(
    $result['next_state']
);

$after = $individual->getState();

if (!$this->isValidState($after)) {
    throw new Exception(
        'Invalid state'
    );
}

形成：

$Verify(Stateafter)Verify(State_{after})$

如果验证失败：

$Stateafter→InvalidState_{after} \rightarrow Invalid$

则不能直接保存。

因此：

$修改≠完成\boxed{ 修改\neq完成 }$

必须经过：

$修改→验证→保存修改\rightarrow验证\rightarrow保存$

241.27 Engine与Repository的完整边界

完整工程流程可以表示为：

Service
↓
Repository
↓
Domain Object
↓
Engine
↓
Calculation
↓
Domain Object Modification
↓
State Update
↓
Validation
↓
Repository
↓
MySQL

即：

$Repository→DomainObject→Engine→DomainObject→Repository\boxed{ Repository \rightarrow DomainObject \rightarrow Engine \rightarrow DomainObject \rightarrow Repository }$

这是 ICAI 中非常重要的一条对象运行链。

Repository 负责：

对象如何进入系统以及如何保存。

Engine 负责：

对象进入以后如何计算。

Domain Object 负责：

对象本身的数据和领域状态。

241.28 Service→Engine→Domain Object

第239、240、241章可以连接起来：

第239章：

$Controller→ServiceController\rightarrow Service$

第240章：

$Service→EngineService\rightarrow Engine$

第241章：

$Engine→DomainObjectEngine\rightarrow DomainObject$

因此形成：

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

再返回：

$DomainObject→EngineResult→Service→Controller\boxed{ DomainObject \rightarrow EngineResult \rightarrow Service \rightarrow Controller }$

如果对象发生变化：

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

241.29 ICAI机器个体中的对象计算

ICAI 的机器个体本身可以看作一个复杂 Domain Object。

例如：

$Individual={ID,Type,Attribute,State,Relation,Knowledge,Goal,Capability,Memory}Individual= \{ ID, Type, Attribute, State, Relation, Knowledge, Goal, Capability, Memory \}$

Engine 可以针对其中不同部分进行计算。

例如：

$CognitiveEngine→CognitiveStateCognitiveEngine \rightarrow CognitiveState$ $CapabilityEngine→CapabilityStateCapabilityEngine \rightarrow CapabilityState$ $DecisionEngine→DecisionStateDecisionEngine \rightarrow DecisionState$ $BehaviorEngine→BehaviorStateBehaviorEngine \rightarrow BehaviorState$ $MemoryEngine→MemoryStateMemoryEngine \rightarrow MemoryState$

因此：

$MachineIndividual→EngineMachineIndividual′MachineIndividual \xrightarrow{Engine} MachineIndividual’$

其中：

$MachineIndividual′≠MachineIndividualMachineIndividual’\neq MachineIndividual$

或者：

$MachineIndividual'=MachineIndividualMachineIndividual’=MachineIndividual$

取决于本次计算是否产生实际变化。

241.30 对象更新模型

可以建立统一对象更新公式：

$Ot+1=Update(Ot,R,I,C)\boxed{ O_{t+1} = Update(O_t,R,I,C) }$

其中：

$OtO_t$ ：当前对象；
$RR$ ：领域规则；
$II$ ：输入条件；
$CC$ ：计算结果；
$Ot+1O_{t+1}$ ：更新后的对象。

进一步：

$C=Engine(Ot,I,R)C=Engine(O_t,I,R)$

所以：

$Ot+1=Update(Ot,Engine(Ot,I,R))\boxed{ O_{t+1} = Update( O_t, Engine(O_t,I,R) ) }$

这就是 Engine→Domain Object 的核心数学模型。

241.31 对象修改的完整工程模型

最终形成：

Business Request
↓
Service
↓
Load Domain Object
↓
Engine Input
↓
Engine Calculation
↓
Calculation Result
↓
Object Modification
↓
State Update
↓
Object Validation
↓
State History
↓
Repository
↓
MySQL

数学表示：

$BR→S→DOt→E→Result→DOt+1→Verify→Repository\boxed{ BR \rightarrow S \rightarrow DO_t \rightarrow E \rightarrow Result \rightarrow DO_{t+1} \rightarrow Verify \rightarrow Repository }$

其中：

$BR=BusinessRequestBR=BusinessRequest$ $S=ServiceS=Service$ $DO=DomainObjectDO=DomainObject$ $E=EngineE=Engine$

241.32 本章核心边界

通过本章，可以明确五个对象之间的职责：

$Service=业务流程\boxed{ Service=业务流程 }$ $Engine=领域计算\boxed{ Engine=领域计算 }$ $DomainObject=领域对象\boxed{ DomainObject=领域对象 }$ $State=对象当前状态\boxed{ State=对象当前状态 }$ $Repository=持久化\boxed{ Repository=持久化 }$

因此不能将这些概念混为一体。

尤其需要保持：

$Engine≠DomainObjectEngine\neq DomainObject$ $Calculation≠ModificationCalculation\neq Modification$ $Modification≠PersistenceModification\neq Persistence$ $EngineResult≠StateEngineResult\neq State$ $StateChange≠EngineSuccessStateChange\neq EngineSuccess$

241.33 Engine→Domain Object完整关系

最终建立：

$InputObject→Engine→ObjectCalculation→EngineResult→ObjectModification→StateUpdate\boxed{ InputObject \rightarrow Engine \rightarrow ObjectCalculation \rightarrow EngineResult \rightarrow ObjectModification \rightarrow StateUpdate }$

如果修改有效：

$StateUpdate→Validation→RepositoryStateUpdate \rightarrow Validation \rightarrow Repository$

如果修改无效：

$StateUpdate→ValidationFailed→Rollback/RejectStateUpdate \rightarrow ValidationFailed \rightarrow Rollback/Reject$

因此：

$Engine→Calculation→Object→State\boxed{ Engine \rightarrow Calculation \rightarrow Object \rightarrow State }$

构成 ICAI 对象运行的核心计算链。

241.34 本章总结

Engine→Domain Object 是 ICAI 工程体系中从“计算”进入“对象变化”的核心关系。

Engine 首先获得领域对象：

$DomainObjectt→EngineDomainObject_t \rightarrow Engine$

然后根据对象、输入、规则和条件进行计算：

$Result=F(Object,Input,Rule,Condition)\boxed{ Result= F(Object,Input,Rule,Condition) }$

计算结果产生以后，并不意味着对象已经发生变化。

必须经过：

$Calculation→ModificationCalculation \rightarrow Modification$

然后：

$Modification→StateUpdateModification \rightarrow StateUpdate$

最终形成：

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

如果状态发生变化：

$Statet≠Statet+1\boxed{ State_t\neq State_{t+1} }$

则形成：

$StateChange=TrueStateChange=True$

随后经过验证并由 Repository 保存：

$DomainObjectt+1→Validation→Repository→MySQL\boxed{ DomainObject_{t+1} \rightarrow Validation \rightarrow Repository \rightarrow MySQL }$

因此，本章建立四个核心过程：

$输入对象→对象计算→对象修改→状态更新\boxed{ 输入对象 \rightarrow 对象计算 \rightarrow 对象修改 \rightarrow 状态更新 }$

进一步形成 ICAI 的对象计算闭环：

$Service→Engine→DomainObject→State→Repository\boxed{ Service \rightarrow Engine \rightarrow DomainObject \rightarrow State \rightarrow Repository }$

这使第239章的：

$Controller→ServiceController\rightarrow Service$

与第240章的：

$Service→EngineService\rightarrow Engine$

以及本章的：

$Engine→DomainObjectEngine\rightarrow DomainObject$

正式连接起来，形成：

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

同时形成 ICAI 机器个体内部最基本的状态变化模型：

$Objectt→EngineObjectt+1\boxed{ Object_t \xrightarrow{Engine} Object_{t+1} }$

这意味着 Engine 不再只是一个独立的计算程序，而是 ICAI 机器个体发生对象变化、状态变化和持续运行的重要执行机制。

第241章 Engine→Domain Object

第241章 Engine→Domain Object

241.1 提出背景

241.2 Engine→Domain Object定义

241.3 输入对象

241.4 输入对象与Domain Object

241.5 Engine读取输入对象

241.6 对象计算

241.7 对象计算不是对象修改

241.8 对象计算输入

241.9 对象计算结果

241.10 对象修改

241.11 对象修改必须遵循领域规则

241.12 Domain Object提供修改接口

241.13 Engine修改对象的边界

241.14 状态更新

241.15 状态更新与属性更新

241.16 状态更新与状态机

241.17 状态更新前后比较

241.18 Engine→Domain Object完整过程

241.19 Engine修改Domain Object的两种模式

第一种：计算后由Service修改

第二种：Engine直接修改领域对象

241.20 Engine直接修改对象的条件

第一，Engine拥有明确领域责任

第二，修改行为属于该领域

第三，修改必须满足规则

第四，修改过程可以被记录

第五，修改后的对象能够继续被 Service 使用

241.21 Engine与对象方法

241.22 Engine与对象不变条件

241.23 对象计算与对象生命周期

241.24 Engine与状态历史

241.25 Engine计算与对象记忆

241.26 Engine修改对象后的验证

241.27 Engine与Repository的完整边界

241.28 Service→Engine→Domain Object

241.29 ICAI机器个体中的对象计算

241.30 对象更新模型

241.31 对象修改的完整工程模型

241.32 本章核心边界

241.33 Engine→Domain Object完整关系

241.34 本章总结