微服务和反应式模型虽然很强大，但也带来了不确定性。开发人员总是对消息驱动的系统持有疑问：
- 有人接收到我发出的消息了吗？
- 他们对消息做出回应了吗？
- 消息的顺序会不会被打乱了？
Vaughn Vernon 在 DDD 探索大会的演讲中提到，DDD 是回答上述问题的基础。使用通用语言（ Ubiquitous Language ）来描述由边界上下文（ Bounded Context ）组成的系统可以降低分布式系统的复杂度。不确定性应该成为通用语言的一部分，比如边界上下文之间的交互问题。
Vernon 是“ Implement Domain Driven Design ”和“ Reactive Messaging Patterns with the Actor Model ”的作者，他认为为项目创建好上下文映射是至关重要的。从实际情况来看，业务的核心领域总会包含多个边界上下文，而上下文映射体现了边界上下文之间的关系。在建立上下文映射关系时，要专注在团队之间的关系上，而不是去关注技术细节，比如究竟是使用 REST 还是使用 RPC。Vernon 说，“集成对象比如何集成更加重要”。
Vernon 看到了反应式系统的发展趋势，反应式行为存在于微服务之中，同时又超越了微服务。这并非什么新概念，他说， Eric Evans 早就在业界推广事件模式。其核心思想就是对过去发生的事件作出反应，进而达到和谐的状态。
微服务和反应式行为带来了不确定性，包括事件顺序的不确定性和事件的重复性问题。Vernon 强调说，“就算你使用的是 Kafka，认为自己是在按顺序消费消息，但其实是在自欺欺人。如果任何一个消息可能出现乱序，那么所有消息都有可能出现乱序，你要为之做好应对准备”。
Vernon 认为这种不确定性是很难得到消除的，因为我们已经习惯于阻塞调用、数据库锁等事物，并总是期待事物是按照一定顺序进行的。在反应式系统里，一些长久以来的信念开始土崩瓦解。或许，开发者会本能地创建出门面（facade）来隐藏不确定性，写出传统的非反应式代码，但 Vernon 认为我们应该要反其道而行之。
Vernon 总结了自己处理不确定性的方式——“更少的查询，更多的事件”。事件告诉我们在过去某个时刻发生了什么。我们不知道系统现在处于什么状态，只知道事件发生时的状态以及在这一过程中发生了哪些变化。如何对这些事件作出反应式属于业务决策，包括如何处理乱序问题。Vernon 引用了 Pat Helland 的论文“ Life Beyond Distributed Transactions ”：“在一个不能依赖分布式事务的系统里，必须在业务层面管理不确定性”。
Vernon 列举了几中不同形式的不确定性，并提供了用于管理不确定性的简短代码。他强调这些代码只是业务决策的实现。业务必须拥抱不确定性，必须让业务决策者来对其进行建模，而不是在软件开发团队内部完成这件事情。不要通过创建门面来隐藏不确定性，而是尽你所能对不确定性进行建模。
查看英文原文： Vaughn Vernon Uses Reactive DDD to Model Uncertainty in Microservices
评论