第215章　IndividualRepository

215.1 IndividualRepository定义

在第214章中已经确定：

Repository 是 Domain Object 与持久化系统之间的边界。

IndividualRepository 是专门负责 Individual 个体对象持久化 的 Repository。

它并不负责个体的认知计算，也不负责决定个体应该做什么，而是负责把当前的 Individual Domain Object 保存到 MySQL，并能够从 MySQL 中重新读取并恢复为 Individual Domain Object。

因此：

$IndividualRepository=IndividualLoad+IndividualSave+IndividualUpdate+IndividualDeleteIndividualRepository = IndividualLoad + IndividualSave + IndividualUpdate + IndividualDelete$

其核心模型为：

$IR=(I,M,Q,P,D,T)IR=(I,M,Q,P,D,T)$

其中：

$II$ ：Individual，个体领域对象；
$MM$ ：Mapping，对象与数据库之间的映射；
$QQ$ ：Query，数据读取与查询；
$PP$ ：Persistence，数据保存与更新；
$DD$ ：Delete，数据删除；
$TT$ ：Time，操作时间。

IndividualRepository 的基本职责可以表示为：

Individual Domain Object
        ↓
IndividualRepository
        ↓
Object Mapping
        ↓
PDO
        ↓
MySQL

反方向读取：

MySQL
   ↓
PDO
   ↓
IndividualRepository
   ↓
Object Mapping
   ↓
Individual Domain Object

因此，IndividualRepository 是：

$IndividualRepository=Individual Persistence Boundary\boxed{IndividualRepository=Individual\ Persistence\ Boundary}$

215.2 Individual对象结构

Individual 并不是一张简单的数据表。

前面的 ICAI OOP 体系已经定义 Individual 为一个组合型认知对象。

可以表示为：

$I=(ID,T,O,K,C,M,B,MM,E,R,S)I=(ID,T,O,K,C,M,B,MM,E,R,S)$

其中：

$IDID$ ：个体唯一标识；
$TT$ ：个体类型；
$OO$ ：Object，对象集合；
$KK$ ：Knowledge，知识集合；
$CC$ ：Capability，能力集合；
$MM$ ：Method，方法集合；
$BB$ ：Behavior，行为集合；
$MMMM$ ：Memory，记忆集合；
$EE$ ：Experience，经验集合；
$RR$ ：Relation，关系集合；
$SS$ ：当前状态。

因此，一个 Individual 的数据库结构通常不是：

individuals

这一张表就可以完成全部保存。

而是：

individuals
objects
object_attributes
object_relations
knowledge
capabilities
methods
behaviors
actions
executions
memories
experiences
states
histories

等多个持久化结构共同构成。

因此：

$Individual≠individuals tableIndividual \neq individuals\ table$

而是：

$Individual=individuals+Objects+Knowledge+Capabilities+Methods+Behaviors+Memory+Experience+Relations+StateIndividual = individuals + Objects + Knowledge + Capabilities + Methods + Behaviors + Memory + Experience + Relations + State$

IndividualRepository 的重要任务，就是正确处理这种 聚合结构。

215.3 个体保存

215.3.1 保存的基本含义

个体保存不是简单执行：

INSERT INTO individuals

而是：

Individual Domain Object
        ↓
验证
        ↓
对象映射
        ↓
判断是否存在
        ↓
保存 Individual
        ↓
保存关联结构
        ↓
验证保存结果
        ↓
返回 Persistence Result

因此：

$Save(I)→Validate→Map→Persist→VerifySave(I) \rightarrow Validate \rightarrow Map \rightarrow Persist \rightarrow Verify$

215.3.2 个体保存条件

Individual 保存之前必须首先判断：

$ValidIndividual=ID∧Type∧State∧StructureValidIndividual = ID \land Type \land State \land Structure$

其中：

$IDID$ ：存在合法身份；
$TypeType$ ：存在合法个体类型；
$StateState$ ：当前状态结构合法；
$StructureStructure$ ：组合结构可以正确映射。

不能因为对象 PHP 实例存在，就直接认为它可以保存。

：

PHP Object存在
        ≠
Domain Object有效
        ≠
Persistence Data有效

215.4 Individual保存与子对象保存

Individual 是组合对象，因此保存时必须处理其内部结构。

例如：

Individual I-001
    ├── Object O-001
    ├── Object O-002
    ├── Knowledge K-001
    ├── Capability C-001
    ├── Method M-001
    ├── Behavior B-001
    ├── Memory M-001
    └── Experience E-001

保存流程可以表示为：

$Save(I)→Save(Ibase)→Save(O)→Save(K)→Save(C)→Save(M)→Save(B)→Save(MM)→Save(E)→Save(R)Save(I) \rightarrow Save(I_{base}) \rightarrow Save(O) \rightarrow Save(K) \rightarrow Save(C) \rightarrow Save(M) \rightarrow Save(B) \rightarrow Save(MM) \rightarrow Save(E) \rightarrow Save(R)$

但是这里必须区分 IndividualRepository 自身职责 与其他 Repository 的职责。

IndividualRepository 不应该重新实现所有 Repository 的 SQL。

正确结构是：

IndividualRepository
        ↓
IndividualRepository协调
        ↓
ObjectRepository
KnowledgeRepository
CapabilityRepository
MethodRepository
BehaviorRepository
MemoryRepository
ExperienceRepository
RelationRepository
        ↓
MySQL

因此：

$IndividualRepository≠AllRepositoryIndividualRepository \neq AllRepository$

它是 Individual 聚合的持久化协调者。

215.5 个体读取

215.5.1 基本读取

IndividualRepository 的读取操作是：

$Load(ID)→ILoad(ID)\rightarrow I$

也就是：

Individual ID
      ↓
查询 individuals
      ↓
读取基础信息
      ↓
读取状态
      ↓
读取对象
      ↓
读取知识
      ↓
读取能力
      ↓
读取方法
      ↓
读取行为
      ↓
读取记忆
      ↓
读取经验
      ↓
读取关系
      ↓
组装 Individual
      ↓
返回 Domain Object

215.6 个体读取不是数据库查询结束

一个非常重要的原则是：

$Database Record≠Domain ObjectDatabase\ Record \neq Domain\ Object$

数据库只保存持久化数据。

Repository 必须把这些数据重新组合成领域对象。

例如 MySQL：

individuals
id = 1
type = human
name = Engineer
state = ready

读取之后不能只返回：

array(
    'id' => 1,
    'type' => 'human',
    'name' => 'Engineer',
    'state' => 'ready'
);

而应该经过 Mapping：

Persistence Data
        ↓
IndividualMapper
        ↓
Individual Object

最终形成：

$individual = new Individual();
$individual->setId(1);
$individual->setType('human');
$individual->setName('Engineer');
$individual->setState('ready');

然后再装载：

Objects
Knowledge
Capabilities
Methods
Behaviors
Memory
Experience
Relations

形成完整 Individual。

215.7 个体读取的两种模式

IndividualRepository 可以提供两种读取方式。

215.7.1 基础读取

只读取 Individual 本体：

$LoadBase(ID)→IbaseLoadBase(ID)\rightarrow I_{base}$

用于：

列表
身份判断
基础状态查询
简单权限判断

215.7.2 聚合读取

读取完整 Individual：

$LoadAggregate(ID)→(I,O,K,C,M,B,MM,E,R,S)LoadAggregate(ID) \rightarrow (I,O,K,C,M,B,MM,E,R,S)$

用于：

认知计算
决策
行为生成
学习
维护
更新

因此可以定义：

findById($id);
loadAggregate($id);

两者不能混淆。

完整认知计算不应该错误地使用只有基础字段的 Individual。

215.8 个体更新

个体更新不是重新建立一个 Individual。

其基本模型为：

$It+ΔI→It+1I_t+\Delta I\rightarrow I_{t+1}$

其中：

$ItI_t$ ：当前个体；
$ΔI\Delta I$ ：经过验证的变化；
$It+1I_{t+1}$ ：更新后的个体。

更新流程：

Current Individual
        ↓
读取当前持久化数据
        ↓
Compare
        ↓
计算 ΔI
        ↓
验证变化
        ↓
Update
        ↓
Read Back
        ↓
Verify
        ↓
Updated Individual

215.9 个体更新必须遵守最小更新原则

如果一次认知过程只证明：

Capability C1
state:
available → blocked

那么更新：

$ΔI=ΔC1state\Delta I=\Delta C1_{state}$

而不能因为一个能力发生变化，就重新生成：

Individual
Object
Knowledge
Capability
Method
Behavior
Memory
Experience

全部结构。

因此：

$Update(I,ΔI)Update(I,\Delta I)$

必须尽可能只修改被验证发生变化的部分。

这就是：

$Minimal Update Principle\boxed{Minimal\ Update\ Principle}$

215.10 Individual更新的层次

Individual 更新可以分为四个层次。

第一层：Individual基础属性

例如：

name
type
description
status

第二层：Individual当前状态

例如：

ready
active
blocked
inactive

第三层：Individual组合结构

例如：

新增 Capability
修改 Method
新增 Knowledge
更新 Memory
新增 Experience

第四层：Individual关系

例如：

Object → belongs_to → Individual
Method → requires → Capability
Knowledge → supports → Method

因此：

$ΔI=ΔA+ΔS+ΔStructure+ΔR\Delta I = \Delta A + \Delta S + \Delta Structure + \Delta R$

其中：

$ΔA\Delta A$ ：基础属性变化；
$ΔS\Delta S$ ：状态变化；
$ΔStructure\Delta Structure$ ：组合结构变化；
$ΔR\Delta R$ ：关系变化。

215.11 个体删除

Individual 删除是四种操作中风险最高的一种。

原因是：

$Individual→Objects→Relations→History→Memory→ExperienceIndividual \rightarrow Objects \rightarrow Relations \rightarrow History \rightarrow Memory \rightarrow Experience$

存在大量关联数据。

因此：

删除 Individual
≠
DELETE FROM individuals

215.12 个体删除类型

IndividualRepository 应区分三种删除。

215.12.1 逻辑删除

保留数据，只修改状态：

active
↓
deleted

例如：

UPDATE individuals
SET status = 'deleted'
WHERE id = ?

这种方式最适合需要保留历史的 ICAI 系统。

215.12.2 归档

将 Individual 从当前运行数据转移到归档状态：

active
↓
archived

其历史数据仍然保留。

适合：

长期不再使用的 Individual
历史个体
旧认知结构
旧运行实例

215.12.3 物理删除

真正执行：

DELETE

只有在明确允许并确认不存在必要历史、关系和依赖时才能执行。

因此：

$PhysicalDeletePhysicalDelete$

必须经过：

$ReferenceCheck∧HistoryPolicy∧DeleteRuleReferenceCheck \land HistoryPolicy \land DeleteRule$

215.13 个体删除前的引用检查

删除 Individual 之前必须检查：

Object References
Knowledge References
Capability References
Method References
Behavior References
Memory References
Experience References
Relation References
History References

例如：

Individual I-001
        ↑
Method M-001
        ↑
Behavior B-001
        ↑
Execution E-001
        ↑
Result R-001

如果直接删除 I-001，而历史记录仍然引用它，就可能形成：

Broken Reference

因此：

$CanDelete(I)=NoRequiredReference∧DeleteRule∧HistoryPolicyCanDelete(I) = NoRequiredReference \land DeleteRule \land HistoryPolicy$

如果条件不满足，则应该返回：

blocked

而不是强制删除。

215.14 IndividualRepository PHP接口

兼容 PHP 5.6 / PHP 7 的基本接口可以设计为：

<?php

interface IndividualRepositoryInterface
{
    public function findById($id);

    public function loadAggregate($id);

    public function save($individual);

    public function update($individual);

    public function delete($id);

    public function archive($id);

    public function exists($id);
}

这里的接口只描述持久化能力，不包含认知计算。

215.15 IndividualMapper

IndividualMapper 负责 Domain Object 与 Persistence Data 之间的转换。

<?php

class IndividualMapper
{
    public function toPersistence($individual)
    {
        return array(
            'id' => $individual->getId(),
            'type' => $individual->getType(),
            'name' => $individual->getName(),
            'status' => $individual->getStatus()
        );
    }

    public function toDomain($data)
    {
        $individual = new Individual();

        $individual->setId($data['id']);
        $individual->setType($data['type']);
        $individual->setName($data['name']);
        $individual->setStatus($data['status']);

        return $individual;
    }
}

Mapper 不负责：

Decision
Learning
Risk
Diagnosis
Behavior

它只负责：

$PersistenceData↔DomainObjectPersistenceData \leftrightarrow DomainObject$

215.16 IndividualRepository基本实现

下面建立一个 MySQL/PDO Repository 的基本结构。

<?php

class MySQLIndividualRepository implements IndividualRepositoryInterface
{
    protected $pdo;
    protected $mapper;

    public function __construct(PDO $pdo, IndividualMapper $mapper)
    {
        $this->pdo = $pdo;
        $this->mapper = $mapper;
    }

    public function exists($id)
    {
        $sql = "
            SELECT COUNT(*) AS total
            FROM individuals
            WHERE id = :id
        ";

        $stmt = $this->pdo->prepare($sql);
        $stmt->execute(array(
            ':id' => $id
        ));

        $row = $stmt->fetch(PDO::FETCH_ASSOC);

        return ((int)$row['total'] > 0);
    }

    public function findById($id)
    {
        $sql = "
            SELECT *
            FROM individuals
            WHERE id = :id
            LIMIT 1
        ";

        $stmt = $this->pdo->prepare($sql);

        $stmt->execute(array(
            ':id' => $id
        ));

        $data = $stmt->fetch(PDO::FETCH_ASSOC);

        if (!$data) {
            return null;
        }

        return $this->mapper->toDomain($data);
    }

    public function save($individual)
    {
        $data = $this->mapper->toPersistence($individual);

        $sql = "
            INSERT INTO individuals
            (
                id,
                type,
                name,
                status
            )
            VALUES
            (
                :id,
                :type,
                :name,
                :status
            )
        ";

        $stmt = $this->pdo->prepare($sql);

        return $stmt->execute(array(
            ':id' => $data['id'],
            ':type' => $data['type'],
            ':name' => $data['name'],
            ':status' => $data['status']
        ));
    }

    public function update($individual)
    {
        $data = $this->mapper->toPersistence($individual);

        $sql = "
            UPDATE individuals
            SET
                type = :type,
                name = :name,
                status = :status
            WHERE id = :id
        ";

        $stmt = $this->pdo->prepare($sql);

        return $stmt->execute(array(
            ':id' => $data['id'],
            ':type' => $data['type'],
            ':name' => $data['name'],
            ':status' => $data['status']
        ));
    }

    public function delete($id)
    {
        $sql = "
            DELETE FROM individuals
            WHERE id = :id
        ";

        $stmt = $this->pdo->prepare($sql);

        return $stmt->execute(array(
            ':id' => $id
        ));
    }

    public function archive($id)
    {
        $sql = "
            UPDATE individuals
            SET status = 'archived'
            WHERE id = :id
        ";

        $stmt = $this->pdo->prepare($sql);

        return $stmt->execute(array(
            ':id' => $id
        ));
    }

    public function loadAggregate($id)
    {
        $individual = $this->findById($id);

        if (!$individual) {
            return null;
        }

        /*
         * 此处由各专用Repository负责加载
         * Object / Knowledge / Capability / Method /
         * Behavior / Memory / Experience / Relation
         */

        return $individual;
    }
}

这里的 loadAggregate() 是聚合读取入口。

实际工程中，不应该在 IndividualRepository 中复制所有子 Repository 的 SQL，而应该组合专用 Repository。

215.17 聚合读取结构

可以进一步建立：

<?php

class IndividualAggregateLoader
{
    protected $objectRepository;
    protected $knowledgeRepository;
    protected $capabilityRepository;
    protected $methodRepository;
    protected $behaviorRepository;
    protected $memoryRepository;
    protected $experienceRepository;
    protected $relationRepository;

    public function load($individual)
    {
        $id = $individual->getId();

        $individual->setObjects(
            $this->objectRepository->findByIndividualId($id)
        );

        $individual->setKnowledge(
            $this->knowledgeRepository->findByIndividualId($id)
        );

        $individual->setCapabilities(
            $this->capabilityRepository->findByIndividualId($id)
        );

        $individual->setMethods(
            $this->methodRepository->findByIndividualId($id)
        );

        $individual->setBehaviors(
            $this->behaviorRepository->findByIndividualId($id)
        );

        $individual->setMemories(
            $this->memoryRepository->findByIndividualId($id)
        );

        $individual->setExperiences(
            $this->experienceRepository->findByIndividualId($id)
        );

        $individual->setRelations(
            $this->relationRepository->findByIndividualId($id)
        );

        return $individual;
    }
}

这样形成：

IndividualRepository
        ↓
IndividualAggregateLoader
        ↓
┌──────────────┬──────────────┬──────────────┐
ObjectRepo     KnowledgeRepo  CapabilityRepo
MethodRepo     BehaviorRepo   MemoryRepo
ExperienceRepo RelationRepo
        ↓
      MySQL

这种结构可以避免 IndividualRepository 变成一个拥有数千行 SQL 的巨大类。

215.18 个体保存事务

如果保存一个完整 Individual，需要同时保存：

Individual
Object
Knowledge
Capability
Method
Relation

那么必须考虑事务。

完整保存：

$Begin→Save(I)→Save(O)→Save(K)→Save(C)→Save(M)→Save(R)→Verify→CommitBegin \rightarrow Save(I) \rightarrow Save(O) \rightarrow Save(K) \rightarrow Save(C) \rightarrow Save(M) \rightarrow Save(R) \rightarrow Verify \rightarrow Commit$

任何关键步骤失败：

$Failure→RollbackFailure \rightarrow Rollback$

但是必须注意：

$DatabaseRollback≠ExternalWorldRollbackDatabaseRollback \neq ExternalWorldRollback$

数据库事务只能回滚数据库中的操作。

如果 Individual 已经执行了外部行为，数据库回滚不能让外部行为“没有发生”。

215.19 个体更新事务

更新可以表示为：

$Begin→Load→Compare→Validate→Update→UpdateRelations→Verify→CommitBegin \rightarrow Load \rightarrow Compare \rightarrow Validate \rightarrow Update \rightarrow UpdateRelations \rightarrow Verify \rightarrow Commit$

例如：

Capability C1
available
    ↓
blocked

如果只发生能力状态变化：

UPDATE capabilities

而不应该重新保存整个 Individual。

因此：

$Update(I,ΔC)Update(I,\Delta C)$

比：

$Delete(I)+Rebuild(I)Delete(I)+Rebuild(I)$

更加合理。

215.20 个体删除事务

安全删除：

Begin
   ↓
Load Individual
   ↓
Check References
   ↓
Check History
   ↓
Check Delete Rule
   ↓
Delete / Archive
   ↓
Verify
   ↓
Commit

如果引用检查失败：

Rollback
        ↓
Delete Blocked

这可以避免因为错误删除 Individual 导致整个认知历史结构损坏。

215.21 IndividualRepository与Service

IndividualRepository 不应该被 Controller 直接承担完整业务流程。

正确结构：

Controller
    ↓
IndividualService
    ↓
IndividualRepository
    ↓
MySQL

如果需要认知计算：

Controller
    ↓
IndividualService
    ├── IndividualRepository
    ├── CognitiveEngine
    ├── GoalService
    ├── CapabilityService
    ├── MethodService
    ├── DecisionService
    └── LearningService

因此：

$IndividualService=Application OrchestrationIndividualService = Application\ Orchestration$

而：

$IndividualRepository=PersistenceIndividualRepository = Persistence$

215.22 IndividualRepository与Engine

IndividualRepository 不能代替 CognitiveEngine。

例如：

IndividualRepository
        ↓
Load Individual
        ↓
CognitiveEngine
        ↓
ObjectEngine
StateEngine
RelationEngine
SceneEngine
KnowledgeEngine

Repository 提供：

事实
对象
历史
状态
关系
知识

Engine 负责：

计算
匹配
推导
判断
验证

因此：

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

两者职责不能混合。

215.23 个体保存后的读取验证

保存成功不能仅仅依赖：

$stmt->execute()

因为：

$SQL Success≠Domain Persistence SuccessSQL\ Success \neq Domain\ Persistence\ Success$

保存后可以重新读取：

Save
 ↓
ReadBack
 ↓
Compare
 ↓
Verify

例如：

$VerifySave=Exists∧IdentityMatch∧StateMatchVerifySave = Exists \land IdentityMatch \land StateMatch$

如果保存后的数据无法重新读取或核心字段不一致，就不能简单返回：

success

而应该返回持久化验证失败。

215.24 Repository结果模型

IndividualRepository 可以统一返回：

$IRR=(I,A,S,E,T)IRR=(I,A,S,E,T)$

其中：

$II$ ：Individual；
$AA$ ：Persistence Action；
$SS$ ：Persistence Status；
$EE$ ：Error / Evidence；
$TT$ ：Time。

例如：

array(
    'individual_id' => 1,
    'action' => 'update',
    'status' => 'success',
    'verified' => true,
    'time' => time()
);

失败：

array(
    'individual_id' => 1,
    'action' => 'delete',
    'status' => 'blocked',
    'reason' => 'required_reference_exists',
    'verified' => false,
    'time' => time()
);

这样 Repository 的返回结果也具有可追踪性。

215.25 IndividualRepository数据库结构

基础 individuals 表可以承担 Individual 本体：

CREATE TABLE individuals (
    id INT NOT NULL AUTO_INCREMENT,
    type VARCHAR(100) NOT NULL,
    name VARCHAR(255) NOT NULL,
    status VARCHAR(50) NOT NULL,
    created_at DATETIME NOT NULL,
    updated_at DATETIME NOT NULL,
    PRIMARY KEY (id)
);

其他认知结构通过外键或关联表连接：

individuals
    │
    ├── objects
    ├── knowledge
    ├── capabilities
    ├── methods
    ├── behaviors
    ├── memories
    ├── experiences
    ├── relations
    └── state_history

实际数据库设计应根据项目已有表结构建立，不应为了 Repository 强行重建已有数据库。

215.26 个体生命周期

IndividualRepository 对应的持久化生命周期可以统一为：

Create
   ↓
Initialize
   ↓
Save
   ↓
Load
   ↓
Runtime
   ↓
Modify
   ↓
Validate
   ↓
Update
   ↓
Verify
   ↓
Archive
   ↓
Delete

但认知生命周期与持久化生命周期并不相同。

例如：

Individual
   ↓
CognitiveEngine
   ↓
Decision
   ↓
Behavior
   ↓
Execution
   ↓
Result
   ↓
Feedback
   ↓
Learning
   ↓
UpdateEngine
   ↓
IndividualRepository

最终才形成：

$It+1I_{t+1}$

并保存到数据库。

215.27 IndividualRepository与UpdateEngine

前面的 UpdateEngine 已经确定：

$It+ΔI→It+1I_t+\Delta I\rightarrow I_{t+1}$

UpdateEngine 负责计算并应用经过验证的更新结构。

Repository 负责持久化。

因此：

Feedback
   ↓
Experience
   ↓
LearningEngine
   ↓
Update Candidate
   ↓
UpdateEngine
   ↓
Updated Individual
   ↓
IndividualRepository
   ↓
MySQL

不能写成：

LearningEngine
      ↓
MySQL

因为这样会绕过 UpdateEngine 和 Repository。

215.28 Individual删除与历史保护

ICAI 中的：

History
Memory
Experience
Decision History
Behavior History
Execution History
Feedback History
Learning History

都可能具有长期价值。

因此：

$Delete Individual≠Delete HistoryDelete\ Individual \neq Delete\ History$

尤其当历史数据用于：

Experience
Learning
Diagnosis
Risk
Verification

时，强制物理删除可能破坏系统的认知连续性。

因此更安全的策略通常是：

Individual Active
       ↓
Individual Archived
       ↓
Current Runtime停止
       ↓
Historical Data保留

215.29 IndividualRepository完整工程关系

最终形成：

                    Controller
                         ↓
                 IndividualService
                         ↓
              ┌──────────┴──────────┐
              ↓                     ↓
     Cognitive / Domain       IndividualRepository
              ↓                     ↓
       Object / State /      AggregateLoader
       Relation / Knowledge       ↓
       Capability / Method    Other Repositories
              ↓                     ↓
            Engine                PDO
                                    ↓
                                  MySQL

如果发生学习更新：

Feedback
   ↓
Memory
   ↓
Experience
   ↓
LearningEngine
   ↓
Update Candidate
   ↓
UpdateEngine
   ↓
Individual
   ↓
IndividualRepository
   ↓
MySQL

如果发生异常：

Detection
   ↓
Risk / Conflict
   ↓
Diagnosis
   ↓
Repair
   ↓
Verification
   ↓
UpdateEngine
   ↓
IndividualRepository
   ↓
MySQL

215.30 IndividualRepository四项核心能力

因此，IndividualRepository 最核心的四项能力可以正式定义为：

一、个体保存

$Save(I)→Validate→Map→Persist→VerifySave(I) \rightarrow Validate \rightarrow Map \rightarrow Persist \rightarrow Verify$

负责把合法 Individual 持久化。

二、个体读取

$Load(ID)→Query→Map→ReconstructLoad(ID) \rightarrow Query \rightarrow Map \rightarrow Reconstruct$

负责从数据库恢复 Individual。

三、个体更新

$It+ΔI→Validate→Update→VerifyI_t+\Delta I \rightarrow Validate \rightarrow Update \rightarrow Verify$

负责保存经过验证的最小变化。

四、个体删除

$Delete(I)→ReferenceCheck→DeletePolicy→Archive/Delete→VerifyDelete(I) \rightarrow ReferenceCheck \rightarrow DeletePolicy \rightarrow Archive/Delete \rightarrow Verify$

负责在保护关系与历史的前提下进行删除。

215.31 本章核心原则

IndividualRepository 必须遵守以下原则。

第一，Individual 不是一张表。

$Individual≠individuals tableIndividual \neq individuals\ table$

第二，Repository 不负责认知。

$Repository≠CognitiveEngineRepository \neq CognitiveEngine$

第三，Repository 不负责决策。

$Repository≠DecisionEngineRepository \neq DecisionEngine$

第四，Repository 不负责学习。

$Repository≠LearningEngineRepository \neq LearningEngine$

第五，Repository 不负责更新计算。

$Repository≠UpdateEngineRepository \neq UpdateEngine$

第六，Repository 负责持久化。

$Repository=Domain Persistence BoundaryRepository = Domain\ Persistence\ Boundary$

第七，读取必须能够恢复 Domain Object。

$PersistenceData→DomainObjectPersistenceData \rightarrow DomainObject$

第八，保存必须能够验证。

$Save→ReadBack→VerifySave \rightarrow ReadBack \rightarrow Verify$

第九，更新遵守最小更新原则。

$It+ΔI→It+1I_t+\Delta I\rightarrow I_{t+1}$

第十，删除必须保护引用和历史。

$Delete→ReferenceCheck→DeletePolicyDelete \rightarrow ReferenceCheck \rightarrow DeletePolicy$

215.32 本章总结

IndividualRepository 是 ICAI 持久化体系中连接 Individual Domain Object 与 MySQL 的核心边界。

它完成四项基本工作：

$IndividualRepository=Save+Load+Update+Delete\boxed{ IndividualRepository = Save + Load + Update + Delete }$

但真正的工程含义并不是简单 CRUD，而是：

Individual Domain Object
        ↓
Repository Mapping
        ↓
Persistence
        ↓
MySQL

读取时反向恢复：

MySQL
   ↓
Persistence Data
   ↓
Repository
   ↓
Domain Object
   ↓
Individual

更新则遵循：

$It+ΔI→It+1I_t+\Delta I\rightarrow I_{t+1}$

删除则遵循：

$ReferenceCheck→DeletePolicy→Archive/Delete→VerificationReferenceCheck \rightarrow DeletePolicy \rightarrow Archive/Delete \rightarrow Verification$

最终，IndividualRepository 与整个 ICAI 工程体系形成：

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

而在认知闭环中则形成：

$Feedback→Memory→Experience→Learning→Update→Individual→IndividualRepository→MySQL\boxed{ Feedback \rightarrow Memory \rightarrow Experience \rightarrow Learning \rightarrow Update \rightarrow Individual \rightarrow IndividualRepository \rightarrow MySQL }$

因此，IndividualRepository 的本质不是“个体数据库操作类”，而是：

$IndividualRepository=Individual Domain Object↔Persistence Boundary\boxed{ IndividualRepository = Individual\ Domain\ Object \leftrightarrow Persistence\ Boundary }$

它使 ICAI 的 个体对象、认知结构、运行结果、学习更新与持久化数据 能够保持清晰的工程边界，并为后续 Repository Factory、Unit of Work、TransactionManager 以及 Aggregate Repository 体系提供基础。

第215章 IndividualRepository

第215章 IndividualRepository

215.1 IndividualRepository定义

215.2 Individual对象结构

215.3 个体保存

215.3.1 保存的基本含义

215.3.2 个体保存条件

215.4 Individual保存与子对象保存

215.5 个体读取

215.5.1 基本读取

215.6 个体读取不是数据库查询结束

215.7 个体读取的两种模式

215.7.1 基础读取

215.7.2 聚合读取

215.8 个体更新

215.9 个体更新必须遵守最小更新原则

215.10 Individual更新的层次

第一层：Individual基础属性

第二层：Individual当前状态

第三层：Individual组合结构

第四层：Individual关系

215.11 个体删除

215.12 个体删除类型

215.12.1 逻辑删除

215.12.2 归档

215.12.3 物理删除

215.13 个体删除前的引用检查

215.14 IndividualRepository PHP接口

215.15 IndividualMapper

215.16 IndividualRepository基本实现

215.17 聚合读取结构

215.18 个体保存事务

215.19 个体更新事务

215.20 个体删除事务

215.21 IndividualRepository与Service

215.22 IndividualRepository与Engine

215.23 个体保存后的读取验证

215.24 Repository结果模型

215.25 IndividualRepository数据库结构

215.26 个体生命周期

215.27 IndividualRepository与UpdateEngine

215.28 Individual删除与历史保护

215.29 IndividualRepository完整工程关系

215.30 IndividualRepository四项核心能力

一、个体保存

二、个体读取

三、个体更新

四、个体删除

215.31 本章核心原则

215.32 本章总结