biz 层：其实就是 application 层，但是我更愿意叫 biz 层，因为这层的作用实际就是进行服务组合以及服务调度的，实际它是基于下层的领域服务去完成业务逻辑流程的，因此我觉得叫 biz 层更加贴切一点。
domain 层：这是整个微服务的核心层，主要包含了领域模型、领域服务以及核心的业务逻辑。领域模型主要包括了聚合中的聚合根、实体以及值对象，领域事件也会放在这一层中。
instructure 层：基础设施层主要包含了各种通用能力以及工具类，它的作用就是为上层提供基础服务的，如数据库服务、MQ 服务以及缓存服务等还有其他的一些配置以及资源。
代码归位
1、interfaces 层
（1）assemble 主要负责实现 vo 与 dto 之间的数据转换工作。
（2）vo 存放需要呈现在页面的视图数据对象。
（3）facade 主要实现本层的接口封装。
（1）dto 中主要放了数据传输对象，biz 层接口的入参以及返回值都是 dto。
（2）service 就是 biz 的接口以及接口实现，主要的作用就是实现对于领域服务的编排以及组合，从而完成具体的业务流程。
按照我自己的习惯，笔者是按照互粉的领域来进行包构建的，比如这里的 user 以及 authority 就是不同的领域。为什么这么划分呢？
在 RocketMQ 里面实际上有这个类似的匹配过程，其通过将某个 Queue 通过 rebalance 方式分配到消费组内某台机器上，消息通过 Queue 就直接对应上了消费机器，再通过订阅过滤（Tag 或 SQL）进行精准匹配消费者。
而在终端场景下，一条消息必须明确指定某个接受者（设备），必须准确找到所有接受者，而且终端设备一般只会连到某个后端服务节点即单连接，和消息产生的节点不是同一个，必须有个较复杂的匹配查找目标的过程，还有如 MQTT 通配符这种更灵活的匹配特性。
触达即通过匹配查找后找到所有的接受者目标，需要将消息以某种可靠方式发给接受者。常见的触发方式有两种：Push、Pull。Push，即服务端主动推送消息给终端设备，主动权在服务端侧，终端设备通过 ACK 来反馈消息是否成功收到或
场景介绍
近些年，我们看到随着智能家居、工业互联而兴起的面向 IoT 设备类的消息正在呈**式增长，而已经发展十余年的移动互联网的手机 APP 端消息仍然是数量级庞大。面向终端设备的消息数量级比传统服务端的消息要大很多量级，并仍然在快速增长。
