向输入端口传递ETag：用领域对象还是字符串？哪个更优？

推荐方案：优先使用ETag值对象传递 #

在绝大多数业务场景下，将ETag作为值对象（Value Object）传入输入端口是更优的选择，仅在极端轻量化、无校验需求且ETag使用频率极低的场景下，才考虑用字符串传递。

决策时的核心考量因素 #

• 语义与可读性：值对象ETag能直接传达“这是一个HTTP ETag标识”的语义，相比模糊的字符串参数，代码可读性大幅提升，其他开发者一眼就能理解参数的含义和用途，避免与其他字符串类型的参数（如文档ID、哈希值）混淆。
• 类型安全与错误预防：值对象可以在构造阶段就完成格式校验（比如验证是否符合RFC 7232定义的ETag格式，区分强ETag和弱ETag），确保只有合法的ETag才能被创建。而字符串传递的话，你需要在每个接收方法中重复校验，不仅冗余，还容易遗漏校验逻辑，导致无效值流入业务流程。
• 复杂度与维护成本：虽然值对象需要额外定义一个类，但这个成本是一次性的。后续所有使用ETag的地方都能直接复用校验和行为逻辑，反而降低了长期维护成本。如果用字符串，每次使用都要处理校验、格式转换，反而会累积技术债务。
• 扩展性：如果未来业务需要扩展ETag的特性（比如存储弱ETag的标识、添加ETag生成逻辑），值对象可以轻松添加字段或方法，而字符串则需要修改所有传入、处理ETag的代码，重构成本极高。

遵循的设计原则与最佳实践 #

1. DDD值对象封装原则：既然ETag是值对象，就应该把它的所有行为（校验、格式转换、强弱判断等）封装在对象内部，领域层的输入端口（如getDocument(ETag eTag)）直接接受值对象，保持领域逻辑的内聚性。
2. 输入端口的边界隔离：输入端口作为领域层与外部（如API层、应用层）的边界，应该用领域对象来约束输入，避免原始字符串直接进入领域逻辑，减少外部变化对领域层的影响。
3. 单一职责原则：让值对象负责ETag的有效性校验和自身行为，业务方法专注于文档查询等核心业务逻辑，职责分离更清晰。

实体/聚合的分层定位 #

实体（Entities）和聚合（Aggregates）必须放在领域层，这是DDD的核心准则：

• 领域层是业务规则的核心载体，实体和聚合根封装了业务的核心状态和行为，比如文档实体的属性、状态变更规则等。
• 应用层的职责是编排领域对象的调用、处理用例流程（比如接收API请求、调用领域服务、返回结果），不应该包含核心业务逻辑，也不应该定义实体或聚合。

内容的提问来源于stack exchange，提问作者Jordi