从零开始学习ABP vNext开发 （二）———— 从控制台项目入手
从最简单的控制台项目，说明基本框架。
使用本地镜像创建K8S服务
K8S在创建容器时，无法从本地localhost中获取镜像，因此，需要将镜像发布到私有镜像库，然后再从私有镜像库创建应用。
Docker Desktop中使用K8S
K8S搭建比较复杂，为了在本地进行测试，可以使用Docker Desktop搭建简单的环境。
从零开始学习ABP vNext开发 （一）————概述
DDD中涉及的技术因素很多，聚合根、实体、值对象、领域事件、存储库、工作单元、领域服务、应用服务等等，还涉及架构的组织，如分层架构、微服务架构等等，还得加上日志、审计等需求……。一个项目如果从头构建，集成所有这些技术就是一个比较大的工程。从另一方面讲，所涉及的这些技术因素都有成熟的解决方案，如果将它们设计在一起，形成支撑框架，在框架的基础上引入业务特定的领域模型，在工程实践中是一种不错的选择。ABP vNext是.Net社区中流行的DDD技术框架，本系列文章介绍ABP vNext的学习。
领域驱动设计与框架——框架的支持与框架依赖的矛盾
领域驱动设计的核心是领域模型，领域模型处于软件架构的中心位置，使用接口隔离持久化等技术的具体实现，从而达到将业务复杂性与技术复杂性分离的目的。理想状态下领域模型是POJO（或者.Net下的POCO），不依赖于具体的框架。然而，实际情况是，如果没有合适的框架支持，将领域模型进行持久化在实际项目中几乎是不可能完成的任务：我们不可能在应付用户需求的同时进行复杂软件框架的研究和实现。实际项目中需要选择成熟、可靠、易于学习的技术框架在有限的时间和预算范围内完成用户需求，这是第一位的，不可能为了在项目中使用某种先进的理念而花费时间和精力。当某种理念缺乏技术支持时，就不可能在项目中使用。只有当先进理念的使用可以为项目带来其它方法不可替代的好处的时候，才有可能使用它。在领域驱动设计刚刚问世的时候，技术框架特别是持久化框架大都还只支持表模式或者Activate Recorder，如果使用领域驱动设计，必须自行开发相应的技术框架，这也就是为什么起初领域驱动设计只有在复杂项目中才会应用的原因。
DDD项目的架构风格——从单体到微服务
微服务与DDD的流行可以说是一个互相促进的过程：领域驱动设计中的限界上下文解决了微服务划分的难题，微服务为限界上下文提供了合适的物理承载。当我们已经确定了应用系统的限界上下文，采用微服务是一个不错的选择，但前提是限界上下文的划分是合理的，而这取决于对领域问题的充分了解和对应用需求的深入理解。
领域模型落地的关键之一——解决持久化问题
在DDD中，领域模型处于核心位置，负责表示业务概念、有关业务状况的信息和业务规则。如果用层次结构描述的话，领域模型处于领域层，这个层次在软件设计时不依赖于基础设施层。如果涉及到对基础设施的访问，在领域层需要定义相关的接口，而将接口的实现放到基础设施层，在运行时使用依赖注入将接口与接口的实现进行装配。这种结构就是控制反转，使得领域模型在设计时独立于基础设施的具体实现。涉及到持久化的存储库就是采用这种方式进行设计，在领域模型中，我们只定义存储库的接口，其操作的领域对象都是普通对象，也就是所谓的POCO，而将存储库的具体实现放在基础设施层，这样领域模型所在的项目不需要依赖任何持久化相关的类库，在实现存储库的组件中需要引用领域模型。
领域驱动设计中的通用语言
“通用语言”或者翻译为“统一语言”是领域驱动设计中的重要概念，这个概念不只在领域驱动设计中使用，在行为驱动开发（BDD）等开发方法中也占有重要的地位。