Optional是表达业务语义是否必然存在的语言构件：适合查询类且允许无结果的操作；不适合聚合内部方法、必有结果计算及命令型方法；关联属性应显式建模为Optional；Repository中Optional是契约而非妥协。
在领域驱动设计中，Optional 不是泛泛的“防空工具”，而是表达**业务语义是否必然存在**的语言构件。用对了，它让方法签名本身成为统一语言的一部分；用错了，反而掩盖真实业务意图，甚至破坏聚合一致性。
明确 Optional 的语义边界：什么时候该返回，什么时候不该
核心判断标准不是“会不会为 null”，而是“在当前限界上下文中，这个结果是否存在是否属于合法、可预期的业务状态”：
-
适合返回 Optional：查询类操作，且业务上允许查无结果——比如
findById(String id)、findActiveDiscountByProduct(Product)。此时Optional.empty()表达的是“未找到匹配项”，而非异常或错误。 -
不适合返回 Optional：
- 聚合根内部方法（如
Order.addOrderItem(...)）——它要么成功变更状态，要么抛出领域异常（如OrderAlreadyPlacedException），不存在“可能没加成”的中间态； - 必有结果的计算方法（如
Order.getTotalAmount()）——金额在订单有效时必然可算，返回Optional<Money>反而暗示“可能算不出来”，违背模型完整性； - 命令型方法（如
Inventory.decreaseStock(...)）——应返回 void 或领域事件，不暴露底层是否存在库存记录的实现细节。
- 聚合根内部方法（如
嵌套访问链中用 flatMap 而非 map，保持语义扁平
当需要穿透多层关联获取深层属性（如 order.getCustomer().getPreferredAddress().getCity()），必须用 flatMap 链式调用，避免产生 Optional<Optional<String>>：
- 错误示范：
order.getCustomer().map(Customer::getPreferredAddress).map(Address::getCity)→ 返回Optional<Optional<String>>，需二次解包，丢失语义清晰性； - 正确写法：
order.getCustomer().flatMap(Customer::getPreferredAddress).map(Address::getCity)→ 最终是Optional<String>，一层语义：城市信息可能存在，也可能不存在。
注意：领域模型中关联属性本身应声明为 Optional<T>（如 private Optional<Address> preferredAddress;），这是对“该关系非强制存在”的显式建模，不是为了适配 Optional 而加。
Repository 接口设计：Optional 是契约，不是妥协
仓储方法的返回类型是限界上下文对外承诺的关键部分：
-
Optional<Order> findById(OrderId id)—— 明确表示“按 ID 查找订单，找不到是正常情况”； -
Order getById(OrderId id)—— 表示“ID 必然对应一个有效订单”，若不存在应抛出EntityNotFoundException（基础设施层捕获并转换），这适用于聚合根已被确认存在后的内部导航场景； - 批量查询不返回
List<Optional<T>>—— 这混淆语义。应返回List<T>（查到即返回）或Page<T>（分页场景），空列表本身就表达了“无结果”。
避免在领域对象内部滥用 Optional 字段
值对象、实体中的字段是否用 Optional，取决于业务规则本身是否允许缺失：
- 可以：
private Optional<String> middleName;（名字中间名在业务上就是可选的）； - 不可以：
private Optional<OrderId> id;（实体必须有 ID，否则不是合法实体，应在构造时校验并拒绝无效状态）； - 更推荐：对可选属性，用值对象封装其存在性逻辑（如
class MiddleName { private final String value; private MiddleName(String value) { ... } }），比裸Optional<String>更具领域含义。
