为什么有的人每天上班，却像个行尸走肉一样。早高峰的地铁站、公交车上那么多人神情麻木。甚至有同学每天不断的完成一个又一个的目标，却仍然没有安全感。
大部分云厂商提供了 Kubernetes as a Service 的容器平台能力，比如 AWS EKS 和阿里云的 ACK，可以大幅简化 K8s 集群的部署、运维、网络存储、安全管理等能力，
在进行领域建模的时候我们会完整的构建一张对象关系图谱，有些对象很明显的属
于某一个范围，这个范围相当于对这些对象的一层抽象或者总结，比如SkuBO,
这个正交原则其实可能有点不太理解或者不容易应用，在领域划分方案出来之
后可以通过一些业务流程来看一下领域内的聚合实体服务等是否跟别的领域内
domain 层：这是整个微服务的核心层，主要包含了领域模型、领域服务以及核心的业务逻辑。领域模型主要包括了聚合中的聚合根、实体以及值对象，领域事件也会放在这一层中。
然而我们看到，在消息（队列）这个领域，近些年我们业界有个很重要的趋势，就是基于消息这份数据可以扩展到流批计算、事件驱动等不同场景，如 RocketMQ-streams，Kafka-Streams、Rabbit-Streams 等等。
上图描述的接受我们的队列存储模型，消息可以来自各个接入场景（如服务端的 MQ/AMQP，客户端的 MQTT），但只会写一份存到 commitlog 里面，
前面也提到了终端消息场景和服务端一个很大的区别是，终端必须要有个客户端维度的队列才能保证可靠触达，而服务端可以使用集中式队列，因为消息随便哪台机器消费都可以
什么是领域（Domain）？
前面我们已经清楚的知道我们现在要做一个什么样的系统，这个系统需要解决什么问题。
但是，很多项目（尤其是互联网项目，为了赶工）都是一开始模型没想清楚，一上来就开始建表写代码，代码写的非常冗余，完全是过程是的思考方式，最后导致系统非常难以维护。
