第240章　Service→Engine

240.1 提出背景

第239章建立了：

$Controller→ServiceController\rightarrow Service$

Controller 接收外部请求，经过参数处理以后，将业务请求交给 Service。

但是 Service 本身并不是所有计算过程的最终执行位置。

在 ICAI 系统中，一个业务请求进入 Service 后，通常还需要经过领域计算、状态判断、规则处理、对象操作等过程。

因此进一步形成：

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

其中：

$Controller=请求入口Controller=请求入口$ $Service=业务流程组织Service=业务流程组织$ $Engine=领域计算执行Engine=领域计算执行$

Service 与 Engine 的关系，是 ICAI 从 MVC 请求层进入智能计算层的重要工程连接。

本章重点研究四个问题：

$BusinessRequestBusinessRequest$ $EngineCalculationEngineCalculation$ $EngineResultEngineResult$ $StateChangeStateChange$

即：

业务请求如何进入 Engine，Engine 如何完成计算，计算产生什么结果，以及结果如何改变机器个体的状态。

240.2 Service→Engine定义

Service→Engine是指 Service 根据业务请求组织业务流程，并将需要进行领域计算、规则判断、状态处理或对象处理的任务交给对应 Engine 执行的工程关系。

基本结构：

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

完整过程：

$BusinessRequest→Service→Engine→Calculation→EngineResult→ServiceBusinessRequest \rightarrow Service \rightarrow Engine \rightarrow Calculation \rightarrow EngineResult \rightarrow Service$

如果 Engine 的计算结果需要改变个体状态，则继续：

$EngineResult→StateChangeEngineResult \rightarrow StateChange$

最终：

$Service→Engine→Result→State\boxed{ Service \rightarrow Engine \rightarrow Result \rightarrow State }$

因此：

$Service≠EngineService\neq Engine$

Service 负责：

组织一次业务过程。

Engine 负责：

执行某一类确定的领域计算或处理。

240.3 业务请求

**Business Request（业务请求）**是已经通过 Controller 输入层处理，并进入 Service 的业务操作要求。

例如：

创建机器个体
查询机器个体状态
判断能力是否可用
执行目标匹配
执行决策计算
更新机器个体状态
记录行为结果

这些请求已经不是单纯的 HTTP 参数。

例如：

POST /individual/decision

经过 Controller：

$HTTPRequest→ParameterHTTPRequest \rightarrow Parameter$

再经过 Service：

$Parameter→BusinessRequestParameter \rightarrow BusinessRequest$

形成：

$HTTPRequest→Controller→Service→BusinessRequest\boxed{ HTTPRequest \rightarrow Controller \rightarrow Service \rightarrow BusinessRequest }$

业务请求可以表示为：

$BR={Subject,Object,Operation,Condition,Data}BR= \{Subject,Object,Operation,Condition,Data\}$

其中：

$SubjectSubject$ ：业务主体；
$ObjectObject$ ：业务对象；
$OperationOperation$ ：要求执行的操作；
$ConditionCondition$ ：执行条件；
$DataData$ ：业务数据。

例如：

$BR={Individual15,Goal8,Match,Condition,Data}BR= \{ Individual_{15}, Goal_{8}, Match, Condition, Data \}$

表示机器个体15需要对目标8进行匹配计算。

240.4 Service为什么调用Engine

Service 可以完成业务流程组织，但复杂领域计算不应该全部堆积在 Service 中。

例如一个决策业务：

DecisionService
↓
读取目标
↓
读取能力
↓
读取方法
↓
读取风险
↓
进行匹配
↓
计算决策
↓
更新状态

如果全部写进 Service：

class DecisionService
{
    public function decide($request)
    {
        // 获取目标
        // 获取能力
        // 获取方法
        // 获取风险
        // 计算匹配
        // 计算决策
        // 修改状态
    }
}

Service 会逐渐成为一个巨大的业务类。

因此将具体领域计算分离：

DecisionService
↓
DecisionEngine

形成：

$Service=ProcessService=Process$ $Engine=CalculationEngine=Calculation$

即：

$业务流程由Service组织\boxed{ 业务流程由Service组织 }$ $领域计算由Engine执行\boxed{ 领域计算由Engine执行 }$

240.5 Engine定义

**Engine（引擎）**是 ICAI 中负责执行某一领域计算、判断、转换、处理或状态运算的核心程序对象。

例如：

CognitiveEngine
MatchingEngine
GoalEngine
CapabilityEngine
MethodEngine
DecisionEngine
BehaviorEngine
MemoryEngine
MaintenanceEngine

这些 Engine 并不是独立系统，而是对应 ICAI 理论领域的工程执行单元。

例如：

$Cognition→CognitiveEngineCognition \rightarrow CognitiveEngine$ $Matching→MatchingEngineMatching \rightarrow MatchingEngine$ $Decision→DecisionEngineDecision \rightarrow DecisionEngine$ $Behavior→BehaviorEngineBehavior \rightarrow BehaviorEngine$

因此：

$Theory→EngineTheory \rightarrow Engine$

可以进一步表示为：

$TheoryConcept→LogicalModel→EngineTheoryConcept \rightarrow LogicalModel \rightarrow Engine$

240.6 Service与Engine职责区别

Service 和 Engine 必须保持清晰边界。

对象	核心职责
Controller	接收请求
Service	组织业务流程
Engine	执行领域计算
Domain Object	表示领域对象
Repository	持久化数据

例如目标执行业务：

Controller
↓
GoalService
↓
GoalEngine
↓
GoalObject
↓
Repository

其中：

$GoalServiceGoalService$

负责组织：

读取目标
→
调用目标计算
→
判断结果
→
保存结果

而：

$GoalEngineGoalEngine$

负责：

目标条件计算
目标状态判断
目标完成判断

所以：

$Service≠EngineService\neq Engine$

240.7 Service→Engine基本流程

最基本的执行流程：

$BusinessRequest→Service→Engine\boxed{ BusinessRequest \rightarrow Service \rightarrow Engine }$

Engine 执行：

$Engine→CalculationEngine \rightarrow Calculation$

产生：

$Calculation→EngineResultCalculation \rightarrow EngineResult$

然后返回：

$EngineResult→ServiceEngineResult \rightarrow Service$

完整流程：

业务请求
↓
Service
↓
Engine
↓
输入数据
↓
领域计算
↓
计算结果
↓
EngineResult
↓
Service

因此：

$Service→Engine→Result→Service\boxed{ Service \rightarrow Engine \rightarrow Result \rightarrow Service }$

240.8 Engine输入

Engine 不应该直接接收未经整理的 HTTP 请求。

错误结构：

HTTP
↓
Engine

正确结构：

HTTP
↓
Controller
↓
Service
↓
Engine

Engine 接收的应该是业务领域数据。

例如：

$request = array(
    'individual_id' => 15,
    'goal_id' => 8,
    'condition' => 'ready'
);

$result = $this->engine->calculate(
    $request
);

此时 Engine 接收：

$EngineInputEngineInput$

而不是：

$HTTPInputHTTPInput$

因此：

$HTTPInput≠EngineInputHTTPInput \neq EngineInput$

240.9 Engine计算模型

Engine 的基本计算形式可以表示为：

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

其中：

$InputInput$ ：计算输入；
$RuleRule$ ：领域规则；
$StateState$ ：当前对象状态；
$ConditionCondition$ ：计算条件；
$ResultResult$ ：计算结果。

例如能力匹配：

$MatchResult=F(Need,Capability,Condition,State)MatchResult= F( Need, Capability, Condition, State )$

决策：

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

行为：

$BehaviorResult=F(Decision,Object,Condition,Capability)BehaviorResult= F( Decision, Object, Condition, Capability )$

Engine 就是这些理论计算的程序执行位置。

240.10 Engine不是Service的简单改名

Engine 与 Service 虽然都执行代码，但两者职责不同。

Service：

$Service=ProcessService= Process$

Engine：

$Engine=CalculationEngine= Calculation$

例如：

DecisionService

负责：

获取目标
↓
获取能力
↓
获取方法
↓
调用DecisionEngine
↓
处理结果
↓
更新个体

而：

DecisionEngine

负责：

目标
+
能力
+
方法
+
风险
+
条件
↓
决策计算

因此：

$ServiceService$

关注：

业务应该经过哪些步骤。

而：

$EngineEngine$

关注：

某一步具体应该如何计算。

240.11 Engine结果

Engine 执行以后产生 Engine Result。

定义：

$EngineResult=Status+Data+State+Message+CodeEngineResult= Status+ Data+ State+ Message+ Code$

例如：

return array(
    'status' => 'success',
    'code' => 'MATCHED',
    'data' => $matchResult,
    'state' => 'matched',
    'message' => '匹配完成'
);

EngineResult 可以包括：

计算状态
计算数据
目标状态
对象状态
结果代码
错误信息

因此：

$Engine→EngineResultEngine \rightarrow EngineResult$

240.12 Engine结果与Service结果

EngineResult 不一定直接等于最终 ServiceResult。

例如：

$EngineResult→Service→BusinessResultEngineResult \rightarrow Service \rightarrow BusinessResult$

Engine 只负责领域计算。

Service 根据业务流程决定如何使用这个计算结果。

例如：

MatchingEngine
↓
MATCHED
↓
DecisionService
↓
允许进入决策

或者：

MatchingEngine
↓
NOT_MATCHED
↓
DecisionService
↓
结束当前业务

因此：

$EngineResult≠ServiceResultEngineResult \neq ServiceResult$

EngineResult 是领域计算结果。

ServiceResult 是业务流程结果。

240.13 Engine结果状态

Engine 可以定义领域计算状态。

例如：

$EngineStatus∈{Success,Failed,Matched,NotMatched,Allowed,Blocked,Changed,Unchanged}EngineStatus\in \{ Success, Failed, Matched, NotMatched, Allowed, Blocked, Changed, Unchanged \}$

例如匹配：

$MatchedMatched$

表示计算获得匹配结果。

$NotMatchedNotMatched$

表示没有形成匹配。

状态判断：

$Statebefore→Engine→StateafterState_{before} \rightarrow Engine \rightarrow State_{after}$

如果计算没有产生状态变化：

$Stateafter=StatebeforeState_{after}=State_{before}$

如果计算产生变化：

$Stateafter≠StatebeforeState_{after}\neq State_{before}$

240.14 Engine与Domain Object

Engine 通常需要操作 Domain Object。

例如：

DecisionEngine
↓
Individual
↓
Goal
↓
Capability
↓
Method

Domain Object 表示：

当前系统中的实际领域对象。

Engine 表示：

对这些对象进行计算的执行单元。

因此：

$DomainObject≠EngineDomainObject\neq Engine$

例如：

class Individual
{
    protected $state;

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

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

Engine：

class StateEngine
{
    public function calculate($individual)
    {
        // 根据规则计算状态
    }
}

二者职责完全不同。

240.15 Engine计算与对象状态

ICAI 中的 Engine 不只是返回数据。

某些 Engine 的计算结果会改变 Domain Object 状态。

基本过程：

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

例如：

Individual
状态：idle
↓
DecisionEngine
↓
决定执行
↓
BehaviorEngine
↓
状态：running

因此：

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

其中：

$StatetState_t$ ：计算前状态；
$InputInput$ ：输入信息；
$RuleRule$ ：领域规则；
$FF$ ：状态计算函数；
$Statet+1State_{t+1}$ ：计算后的状态。

240.16 状态变化

**状态变化（State Change）**是指 Domain Object 在 Engine 执行前后，其状态值发生变化。

定义：

$StateChange=Statebefore≠Stateafter\boxed{ StateChange= State_{before} \neq State_{after} }$

例如：

before:
status = idle

after:
status = running

则：

$idle≠runningidle\neq running$

形成：

$StateChange=TrueStateChange=True$

如果：

before:
status = idle

after:
status = idle

则：

$StateChange=FalseStateChange=False$

240.17 状态变化不是Engine结果本身

需要区分：

$EngineResultEngineResult$

和：

$StateChangeStateChange$

Engine 可以计算成功，但不一定改变状态。

例如：

查询当前状态
↓
Engine
↓
查询成功
↓
状态仍然为 running

此时：

$EngineResult=SuccessEngineResult=Success$

但：

$StateChange=FalseStateChange=False$

所以：

$EngineSuccess≠StateChangeEngineSuccess \neq StateChange$

这是 ICAI 状态工程中的重要区别。

240.18 状态变化模型

可以建立统一状态模型：

$Statet→Input+RuleEngine→ResultStatet+1\boxed{ State_t \xrightarrow{Input+Rule} Engine \xrightarrow{Result} State_{t+1} }$

进一步：

$StateChange=Compare(Statet,Statet+1)StateChange= Compare(State_t,State_{t+1})$

其中：

$Compare(a,b)={True,a≠bFalse,a=bCompare(a,b)= \begin{cases} True,&a\neq b\\ False,&a=b \end{cases}$

如果存在多个状态属性：

$State={Status,Condition,Mode,Availability,Progress}State= \{Status,Condition,Mode,Availability,Progress\}$

则可以比较整个状态集合：

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

240.19 Service组织状态变化

Engine 负责计算状态变化，但 Service 负责把状态变化纳入完整业务流程。

例如：

Request
↓
BehaviorService
↓
BehaviorEngine
↓
计算动作
↓
产生行为结果
↓
判断状态变化
↓
更新Individual
↓
保存

因此：

$BehaviorEngine→StateChangeBehaviorEngine \rightarrow StateChange$

而：

$BehaviorService→StateChange→RepositoryBehaviorService \rightarrow StateChange \rightarrow Repository$

形成：

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

240.20 Engine与Repository边界

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

不推荐：

Service
↓
Engine
↓
SQL

因为这样 Engine 同时负责：

$Calculation+PersistenceCalculation+Persistence$

职责过多。

更合理：

Service
↓
Engine
↓
Result
↓
Domain Object
↓
Repository
↓
MySQL

即：

$Engine=CalculationEngine=Calculation$ $Repository=PersistenceRepository=Persistence$

因此：

$Engine≠RepositoryEngine\neq Repository$

240.21 Service协调Engine与Repository

Service 是两者之间的重要协调层。

完整过程：

Service
↓
读取Domain Object
↓
Engine计算
↓
获得EngineResult
↓
修改Domain Object
↓
Repository保存
↓
返回BusinessResult

数学形式：

$Objectt→Engine→Result→Objectt+1→RepositoryObject_t \rightarrow Engine \rightarrow Result \rightarrow Object_{t+1} \rightarrow Repository$

因此 Service 的重要职责之一就是：

$协调计算与持久化\boxed{ 协调计算与持久化 }$

240.22 一个简单的状态Engine

例如机器个体运行状态：

class StateEngine
{
    public function calculate($individual, $action)
    {
        $current = $individual->getState();

        if ($action === 'start') {

            if ($current === 'idle') {
                return array(
                    'status' => 'success',
                    'state' => 'running',
                    'changed' => true
                );
            }

            return array(
                'status' => 'blocked',
                'state' => $current,
                'changed' => false
            );
        }

        return array(
            'status' => 'failed',
            'state' => $current,
            'changed' => false
        );
    }
}

Engine 只计算：

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

并返回：

$EngineResultEngineResult$

240.23 Service调用StateEngine

Service：

class IndividualService
{
    protected $engine;

    public function __construct(
        StateEngine $engine
    ) {
        $this->engine = $engine;
    }

    public function changeState(
        $individual,
        $action
    ) {

        $result =
            $this->engine->calculate(
                $individual,
                $action
            );

        if (
            $result['status'] ===
            'success'
            &&
            $result['changed'] === true
        ) {
            $individual->setState(
                $result['state']
            );
        }

        return $result;
    }
}

形成：

$Service→StateEngine→EngineResultService \rightarrow StateEngine \rightarrow EngineResult$

然后：

$EngineResult→DomainObjectEngineResult \rightarrow DomainObject$

240.24 Service→Engine完整状态流程

完整结构：

BusinessRequest
↓
Service
↓
读取Domain Object
↓
读取当前State
↓
构造EngineInput
↓
Engine
↓
Calculation
↓
EngineResult
↓
判断是否改变
↓
Domain Object
↓
State更新
↓
Repository
↓
BusinessResult

数学表示：

$BR→S→E→ER→DO→State′→Repository→Result\boxed{ BR \rightarrow S \rightarrow E \rightarrow ER \rightarrow DO \rightarrow State’ \rightarrow Repository \rightarrow Result }$

其中：

$BRBR$ ：Business Request；
$SS$ ：Service；
$EE$ ：Engine；
$ERER$ ：Engine Result；
$DODO$ ：Domain Object；
$State'State’$ ：更新后的状态。

240.25 Engine计算的可重复性

在不涉及随机机制的情况下，同样的输入、规则和状态应该得到一致的计算结果。

即：

$F(Input,Rule,State)=ResultF(Input,Rule,State) = Result$

如果：

$Input1=Input2Input_1=Input_2$ $Rule1=Rule2Rule_1=Rule_2$ $State1=State2State_1=State_2$

则：

$Result1=Result2Result_1=Result_2$

这有利于 ICAI 的：

调试；
测试；
错误定位；
状态追踪；
结果验证；
历史重现。

因此 Engine 应尽量保持明确的输入和输出边界。

240.26 Engine不直接决定所有业务

Engine 虽然负责计算，但不能因此把整个业务流程都放进去。

例如：

DecisionService
↓
DecisionEngine

Engine 计算：

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

但是：

是否记录决策
是否更新行为状态
是否写入历史
是否通知其他模块

这些属于 Service 的业务流程协调。

因此：

$Engine=领域计算Engine=领域计算$ $Service=业务协调Service=业务协调$

240.27 多Engine组合

一个 Service 可以调用多个 Engine。

例如决策服务：

DecisionService
│
├── GoalEngine
├── CapabilityEngine
├── MatchingEngine
├── MethodEngine
├── RiskEngine
└── DecisionEngine

流程：

$GoalEngine→CapabilityEngine→MatchingEngine→MethodEngine→RiskEngine→DecisionEngineGoalEngine \rightarrow CapabilityEngine \rightarrow MatchingEngine \rightarrow MethodEngine \rightarrow RiskEngine \rightarrow DecisionEngine$

但这些 Engine 的调用顺序应该由 Service 根据业务流程进行组织。

因此：

$Service=Engine1→Engine2→Engine3→…Service = Engine_1 \rightarrow Engine_2 \rightarrow Engine_3 \rightarrow …$

而不是让 Engine 自己形成不可控制的调用网络。

240.28 ICAI中的Engine分类

按照 ICAI 理论结构，可以建立：

认知类

CognitiveEngine
ObjectEngine
AttributeEngine
StateEngine
RelationEngine
SceneEngine
KnowledgeEngine

需求目标类

NeedEngine
GoalEngine

能力匹配类

CapabilityEngine
MatchingEngine
MethodEngine

决策行为类

DecisionEngine
BehaviorEngine
ActionEngine
ResultEngine
FeedbackEngine

记忆学习类

MemoryEngine
ExperienceEngine
LearningEngine
UpdateEngine

维护类

RiskEngine
ConflictEngine
DiagnosisEngine
ProtectionEngine
RepairEngine

这些 Engine 都属于 ICAI 通用核心理论的工程执行单元。

240.29 Engine与ICAI运行循环

ICAI 的运行循环：

$Cognition→Need→Goal→Capability→Matching→Method→Decision→Behavior→Action→Result→Feedback→Memory→Learning→UpdateCognition \rightarrow Need \rightarrow Goal \rightarrow Capability \rightarrow Matching \rightarrow Method \rightarrow Decision \rightarrow Behavior \rightarrow Action \rightarrow Result \rightarrow Feedback \rightarrow Memory \rightarrow Learning \rightarrow Update$

在工程中可以映射为：

CognitiveEngine
↓
NeedEngine
↓
GoalEngine
↓
CapabilityEngine
↓
MatchingEngine
↓
MethodEngine
↓
DecisionEngine
↓
BehaviorEngine
↓
ActionEngine
↓
ResultEngine
↓
FeedbackEngine
↓
MemoryEngine
↓
LearningEngine
↓
UpdateEngine

Service 不一定一次调用全部 Engine。

具体调用链由业务请求决定。

240.30 Engine与个体状态持续变化

ICAI 的机器个体不是静态对象。

其状态随着运行不断变化：

$It→Engine→It+1I_t \rightarrow Engine \rightarrow I_{t+1}$

例如：

idle
↓
running
↓
waiting
↓
completed
↓
learning
↓
updated

因此机器个体生命周期中的状态变化可以表示为：

$State0→EngineState1→EngineState2→Engine…State_0 \xrightarrow{Engine} State_1 \xrightarrow{Engine} State_2 \xrightarrow{Engine} …$

每次状态变化都可以形成历史记录：

$History={State0,State1,…,Staten}History= \{State_0,State_1,\ldots,State_n\}$

这为第150章建立的机器个体记忆结构提供工程基础。

240.31 状态变化记录

当 Engine 导致状态变化时，可以记录：

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

例如：

Object: Individual#15
Before: idle
After: running
Reason: start
Time: 2026-09-05 18:00:00

数据库可以建立：

individual_state_history

字段：

id
individual_id
before_state
after_state
reason
created_at

形成：

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

240.32 Engine异常

Engine 在计算过程中也可能发生异常。

例如：

输入对象不存在；
状态数据缺失；
规则不存在；
计算条件冲突；
Domain Object 无效；
内部计算错误。

因此：

$Engine→ExceptionEngine \rightarrow Exception$

Service 可以统一处理：

$Service→Engine→ExceptionService \rightarrow Engine \rightarrow Exception$

再形成：

$Exception→Service→BusinessResultException \rightarrow Service \rightarrow BusinessResult$

或者：

$Exception→HandlerException \rightarrow Handler$

Engine 不应该为了隐藏错误而简单返回空值：

return null;

应该明确区分：

$ValidResultValidResult$

与：

$ExceptionException$

240.33 Service→Engine与自我维护

ICAI 的维护过程同样通过 Service→Engine 结构实现。

例如：

MaintenanceService
↓
RiskEngine
↓
DiagnosisEngine
↓
ProtectionEngine
↓
RepairEngine

完整过程：

$RiskDetection→Diagnosis→Protection→RepairRiskDetection \rightarrow Diagnosis \rightarrow Protection \rightarrow Repair$

对应：

$Service→Engine1→Engine2→Engine3→Engine4Service \rightarrow Engine_1 \rightarrow Engine_2 \rightarrow Engine_3 \rightarrow Engine_4$

最终可能导致：

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

例如：

正常
↓
发现异常
↓
风险状态
↓
保护状态
↓
修复状态
↓
恢复正常

这说明 Service→Engine 不只是普通 CRUD 工程关系，也是 ICAI 自我维护机制的工程基础。

240.34 Service→Engine与学习

学习过程也可以采用相同结构：

LearningService
↓
LearningEngine
↓
Experience
↓
Knowledge
↓
Memory
↓
Update

例如：

$Experience→LearningEngine→KnowledgeUpdateExperience \rightarrow LearningEngine \rightarrow KnowledgeUpdate$

然后：

$KnowledgeUpdate→MemoryKnowledgeUpdate \rightarrow Memory$

形成：

$Service→Engine→LearningResult→MemoryService \rightarrow Engine \rightarrow LearningResult \rightarrow Memory$

因此认知、决策、行为、维护和学习都可以共享统一的 Service→Engine 工程结构。

240.35 Service→Engine与数据库

数据库不应该成为 Engine 的核心计算位置。

240.36 Service→Engine完整工程模型

综合本章，可以建立：

HTTP Request
        ↓
    Controller
        ↓
   Parameter
        ↓
     Service
        ↓
 Business Request
        ↓
 Domain Object
        ↓
      Engine
        ↓
   Calculation
        ↓
   EngineResult
        ↓
 State Comparison
        ↓
 Domain Object
        ↓
 State Change
        ↓
   Repository
        ↓
      MySQL
        ↓
 Business Result
        ↓
     Controller
        ↓
   View / JSON

其核心数学关系：

$EngineResult=F(BusinessInput,Rule,State,Condition)\boxed{ EngineResult= F(BusinessInput,Rule,State,Condition) }$

状态变化：

$Statet+1=G(Statet,EngineResult)\boxed{ State_{t+1} = G(State_t,EngineResult) }$

业务最终结果：

$BusinessResult=H(EngineResult,StateChange,BusinessRule)\boxed{ BusinessResult= H(EngineResult,StateChange,BusinessRule) }$

240.37 Service→Engine核心边界

最终可以将三层职责明确为：

$Controller=Request\boxed{ Controller=Request }$ $Service=Process\boxed{ Service=Process }$ $Engine=Calculation\boxed{ Engine=Calculation }$

进一步：

$DomainObject=State\boxed{ DomainObject=State }$ $Repository=Persistence\boxed{ Repository=Persistence }$

因此形成：

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

但实际数据并不是简单单向流动。

计算过程为：

$DomainObject→Engine→EngineResult→DomainObjectDomainObject \rightarrow Engine \rightarrow EngineResult \rightarrow DomainObject$

保存过程为：

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

所以完整工程结构实际上是：

Controller
   ↓
Service
   ↓
Engine ← Domain Object
   ↓          ↑
Result ───────┘
   ↓
Domain Object
   ↓
Repository
   ↓
MySQL

240.38 本章总结

Service→Engine 是 ICAI 从业务流程进入领域计算的核心工程关系。

业务请求首先进入 Service：

$BusinessRequest→ServiceBusinessRequest \rightarrow Service$

Service 根据业务流程选择相应 Engine：

$Service→EngineService \rightarrow Engine$

Engine 根据输入、规则、状态和条件进行计算：

$EngineResult=F(Input,Rule,State,Condition)\boxed{ EngineResult= F(Input,Rule,State,Condition) }$

计算结果返回 Service：

$Engine→EngineResult→ServiceEngine \rightarrow EngineResult \rightarrow Service$

如果计算结果导致对象状态发生变化：

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

然后由 Service 协调 Domain Object 和 Repository：

$EngineResult→DomainObject→Repository→MySQL\boxed{ EngineResult \rightarrow DomainObject \rightarrow Repository \rightarrow MySQL }$

因此，本章建立了五个核心工程关系：

$BusinessRequest→Service\boxed{ BusinessRequest \rightarrow Service }$ $Service→Engine\boxed{ Service \rightarrow Engine }$ $Engine→EngineResult\boxed{ Engine \rightarrow EngineResult }$ $EngineResult→StateChange\boxed{ EngineResult \rightarrow StateChange }$ $StateChange→Repository\boxed{ StateChange \rightarrow Repository }$

最终形成 ICAI 的业务计算链：

$Controller→Service→Engine→Result→State→Repository\boxed{ Controller \rightarrow Service \rightarrow Engine \rightarrow Result \rightarrow State \rightarrow Repository }$

其中：

$Controller=请求入口Controller=请求入口$ $Service=业务流程Service=业务流程$ $Engine=领域计算Engine=领域计算$ $Result=计算结果Result=计算结果$ $State=个体当前状态State=个体当前状态$ $Repository=持久化Repository=持久化$

由此，Service→Engine 不仅解决了 MVC 中业务层与计算层的职责划分，也建立了 ICAI 从业务请求→领域计算→计算结果→状态变化→持久化的完整工程路径，为后续 Engine 内部实现、Domain Object 状态管理以及 ICAI Runtime 的持续运行提供基础。

第240章 Service→Engine

第240章 Service→Engine

240.1 提出背景

240.2 Service→Engine定义

240.3 业务请求

240.4 Service为什么调用Engine

240.5 Engine定义

240.6 Service与Engine职责区别

240.7 Service→Engine基本流程

240.8 Engine输入

240.9 Engine计算模型

240.10 Engine不是Service的简单改名

240.11 Engine结果

240.12 Engine结果与Service结果

240.13 Engine结果状态

240.14 Engine与Domain Object

240.15 Engine计算与对象状态

240.16 状态变化

240.17 状态变化不是Engine结果本身

240.18 状态变化模型

240.19 Service组织状态变化

240.20 Engine与Repository边界

240.21 Service协调Engine与Repository

240.22 一个简单的状态Engine

240.23 Service调用StateEngine

240.24 Service→Engine完整状态流程

240.25 Engine计算的可重复性

240.26 Engine不直接决定所有业务

240.27 多Engine组合

240.28 ICAI中的Engine分类

认知类

需求目标类

能力匹配类

决策行为类

记忆学习类

维护类

240.29 Engine与ICAI运行循环

240.30 Engine与个体状态持续变化

240.31 状态变化记录

240.32 Engine异常

240.33 Service→Engine与自我维护

240.34 Service→Engine与学习

240.35 Service→Engine与数据库

240.36 Service→Engine完整工程模型

240.37 Service→Engine核心边界

240.38 本章总结