4.3 组合实体模式

组合实体模式（Composite Entity）用一个粗粒度的实体对象，统一管理一组相互依赖的细粒度对象（一张“对象图”）。它诞生于 EJB 时代：当时每个细粒度对象都可能是一个独立的实体 Bean，逐个远程访问代价极高。组合实体把它们打包，让客户端用一次粗粒度调用就能操作整张图。

下面的实验：Customer 组合实体管理着 Address 和一组 Order，调整字段后一次 persist()，整张对象图作为整体保存。

粗粒度 vs 细粒度

核心权衡是远程调用的次数：

• 细粒度：每个依赖对象都独立访问/持久化，加载一个客户可能要好几次远程往返。

• 粗粒度（组合实体）：客户、地址、订单作为一个单元，一次调用搞定。

下面的对照器让你切换两种粒度，直观看到加载整张对象图所需的远程调用次数差异。

角色拆解

经典组合实体常包含几个角色：

• 组合实体（Composite Entity）：粗粒度的主对象，对外的唯一入口。

• 依赖对象（Dependent Objects）：被它管理的细粒度对象，不单独对外暴露。

• 策略（Strategies）：可选，用来定制实体的持久化/加载方式。

客户端只看见组合实体，依赖对象的生命周期由它统一掌管——这既减少了远程调用，也隐藏了内部结构。

现实回声

纯正的 EJB 实体 Bean 已成历史，但“用粗粒度边界包住一组紧密相关的对象”这一思想，在今天依然处处可见：

• DDD 的聚合根（Aggregate Root）：聚合根是唯一入口，统一管理聚合内对象的一致性边界——与组合实体如出一辙。

• GraphQL 的一次查询取回对象图：避免前端为关联数据发起 N 次请求。

理解组合实体，能帮你看懂这些现代设计背后“减少往返、统一边界”的共同动机。