领域驱动设计实战进阶第一波（八）：开发一般业务的大健康行业直销系统（总结篇）

DDD实战进阶第一波：开发一般业务的大健康行业直销系统

前面我们花了7篇的文章来给大家介绍经典DDD的概念、架构和实践。这篇文章我们来做一个完整的总结，另外生成一个Api接口文档。

一.DDD解决传统的开发的几大问题：

1、没有描述需求的设计模型；而是直接通过数据库表的方式体现，也就是需求与设计是脱节的。
2、编码的架构也没有与设计和需求对应起来。
3、业务逻辑与技术混在一起；业务逻辑可能直接调用的数据访问，这样把业务逻辑与数据访问的技术混在一起。
4、开发没有层次感和节奏感；系统没有一个统一的约束，开发人员没有一个统一的节奏，这主要体现在随意的编码。
5、Bug 定位困难：当系统出现业务异常行为时，无法快速准确的定位出现问题的位置，因为系统不同开发人员的代码放置随意性。
6、需求变更响应缓慢：在大型的系统或产品中，当需要增加功能或修改现有功能时，因为代码架构的随意性，可能会出现改了功能可能会影响到其他的功能，造成系统极不稳定。

解决软件设计与开发问题的套路就是领域驱动设计（简称 DDD）。DDD 这个套路能够灵活解决以上的问题，为我们提供一个好的设计、架构以及高质量的代码。

二.DDD解决之道：

DDD 方法首先是需要将需求分析后，形成一个反应需求的领域模型。领域模型就是大家平常理解的类、类的属性、类之间的关系等。当然在 DDD 中，为了更好的将领域模型反应需求，对类、类的属性、类之间的关系等有一些模式的指导。比如类的属性可能是一般属性，也可能是值对象；比如有关系的类之间是否是代表一个整体概念、有相同生命周期、需要统一持久化等。所以我们的领域模型除了能够跑通需求外，还要考虑聚合根、实体、值对象、聚合等概念的应用，这样领域模型的设计才能更好的反应需求，也能够更好的将设计对应成有约束力的代码。另外 DDD 也提供了大量模式，告诉我们应该如何编写对应设计的代码，能够将我们的代码真正映射到设计；如何进行业务逻辑与持久化机制的剥离；如何进行更好的架构设计等。

1.DDD能应对复杂性：系统复杂性主要体现在三个方面。一是技术维度，有业务代码的实现、有与数据库或其他持久化存储交互的实现、有消息队列的实现、有身份验证与授权的实现、有 WebAPI 暴露的实现等；二是业务维度，有太多的模块和功能需要去做；三是时间维度，需要快速的开发，快速的响应需求的变更，快速的修正 Bug。

DDD应对复杂性主要通过三个方面：

a. 技术维度：通过合理的架构分层，能够让每层关注自己的事情，比如领域层只关注业务逻辑的事情，仓储实现层只关注持久化数据与查询的事情，应用服务层只关注协调领域层与仓储实现层完成用例的事情，接口层只关注暴露给前端的事情。

b. 业务维度：通过将大系统划分成多个界限上下文，可以让不同团队和不同人只关注当前上下文的开发。在当前界限上下文中的领域层、仓储实现层、应用服务层、接口层都与其他界限上下文独立开来，这样可以专注开发，并且在修改代码与发布产品时，影响面较小。

c. 时间维度：通过敏捷式迭代快速验证，快速修正。

2.高效掌握DDD：

a. 熟悉概念：充分熟悉前面文章介绍的界限上下文、实体、值对象、领域服务、聚合、聚合根、仓储、应用服务、接口等。
b. 熟悉架构：充分熟悉前面文章介绍的经典DDD的架构。
c. 实践：前面文章从产品、经销商、订单三个界限上下文分析了需求、建立了领域模型、通过经典DDD架构实现了代码，需要你在实际项目中灵活的运用。

三.接口文档的生成

当我们已经做好了所有的接口后，需要生成WebApi在线的接口文档，便于前端人员进行查看与使用。.net core webapi中使用Swagger生成接口文档。

1.在WebApi项目中引入Nuget包：Swashbuckle.AspNetCore。
2.在WebApi项目属性的生成中，勾选“XML 文档文件”。此目的是可以包括WebApi中每个接口的注释。

3.在WebApi Startup.cs文件的ConfigureServices方法中，添加如下的代码：

//swagger接口文档的信息

services.AddSwaggerGen(c =>
        {
            c.SwaggerDoc("v1", new Info
            {
                Version = "v1",
                Title = "产品界限上下文接口文档",
                Description = "包括产品界限上下文所有接口的描述",
                Contact =new Contact {Name="曹剑",Email="[email protected]"}
            });
            //使用Xml文档中接口的注释
            var basePath = ApplicationEnvironment.ApplicationBasePath;
            var xmlPath = Path.Combine(basePath, "Product.WebApi.xml");
            c.IncludeXmlComments(xmlPath);               
        });

4.在Configure方法中，添加如下的代码：
//制定swagger接口文档的访问url路径信息

app.UseSwagger();
        app.UseSwaggerUI(p =>
        {
            p.SwaggerEndpoint("/swagger/v1/swagger.json", "Product接口");
        });

5.修改Properties下的launchSettings.json文件中的两个launchUrl的值都改为swagger，这样在打开这个WebApi时，自动跳转到swagger帮助文件：

"profiles": {

"IIS Express": {
  "commandName": "IISExpress",
  "launchBrowser": true,
  "launchUrl": "swagger",
  "environmentVariables": {
    "ASPNETCORE_ENVIRONMENT": "Development"
  }
},
"Product.WebApi": {
  "commandName": "Project",
  "launchBrowser": true,
  "launchUrl": "swagger",
  "environmentVariables": {
    "ASPNETCORE_ENVIRONMENT": "Development"
  },
  "applicationUrl": "http://localhost:5000"
}

}

6.访问时，最终的效果如下图：

7.在点击每个接口时，可以看到详细的调用说明：

本系列的文章就到这里，这个系列的文章主要是讲解了经典DDD，关于CQRS DDD与微服务，可以继续关注我们后续的系列文章，也可以加入QQ群或关注我们的微信公众号。在后续CQRS与微服务的内容中，我们将实现如下的架构
微服务架构：

CQRS架构：

QQ讨论群：309287205
DDD实战进阶视频请关注微信公众号：MSSHCJ