那种，那么在操作上一对多的情况下肯定是希望在一次操作就可以完成的。如果这个对象也参与在这个操作中就可能存在这个对象跟一对多的这俩对象
什么是驱动（Driven）？
上面其实已经提到了，就是：1）领域驱动领域模型设计；2）领域模型驱动代码实现。这个就和我们传统的数据库驱动开发的思路形成对比了。
不止于分发
我们都知道以 RocketMQ 为代表的消息（队列）起源于不同应用服务之间的异步解耦通信，与以 Dubbo 为代表的 RPC 类服务通信一同承载了分布式系统（服务）之间的通信场景，
上面这些中心看起来很自然，因为大家对电子商务的这个领域都已经非常熟悉了，所以都没什么疑问，好像很自然的样子。所以，领域划分是不是就是没什么挑战了呢？显然不是。
1 MySQL + 专用AP数据库的搭积木方案
专用分析型数据库产品选项众多，一个可选方案是使用两套系统来分别满足的OLTP和OLAP型需求，在两套系统中间通过数据同步工具等进行数据的实时同步。
用户可以选择通过DDL将一张表的全部列或者部分列创建为列索引，列索引采用列压缩存储，其存储空间消耗会远小于行存格式。默认列索引会全部常驻内存以实现最大化分析性能，但是当内存不够时也支持将其持久化到共享存储上。
第二部分，会介绍一致性难题的通用解法以及各种方案间的取舍；第三部分，会介绍主流的流计算引擎是如何对通用解法进行泛化以实现一致性。
然而在实际使用过程中，许多人对可观测性的关注，主要集中在系统上线之后。这当然是没有问题的，但实际上，从一个系统开发开始，一直到线上运行，都是可以从可观测的角度来对系统的质量进行评估和衡量，我们可以称之为对质量的观测。
而仅指引擎内部的状态，譬如各个算子的状态、实时流的消费偏移等，流计算引擎内部状态变更的保证，并不能等价于从输入到输出的一致性，端到端一致性需要你自己关心。
从而段时间内有大量的告警触发，以及大量的告警消息通知。缺乏合理的降噪机制。
通知管理能力弱：许多告警管理系统只是简单地将告警消息发送出去，存在着通知渠道不完善、通知内容不符合用户需求、无法支持值班需求等等问题。
