ddd中抽象类不应承载通用字段或软删除等行为，因违背领域意图与聚合边界；应改用值对象组合（如archivalstatus）复用业务语义，并由基础设施层处理id、时间戳等持久化细节。
Java 中抽象类不适合直接承载 DDD 基础实体的行为规范，尤其不能靠继承来统一管理通用字段（如 id、createdAt、updatedAt）或“软删除”“归档”等有业务语义的操作。
抽象类不是实体建模的合理载体
DDD 强调实体应以业务身份和生命周期为核心，而非技术共性。把 id、version、isDeleted 等字段塞进抽象基类，会导致：
- 所有子类被迫继承无业务意义的字段，违背“模型表达领域意图”的原则
- 空方法（如
softDelete()）在不支持该行为的聚合中变成哑接口，破坏契约清晰性 - 违反聚合一致性边界——不同聚合对“删除”的定义可能完全不同（如订单不可删、客户可逻辑删）
用组合替代继承来复用有语义的行为
当多个聚合确实需要共享**具备明确业务含义的状态流转逻辑**（例如“归档”“冻结”“审核中”），应将其封装为独立的值对象，而非塞进抽象类：
- 定义
ArchivalStatus值对象，含isArchived()、archiveBy(User)、unarchiveBy(User)等方法 - 在需要归档能力的聚合根（如
Document、Contract）中持有该值对象：private final ArchivalStatus archivalStatus; - 聚合根通过委托调用行为：
public void archive(User operator) { this.archivalStatus.archiveBy(operator); }
基础标识与审计信息应由基础设施层处理
id、createdAt、updatedAt 这类字段属于持久化契约，不属于领域层职责：
-
id应由仓储（Repository）在创建时生成并赋值，实体构造时接收它，不提供 setter - 时间戳由框架（如 JPA 的
@CreatedDate/@LastModifiedDate）或应用服务层注入，实体本身不维护 - 若需领域内感知创建者，应建模为
CreatedBy值对象（含UserId和timestamp），由上层传入构造
真正适合抽象类的场景：模板方法约束流程
抽象类在 DDD 中仍有价值，但仅限于定义**稳定算法骨架 + 可插拔的领域行为钩子**，例如：
- 统一的领域事件发布流程：
saveAndPublishEvents()模板方法，强制子类实现collectDomainEvents() - 状态变更校验骨架：
transitionTo(Status next)封装前置检查、状态更新、后置通知，子类只需重写isValidTransition(Status from, Status to)
这类设计不暴露字段，不强加状态，只约束行为结构，符合开闭原则与领域聚焦原则。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
