这样的一个队列模型就可以同时支持服务端和终端场景的接入和消息收发，达到一体化的目标。
推拉模型
介绍了底层的队列存储模型后，我们再详细描述一下匹配查找和可靠触达是怎么做的。
不同的业务需求都不一样，又比如 Bridge 扩展，其能够把终端设备状态和消息数据与一些外部生态系统（产品）打通。
交付设计
好的架构设计还是要考虑最终的落地问题，即怎么交付。如今面临的现状是公共云、专有云，
如果基于现有的 RocketMQ 的 Topic 重管理逻辑显然有些困难。我们定义了一种轻量的 Topic，专门支持终端这种场景，不需要注册 namesrv 进行管理，由上层协议逻辑层进行自管理，broker 只负责存储。
这个思路，和传统的分析、设计、编码这几个阶段被割裂（并且每个阶段的产物也不同）的软件开发方法学形成鲜明的对比。
领域建模的目标针对我们在领域中所关心的问题，即只针对核心关注点，而不是整个领域中的所有问题；
领域模型在设计时应考虑一定的抽象性、通用性，以及复用价值；
。如果你不了解，就算你领域建模的能力再强，各种技术架构能力再强也是使不上力。领域专家不是某个固定的角色，而是某一类人，这类人对这个领域非常了解。
还是拿经典的电商系统来分析，通常一个电商系统都会包含好几个大块，比如：
会员中心：负责用户账号登录、用户信息的管理；
商品中心：负责商品的展示、导航、维护；
不过并不是所有的系统都需要划分子域的，有些系统只是解决一个小问题，这个问题不复杂，可能只有一两个核心概念。所以，这种系统完全不需要再划分子域。
我们可以使用这些工具，来设计每一个子域的领域模型。最终通过领域模型图将设计沉淀下来。要使用这些工具，首先就要理解每个工具的含义和使用场景。
这个步骤最核心的就是找出聚合根，并找出每个聚合根包含的信息；关于如何设计聚合，可以看一下我写的这篇文章；
画出领域模型图，圈出每个模型中的聚合边界；
