密封类在DDD中通过编译期限定子类型、支撑模式匹配穷举、强化限界上下文隔离、协同record构建安全领域载体，实现边界可验证、不可绕过、内聚可控。
密封类在大型业务领域驱动设计中控制边界的优势，核心在于它把“哪些类型可以存在”这件事从运行时搬到了编译期，让领域边界的约束可验证、可穷举、不可绕过。
明确限定合法子类型，杜绝非法扩展
在复杂业务系统中，一个领域抽象（比如 PaymentMethod、OrderStatus 或 ShipmentType）往往只有有限且确定的几种实现。密封类通过 permits 显式列出所有允许的子类，强制开发者在定义时就确认完整集合。
- 编译器会拒绝任何未在 permits 中声明的子类，哪怕只是拼写错误或遗漏
- 团队新人无法凭直觉新增一个 CryptoPayment 而不被发现，除非它被显式加入许可列表
- 相比传统抽象类+文档约定的方式，这种约束不是靠人遵守，而是靠语言机制兜底
支撑模式匹配的完整性检查，消除逻辑盲区
当领域行为需要按类型分支处理（如计算运费、生成发票、触发风控），密封类配合 switch 表达式或 instanceof 模式匹配，能让编译器判断是否覆盖全部可能。
- Java 编译器能提示 “missing case for Triangle” —— 不再依赖人工 review 或测试覆盖来发现漏判
- 在状态机建模（如订单生命周期）中，每个 OrderEvent 的响应逻辑可与密封枚举一一对应，避免新增状态后忘记更新处理逻辑
- 这种穷尽性保障，在微服务间协议变更、事件结构演化时尤为关键
强化限界上下文的内聚性与隔离性
DDD 强调限界上下文（Bounded Context）是模型的语义边界。密封类天然适配这一思想：它让一个上下文内的核心抽象成为“封闭宇宙”，外部无法注入新变体破坏上下文一致性。
- 例如 shipping.ShipmentType 是订单上下文内部的密封接口，而物流上下文另有自己的 logistics.ShipmentType —— 两者不能混用，也不会因继承关系意外耦合
- 当跨上下文集成时，数据需经防腐层（ACL）转换，密封类的存在反而凸显了这种转换的必要性
- 模块化构建中，密封类可配合模块系统（如 Java Platform Module System），进一步限制跨模块继承
与 Records 协同，构建轻量、安全、可组合的领域载体
密封类常与 record 联用：父类定义行为契约，子类用 record 承载不可变数据。这种组合既保持类型安全，又避免冗余代码。
- public sealed interface Discount permits PercentageDiscount, FixedAmountDiscount {}
- public record PercentageDiscount(double rate) implements Discount {}
- 字段自动不可变 + 类型封闭 + 解构友好 → 领域对象即文档，即契约，即实现
