开发复杂：K8s 使用声明式方法来编排和管理容器。为了实现这一点，需要配置一个 YAML 文件，但再复杂的应用程序中，引入新环节影响了开发者的生产力和敏捷性。此外，缺乏内置的编程模型，
开发者需要依赖第三方库来处理程序间的依赖关系，这些都会影响到开发效率，并增加不必要的 DevOps 开销。
sealer 是一款开源的分布式应用打包交付运行的方案，极大的简化了容器项目的交付复杂性和一致性问题。sealer 构建出来的产物可称之为"集群镜像"，并内嵌了 K8s，该"集群镜像"可以 push 到 registry 中共享给其他用户使用，也可以在官方仓库中找到非常通用的分布式软件直接使用。
交付是容器生态的另一个难题，面临着依赖复杂、一致性的问题，尤其是工业级的 Kubernetes 交付项目，交付周期变长、交付质量要求高，sealer 非常适合于软件开发商、ISV 等性质的企业，可将部署时间缩短至小时级别。
大部分传统行业、一些技术能力偏向于业务层的互联网企业、和一些不希望因受制于后端而影响业务快递迭代的创业公司，大多都会倾向于 PaaS 形态的产品，抛开企业属性，PaaS 类的服务在处理以下场景更具交付优势：
本文先找人进行了试读，有大佬提出了一些建议，为了让本文更容易让人理解
，这里我们不再具体讨论领域模型、子领域、限界上下文和聚合的概念，而是聚焦于对一个宽泛意义上的领域来划分，
应用层以及领域层都依赖基础设施层的话，那基础层就成了最核心的层级了，但是实际上领域层才是真正的核心，这显然违背了 DDD 以领域为核心的设计思想。
因此我们使用依赖倒置的方式，让基础设施层去依赖领域层，这样做的好处就是可以让领域层更加的职责单一以及更加的纯粹，
他不需要关心数据是怎么来的，无论是数据库查来的还是缓存萃取出来的还是从外部查来的，它只需要关心它自己领域内的业务逻辑就可以。既然我们明确了该怎么进行领域分层，那么各层的数据组织形式是怎样的呢？
他不需要关心数据是怎么来的，无论是数据库查来的还是缓存萃取出来的还是从外部查来的，它只需要关心它自己领域内的业务逻辑就可以。既然我们明确了该怎么进行领域分层，那么各层的数据组织形式是怎样的呢？
