大部分核心的业务逻辑需要下沉到 domain 层中。实际一开始进行这种方式的开发的时候非常的不习惯，但是当你实际沉下心来做的时候会发现
实现一体化前我们先从理论上分析一下问题和可行性。我们知道，无论是终端消息还是服务端消息，其实就是一种通信方式，从通信的层面看要解决的基础问题简单总结就是：协议、匹配、触达。
上图中还有一个 Cache 模块用于做消息队列 cache，因为在大广播比场景下如果为每个终端设备都去发起队列 Pull 请求则对 broker 读压力较大，既然每个请求都去读取相同的 Topic 队列，则可以复用本地队列 cache。
上图描述的接受我们的队列存储模型，消息可以来自各个接入场景（如服务端的 MQ/AMQP，客户端的 MQTT），但只会写一份存到 commitlog 里面，
所以在队列数量上可以达到十万级。然而这终端设备队列场景下，十万级的队列数量还是太小了，我们希望进一步提升一个数量级，达到百万级队列数量，我们引入了 Rocksdb 引擎来进行 CQ 索引分发。
从领域和代码实现的角度来理解，领域模型绑定了领域和代码实现，确保了最终的代码实现就一定是解决了领域中的核心问题的。因为：1）领域驱动领域模型设计；2）领域模型驱动代码实现。
对领域内的各种业务场景和各种业务规则也非常清楚，总之，对这个领域内的一切业务相关的知识都非常了解。所以，他们自然就有能力表达出系统该做成什么样子。
把他的产品充分设计好，从各个方面去考虑，如何设计一个产品，才能更好的解决用户的核心诉求，即领域内的核心问题。如果对领域不够了解，如果想不清楚用户到底要什么，如果思考问题不够全面，谈何设计出一个合理的产品呢？
领域建模的方法
通过上面我介绍的细化子域的内容，现在再来谈该如何领域建模，我觉得就方便很多了。我的主要方法是：
随着互联网而兴起的新兴数据库产品很多都兼容了MySQL协议，因此成为替代MySQL的一个可选项。而这些分布式数据库产品大部分采用了分布式Share Nothing的方案
