Model（领域对象）：领域对象是我们正常业务应该用的领域业务模型，它的字段和方法应该和业务语言保持一致，不需要进行持久化和序列化，他主要存在与内存中。也就是说，所以 Model 和 DO 可能字段属性都不一样。
主要的原因就是为了隔离接口数据变化，防止外在服务的数据变化影响应用层的代码，如果真的需要修改那么直接在防腐层中进行修改就好了。
按照我自己的习惯，笔者是按照互粉的领域来进行包构建的，比如这里的 user 以及 authority 就是不同的领域。为什么这么划分呢？主要考虑到未来万一有新的拆分，我们可以直接按照对应的域进行拆分
我们都知道以 RocketMQ 为代表的消息（队列）起源于不同应用服务之间的异步解耦通信，与以 Dubbo 为代表的 RPC 类服务通信一同承载了分布式系统（服务）之间的通信场景，所以服务间的消息分发是消息的基础诉求。
特性分析
尽管无论是终端消息还是服务端消息，其本质都是消息的发送和接受，但是终端场景还是有和服务端不太一样的特点，下面简要分析一下：
在 RocketMQ 里面实际上有这个类似的匹配过程，其通过将某个 Queue 通过 rebalance 方式分配到消费组内某台机器上，消息通过 Queue 就直接对应上了消费机器
另外，终端消息有一个很重要的区别是可靠性保证的 ACK 必须是具体到一个终端设备的，而服务端消息的可靠性在于只要有一台消费者机器成功处理即可，不太关心是哪台消费者机器
但是有一个地方我们使用了写放大模式，就是通配符匹配，因为接受者订阅的是通配符和消息的 Topic 不是一样的内容，接受者读消息时没法反推出消息的 Topic，
集中存储在线订阅关系，这个也是常见的一种做法，如保存到 Rds、Redis 等，但要保证数据的实时一致性也有难度，而且要进行匹配查找对整个消息的实时链路 RT 开销也会有一定的影响。
如上图所示，一般一个分布式 KV 读写流程是，Key 通过 hash 得到一个逻辑 slot，slot 通过一个映射表得到具体的 node。Hash 算法一般是固定模数，映射表一般是集中式配置或使用一致性协议来配置。节点扩缩一般通过调整映射表来实现。
