业务组件聚类靠数据生成职责唯一性任务描述里的规则让它不是贫血模型

把行为（任务）和数据（实体）结合成业务组件时，聚类不是随便 按”相关”就能归拢的，作者给出了两条决定组件边界的关键规则。 第一条是数据生成职责唯一性：如果A主题域引用了B主题域的数据 实体，对A主题域做任务聚类时，不会把B主题域中被引用数据实体 相关的任务也聚类进A——那些任务应该由B主题域在做自己的聚类时 去考虑，这样才能保证在企业级系统里，每份数据只有唯一一个组件 真正拥有”生成”它的职责，不会出现多个组件都能写同一份数据、 互相打架的情况。第二条与之呼应：对同一个数据实体做新增、修改、 删除操作的任务，都应该归属到同一个组件里，只有这个组件对该 数据实体拥有写权限，其他所有引用了这个数据实体的组件都只能有 读权限——这也是保证企业级数据一致性的重要措施（如果确实需要 建立主副本，主本数据的设计方是主要负责方，副本设计方必须考虑 如何与主本保持一致）。这套按数据写权限唯一性聚类的方式，表面 上看很容易被误认成”贫血模型”——毕竟组件内任务和实体的关联 主要体现为对实体的增删改操作，这正是贫血模型最典型的症状 （数据和行为分离，实体本身没有业务逻辑）。但作者澄清这不是 贫血模型：流程对数据更丰富的处理规则（校验逻辑、业务约束、 计算规则等）都被包含在任务本身的描述里，只是没有像面向对象 设计那样把这些规则直接绑定到实体对象上而已——聚类的依据是 “谁对这份数据拥有唯一写权限”，而不是”这份数据本身有没有携带 行为”，这是两个不同维度的问题。

结构图：

flowchart TB
    A[主题域A] -.引用.-> B[主题域B的数据实体]
    A2[A主题域任务聚类] -->|不聚类B的写操作任务| A
    B2[B主题域任务聚类] -->|B数据实体的增/删/改任务归此| B
    C[数据实体X] --> W[唯一写权限组件]
    C --> R1[组件1 只读]
    C --> R2[组件2 只读]
    W -->|处理规则藏在任务描述里| N[非贫血 只是规则不绑在实体对象上]