如何在 Java 中利用 密封类体系 构建领域驱动设计（DDD）中的代数数据类型（ADT）

在领域驱动设计中，如何让代码精确地表达业务规则，而不是让规则散落在文档和开发者的记忆里？一个有效的策略，是将“有限、封闭、不可变”的核心业务概念，直接映射到编程语言的类型系统中。Ja va的密封类（Sealed Class）体系，恰好为此提供了一套优雅的解决方案——它让编译器成为你业务边界的守护者。

用密封类体系构建DDD代数数据类型，核心是通过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列表之外进行实现。这从机制上防止了领域概念的腐化和边界被突破。

总而言之，将密封类、记录类和模式匹配结合使用，不仅仅是应用一项新的语法特性。它更是一种设计范式的转变，让类型系统从被动的“数据容器”，转变为主动的“业务规则执行者”。通过编译器的强制约束，那些原本容易在代码评审和测试中遗漏的业务规则漏洞，在编码阶段就被提前封堵，使得系统的核心领域模型更加健壮和可信。