在领域驱动设计（DDD）实践中，如何确保业务规则在代码中得到精确、无歧义的表达，而非散落于文档或依赖口头沟通？一个高效的策略是将“有限、封闭、不可变”的核心业务概念，直接映射至编程语言的类型系统。Ja va 的密封类（Sealed Class）特性，为此提供了一套优雅的解决方案——它让编译器成为业务边界与规则的天然守护者。
利用密封类体系构建DDD代数数据类型（ADT），其核心在于：通过
sealed interface定义领域契约，使用record实现不可变的具体变体，并借助switch表达式强制穷尽处理。这套组合拳使得业务概念的“有限性、封闭性、不可变性”由编译器在编译期保障，从而在跨上下文协作时自动形成坚固的防腐层。
使用 sealed interface 精准定义领域契约
首要步骤是为核心领域概念划定清晰的边界。选择sealed interface而非抽象类，在语义上更为精准：接口的核心职责是声明契约，它不承载具体行为实现，而是明确宣告——“此业务概念，有且仅有以下几种合法形态”。
以电商领域经典的“订单状态”建模为例，其定义方式清晰直观：
- 声明领域契约：
public sealed interface OrderStatus permits Placed, Confirmed, Shipped, Cancelled {} - 保障封闭性：所有被
permits子句允许的实现类，必须在同一模块内可见（在默认模块下，通常建议置于同一包或文件中集中管理）。 - 编译时强制约束：
permits子句是强制声明的，若省略，编译器将直接报错。这从根源上杜绝了“遗漏声明新状态”的可能性，确保了领域模型的完整性。
使用 record 实现具体且不可变的业务变体
定义好契约后，需填充具体的业务事实。每个被允许的状态变体，都对应业务流转中的一个确定节点，天然适合用record来实现。
record关键字带来的优势显著：
- 精准业务建模：例如，
public record Placed(Instant placedAt, String orderRef) implements OrderStatus {}。这条记录清晰地表明，“已下单”状态必须包含“下单时间”和“订单号”这两个不可变的核心事实。 - 消除样板代码：
record自动提供了基于所有组件的构造器、equals()、hashCode()和toString()方法，开发者无需手动编写这些重复性代码，提升开发效率。 - 强化不可变语义：虽然
record默认是final的，但显式添加final关键字（如public final record ...）能使代码的“不可变”设计意图更加明确，增强可读性与团队共识。
利用 switch 表达式强制穷尽状态处理
当需要根据状态执行业务逻辑时，传统的instanceof检查和if-else链不仅冗长，且极易遗漏分支。密封类体系与现代switch表达式的结合，彻底解决了这一问题。
- 编译器驱动的类型安全：写法如
return switch (status) { case Placed p -> “已下单”; case Confirmed c -> “已确认”; ... };。编译器会强制检查此switch是否覆盖了OrderStatus所有被允许的实现类。 - 零容忍状态遗漏：只要漏掉任何一个变体，编译就会失败。同样，如果某个实现类未被声明为
final，编译器也会报错，因为它破坏了类型的“封闭性”。 - 摒弃模糊的默认分支：一个关键最佳实践是——禁止使用
default分支。这迫使开发者在业务状态演进时，必须显式地思考和处理每一个新增或修改的状态，避免用一个笼统的default掩盖认知盲区，从而提升代码的健壮性。
跨限界上下文协作时自动形成防腐层
在微服务或模块化架构中，领域概念常需跨边界传递，此时防腐层（Anti-Corruption Layer, ACL）的设计至关重要。密封类体系在此场景下展现出独特优势。
假设订单上下文需要将OrderStatus传递给下游的物流上下文：
- 提供稳定接口：物流服务只需依赖
OrderStatus接口类型，无需知晓也无法依赖具体的实现类名，有效降低了模块间的耦合度。 - 强制显式业务处理：物流服务在使用
switch处理状态时，必须显式列出并处理Shipped等所有已知状态，无法以“兼容未来未知类型”为借口忽略当前必要的业务逻辑。 - 保障状态不可变性：基于
record的状态变体在跨上下文传递过程中是不可变的，有效防止了数据在传输时被意外篡改的风险。 - 编译时边界守卫：如果其他模块（如下游的物流模块）试图私自定义一个
class FraudState implements OrderStatus，编译器会直接拦截，因为OrderStatus是密封的，不允许在permits列表之外进行实现。这从机制上防止了领域概念的腐化与边界突破，是编译时保障的天然防腐层。
综上所述，将密封类、记录类和模式匹配结合使用，远不止是应用新的语法特性。它代表了一种设计范式的转变，使类型系统从被动的“数据容器”，升级为主动的“业务规则执行者”。通过编译器的强制约束，那些原本容易在代码评审和集成测试中遗漏的业务规则漏洞，在编码阶段就被提前封堵。这使得系统的核心领域模型更加健壮、可信，并显著提升了代码的表达力与可维护性，是实践领域驱动设计与构建高质量Java应用的利器。
