前言
很高兴能开始新的系列，这次的章节是DDD领域驱动设计和微服务的概念与思想。
PS：
此系列文章的源码，没有很丰富的功能，没有非常完善的认证体系，不适合直接用去企业开发。
此系列的文章，核心是突出DDD的思想，和微服务的思想。所以功能上会比较精简。
技术点：
CQRS+Event实现微服务，EfCore实现领域持久层。
源码地址：
https://github.com/SkylerSkr/Skr3D
1.DDD的思想
先讲解DDD的思想，领域驱动设计。以领域为核心推动程序的设计。
数据库驱动：
我们在开发过程中，拿到一个新的项目，第一时间应该都是设计数据库。如果业务上需要增加个字段，那么就需要更改表结构。
缺点1：如果我们不同的业务，都对一张表进行了操作，那么我们改表结构的时候，就需要处理跟业务无关的代码。随着项目的增大，这种更改工作可能是巨大的。
缺点2：有一些操作可能跟自己当前的业务一点关系都没有。随着项目的增大，代码的可读性会越来越差。
领域驱动：
数据库驱动，随着项目的增大，业务逐渐的负责，后期的开发成本会几何倍的增长。所以就有了DDD的出现，我们从领域的角度解决问题，最后再解决持久化。
领域：
小编的公司是做酒店行业的，那就是酒店领域。设想一下，如果你到酒店入住，需要哪些流程呐？
领域事件：
网上预定，入住，退房，客房服务，点餐等等。这些在酒店领域内的业务就是领域事件。
核心子领域：
网上预定，入住，退房。是酒店领域一定要有的功能，这就是核心子领域。
支撑子领域：
客房服务，点餐等不影响主要功能的就是支撑子领域。
领域专家：
对该领域非常熟悉的人，你的项目经理，老板，行业资深的从业者等。
微服务的思想
传统项目：
在我们的传统的开发过程中，每次发布都需要发布完整的项目，耗时非常长，如果发布失败了整个程序都会停止。
微服务项目：
在微服务中，服务是最小的单元。我们把传统的项目分成多个服务，单独部署出去。单服务的更改和停机，对整个项目的影响就不会很大。而DDD天生适合微服务，因每个单独的领域，就可以是单独的服务。
微服务的实现方式：
因各个服务会经常发布，可能是增加服务，也可能是减少服务。所以服务发现和网关就是核心要点。
1.服务发现：发现有哪些服务正在运行。
2.网关:对接服务发现，判断请求进来，需要转发给哪个服务处理。
架构分层
01:UI层没啥说的
02:应用层，这里就充当网关的作用，用来决定请求进入哪个领域。
03:领域层，领域层只关心自己，不关心实现方式。所以将持久层的接口也放在领域层。
Infrastruct:基础设施层，这里就提供一些基础的功能。也实现领域层的持久化方法。
架构图
