因为我们给自己设计的目标规划在不断变高。所以，我们这么忙碌都是为什么什么？我们要干嘛？我们要去哪儿？
开发复杂：K8s 使用声明式方法来编排和管理容器。为了实现这一点，需要配置一个 YAML 文件，但再复杂的应用程序中，引入新环节影响了开发者的生产力和敏捷性。
在进行领域建模的时候我们会完整的构建一张对象关系图谱，有些对象很明显的属
于某一个范围，这个范围相当于对这些对象的一层抽象或者总结，比如SkuBO,
SpuBO,SkuSnapShotBO等。
那么对于划分领域的这个人是否真正的从业务出发去划分谁也不
知道，就是说这个领域在当前业务中是肯定存在的，比如下单优惠，支付优惠
，营销策略等等。
实际上，在很多场景下，父命令是没有执行逻辑的，特别是以 resource 作为父命令的场景，父命令的唯一作用就是打印这个命令的用法。
cobra 让子命令和父命令的定义非常简单，但父子调换仍然需要修改其间的链接关系，是否有方法让这个过程更简单一点呢？
在领域层，我通常使用的是 model，可以理解为业务领域模型，主要包括实体以及值对象。在应用层会将 model 作为参数进行领域层接口的调用完成核心的业务逻辑。
然而我们看到，在消息（队列）这个领域，近些年我们业界有个很重要的趋势，就是基于消息这份数据可以扩展到流批计算、事件驱动等不同场景，如 RocketMQ-streams，Kafka-Streams、Rabbit-Streams 等等。
方向二：产业融合应用
发展人工智能应以产业的融合应用与产业数字化转型为核心目标，进而逐渐形成数据驱动、人机协同、跨界融合、共创分享的智能经济形态。纲要提出，要以数字化转型整体驱动生产方式、生活方式和治理方式变革，充分发挥我国数据、
DDD中，我们总是以领域为边界，分析领域中的核心问题（核心关注点），然后设计对应的领域模型，再通过领域模型驱动代码实现。而像数据库设计、持久化技术等这些都不是DDD的核心，而是外围的东西。
领域模型在设计时应考虑一定的抽象性、通用性，以及复用价值；
通过领域模型驱动代码的实现，确保代码让领域模型落地，代码最终能解决问题；
领域模型是系统的核心，是领域内的业务的直接沉淀，具有非常大的业务价值；
