大多数编程语言中 if 语句主要有两个作用：验证输入以保护领域免受错误数据的影响，以及处理领域内业务逻辑。但是， Udi Dahan 最近在阿姆斯特丹 DDD 欧洲会议上的发言中指出，我们一般很少从业务或领域角度管理使用 if 语句处理逻辑的风险。
我们在线购物时会浏览不同的商品，并仔细阅读其中一些商品的详细信息。当找到想要购买的商品并将其添加到购物车中时，我们也从交互的查询功能转移到命令功能。对任何类型的命令，Dahan 认为我们应该问的重要问题之一是，什么因素会导致该命令失效。他还强调了我们必须区分技术失效（例如网络服务器崩溃或者反序列化错误，这应该由基础架构解决）和逻辑失效（比如将已经从产品目录中删除的商品添加到购物篮）。
Dahan 与客户合作的一个常见案例就是检查是否有项目被删除。对他来说，处理已删除项目这类问题的一个步骤是区分私有数据和公共数据，并与内容管理系统进行比较。在内容管理系统中，你可以编辑页面和内容，最后通过按“发布”键公开信息。在处理私有数据方面，用户可以随意添加、更新或删除项目，直到最后满意了再公开。
在处理公共数据方面，我们应该更多地用业务逻辑来替换删除和检查删除，应该更仔细地斟酌为什么要删除某个项目。以某个不再出售的产品为例，或许更好的方法是创建一个特定的命令，将该产品标记为不出售，而不是使用某种形式的暂时或真正的删除。
这种解决方案的潜在问题是竟态条件（race condition）。即顾客将商品添加到购物篮后该商品被标记为不出售，之后当客户想要结账时已经无法购买这项商品了。对于 Dahan 来说，以这种方式看待问题的视角是非常狭窄的、以数据为中心且局限于某个时间点。相反地，他将这个问题描述为多个参与者同时在同一个对象上操作的典型场景。
对于在协作领域多个参与者同时对相同的数据进行操作的情况，Dahan 认为我们应该开始考虑使用 CQRS。当 CQRS 应用于领域时，他建议使其尽可能简单化，并设计好解决方案，以保证经过验证后应用于领域逻辑的命令几乎不会失效。这意味着在处理命令时，我们必须准备好在竞态条件下失败却仍然可以满足整体业务目标。通常这从商业角度来说能达到最终的一致性，但不是技术上的一致性（如读取模型最终与写入模型同步）。举例来说就是客户把某个不出售的商品添加到购物篮中。
这个问题的一个解决方案是使用幕后长期运行过程，当用户不再操作购物篮或者超时时，从购物篮移除已停止销售的商品。最终，该商品被从所有购物篮中移除，因此不再销售。
当我们查看系统时可能会发现许多以某种形式检查状态的if 语句，对于每一个if 语句，我们都应该搞清楚是否有其他参与者可能改变该if 语句所检查的状态。这样我们可以找到潜在的协作情形和对长期运行过程的需求。不过Dahan 指出，我们要注意不要使用太多的长期运行过程，它并不是万能的。
查看英文原文： The Dangers of If Statements in Domain Logic
感谢王纯超对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。
评论