DDD中不应通过抽象基类沉淀createTime等审计字段，因其无业务含义；应仅沉淀身份契约（如id()）和内聚验证能力（如validate()）；审计字段由持久化层自动处理；有业务意义的状态复用应采用组合而非继承。
在领域驱动设计（DDD）中，不应当通过抽象基类沉淀通用的领域实体属性，比如 createTime、updateTime、version、status 等字段。
这些字段看似“通用”，但它们在领域模型中没有业务含义，也不参与核心业务规则或状态流转。强行塞进抽象实体基类，会污染领域层，违背 DDD 的分层隔离原则。
真正该沉淀到抽象基类的，只有两类东西：
- 身份契约：所有实体共有的唯一标识机制
- 内聚验证能力：实体自身能回答“我是否合法”
例如：
立即学习“Java免费学习笔记（深入）”；
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 强制提供不可变的
id()方法，返回统一类型（如String或自定义Identity值对象） - 要求子类实现
validate()，用于校验自身状态（如邮箱格式、金额非负、状态迁移合法性） - 构造器中校验 ID 非空，防止无效实体被创建
审计类字段属于基础设施细节，应由持久化层自动处理
-
@CreatedDate（Spring Data JPA）、MyBatis 拦截器、或自定义InsertHandler可在保存时自动填充createTime -
@Version用于乐观锁，由 ORM 在更新时管理，无需领域对象感知 - 这些字段不出现在
Entity类中，就不会出现在领域服务、聚合根方法签名或领域事件里，避免业务逻辑被技术元数据干扰
需要复用有业务意义的状态？用组合，不是继承
如果多个聚合都需要“软删除”或“归档”能力：
- 定义
ArchivalStatus值对象，封装isArchived()、archiveBy(User)、restore()等行为 - 在
Order、Product等聚合根中持有该值对象，而不是从BaseEntity继承一堆字段和 setter
这样既保持领域模型纯粹，又让可复用行为具备明确语义和测试边界。
不复杂但容易忽略。
