那么可能就不需要使用 K8s 来编排容器应用了，毕竟 K8s 是源自 Google 的 Borg，他是用来管理 Google 海量的容器应用的。
那么终究有一些其他存在感比较强的横向应用场景，比如权限，审批这种的。如果一个大型系统没有权限和审批的话那系统可能就千疮百孔了。
这个原则是我在群里面聊的内容的一个总结，简单解释一下，就是可以从统一
语言或者领域名称中找一些线索，比如我们有很多业务流程，有很多用例或者
在领域层，我通常使用的是 model，可以理解为业务领域模型，主要包括实体以及值对象。在应用层会将 model 作为参数进行领域层接口的调用完成核心的业务逻辑。
DDD 领域建模设计的理论中并没有对在工程结构怎么落地实际的代码做出硬性规定，本文主要根据笔者自己的一些思考以及实践经验梳理了领域模型与代码模型映射的结构
希望对大家再各自业务落地 DDD 实践的时候有所参考。到这里我们实现 DDD 落地的所有准备工作都差不多了，后面的文章中我们将根据真实的业务场景进行真正的落地实践
从业务分析到领域建模，从领域分层到代码实现。我想通过这一系列的理论加实践的方式，相信大家可以真正领悟到 DDD 的魅力所在。
消息的可靠性 ACK 标识可以集中在消费组维度，而终端消息的可靠性 ACK 标识需要具体离散到终端设备维度。简单地说，一个是客户端设备维度的 Retry 队列，一个是消费组维度的 Retry 队列。
网关节点根据其连上的终端设备订阅情况进行内部匹配，找到哪些终端设备能匹配上，然后会触发 pull 请求去存储层读取消息再推送终端设备。
然后进行匹配查找再精准推送。事件广播机制看起来有扩展性问题，但是其实性能并不差，因为我们推送的数据很小就是 Topic 名称，而且相同 Topic 的消息事件可以合并成一个事件
