Java 17密封类将DDD中“有限子类型”从文档约定升级为编译期强制契约，通过permits列表、模块约束和switch穷尽检查确保领域模型不被非法扩展。
Java 17 密封类不是“限制继承的语法糖”，而是让 DDD 中的“有限子类型”从文档约定变成编译期强制契约。只要 permits 列表完整、子类修饰符合规、模块导出正确，编译器就能保证你定义的领域模型不会被意外扩展。
为什么 Shape 不该是普通 abstract class？
在金融账户、订单状态、支付方式等 DDD 场景中，你希望明确知道所有合法子类型——比如 Account 只能是 SavingsAccount、CheckingAccount 或 CreditAccount。用传统 abstract class 声明，任何包里都能写 class FakeAccount extends Account，运行时才暴露问题；而密封类让这种非法继承在 javac 阶段就报错：
error: class FakeAccount is not allowed to extend sealed class Account- IDE 实时高亮、自动补全只显示
permits中的类 - 配合 Lombok 的
@Sealed（非官方）或 MapStruct 等工具时，生成逻辑也只覆盖已知子类
permits 列表必须与子类在同一个模块（或默认模块）
这是最容易被忽略的部署约束。即使你写了 public sealed class Account permits SavingsAccount, CheckingAccount，如果 SavingsAccount 在另一个未声明 opens 或 exports 的模块中，编译直接失败：
- 错误信息形如：
error: subclass SavingsAccount is in module 'bank-core' but sealed class Account is in module 'bank-api' - 解决方法：要么把所有相关类放在同一模块（推荐用于内聚领域层），要么在
module-info.java中显式导出包并允许跨模块继承（不推荐，破坏封装边界） - 无模块项目（默认模块）下，只要在同一个源路径（如
src/main/java）即可，但需确保子类文件存在且已编译
non-sealed 子类 ≠ 完全开放，它只是“解封点”
你可能想让 CheckingAccount 支持定制化子类（如 BusinessCheckingAccount），于是标记为 non-sealed。但要注意：
-
non-sealed不解除模块限制：子类仍需与CheckingAccount同模块 - 反射动态生成子类（如 Mockito mock、CGLIB 代理）会触发
VerifyError，因为 JVM 类验证器检查密封链完整性 - 它不传递“解封”效果：若
CheckingAccount是non-sealed，但它的父类Account是sealed，则BusinessCheckingAccount继承的是CheckingAccount，而非绕过Account—— 这是设计意图，不是 bug
搭配 switch 表达式实现穷尽性检查
这才是密封类在 DDD 中最实在的价值：把“漏处理某种状态”的风险提前到编译期。例如处理账户状态迁移：
return switch (account) {
case SavingsAccount s -> s.calculateInterest();
case CheckingAccount c -> c.applyOverdraftFee();
case CreditAccount c -> c.calculateCreditLimit();
// 编译器强制要求覆盖全部 permits 列表，否则报错
};
如果后续新增 InvestmentAccount 但忘了加进 permits 和 switch 分支，编译直接失败。这比靠单元测试覆盖率或 Code Review 更可靠。
真正难的是维护 permits 列表与实际子类的一致性——删了一个子类却忘了更新 permits，或者重构包路径后子类没同步移动，都会导致编译中断。把它当成和接口方法签名一样严肃的契约来对待。
