如何利用 JDK 17 的密封类（Sealed Classes）构建领域驱动设计中的受限继承体系

“纵有疾风来，人生不言弃”，这句话送给正在学习文章的朋友们，也希望在阅读本文《如何利用 JDK 17 的密封类（Sealed Classes）构建领域驱动设计中的受限继承体系》后，能够真的帮助到大家。我也会在后续的文章中，陆续更新文章相关的技术文章，有好的建议欢迎大家在评论留言，非常感谢！

Java 17密封类是编译期强制的继承契约，要求显式声明permits、子类必须存在且用final/sealed/non-sealed修饰，配合switch实现穷尽性检查，提升领域建模安全性与一致性。

Java 17 的密封类不是“增强版 final”，而是编译期强制的继承契约——它能让你在领域模型中真正表达“只有这几种状态/类型是合法的”，而不是靠文档或约定去约束。

密封类必须显式声明 permits，且子类必须标注继承策略

Java 17 不允许省略 permits（Java 21+ 才支持自动推导），漏写、拼错子类名、或子类不在同一模块/包中，都会直接编译失败。这不是运行时检查，是硬性语法要求。

• permits 后列出的每个子类必须真实存在，且不能是嵌套类（除非是静态嵌套）
• 每个子类必须用 final、sealed 或 non-sealed 显式修饰，缺一不可
• 若子类是 sealed，它自己也必须带 permits，形成可延续的限制链

领域建模时，优先用 final 子类封住具体实现分支

在 DDD 中，像 PendingStatus、ShippedStatus 这类具象状态，通常不应再被继承——它们代表一个确定的业务语义，扩展只会引入歧义。

• 用 final 是最安全选择，避免下游误覆写行为逻辑
• 抽象方法（如 canTransitionTo(Status next)）应在密封父类中定义，由各 final 子类各自实现具体规则
• 不要为了“看起来统一”而把所有子类都设为 sealed；如果某分支确实不需要继续细分，final 更清晰

non-sealed 不是后门，而是有明确开放意图的设计信号

比如订单领域中，OrderStatus 密封类允许 RefundedStatus 和 CancelledStatus，但其中 RefundedStatus 可能需支持不同退款渠道（AlipayRefund、WechatRefund）——这时把它标为 non-sealed，就等于说：“这个状态分支允许业务方按需扩展，但仅限于本上下文内”。

• non-sealed 子类仍受密封父类保护：外部包无法直接继承 OrderStatus，只能继承你放开的那一个分支
• 它不破坏整体密封性，只是局部解耦；编译器仍能对其他 final/sealed 分支做穷尽检查
• 滥用 non-sealed（例如给所有子类都放开）会让密封机制形同虚设

和模式匹配配合时，switch 才真正“安全”

密封类的价值在 switch 表达式里才完全释放：编译器知道所有可能子类型，能校验是否覆盖全部 permits 列表。

• 写 switch (status) { case PendingStatus p -> ... }，漏掉任一 permits 子类，编译报错
• 不需要加 default 分支（除非你主动加了，但会失去穷尽性保障）
• 若后续新增子类，所有相关 switch 必须同步更新，否则编译不过——这是强一致性保障，不是靠人肉 review

真正难的不是写对语法，而是判断哪些类该密封、哪些子类该 final、哪些又该 non-sealed；这取决于你对领域边界的理解深度——错把应封闭的分支放开，或把需灵活的分支锁死，都会让模型僵化或失控。

本篇关于《如何利用 JDK 17 的密封类（Sealed Classes）构建领域驱动设计中的受限继承体系》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！