一文了解大厂的DDD领域驱动设计

1.什么是DDD？

DDD名为：Domain Driven Design (领域驱动设计) 简称：DDD
概念来源于2004年著名建模专家eric evans发表的他最具影响力的书籍

2.DDD与我们的传统开发又有什么区别和优势？

有过工作的朋友都知道国内大多数开发模式为：
MVC【 Model-View-Controller（模型-视图-控制器） 模式】，MVVM【Model-View-ViewMode（简称：前后端分离）】，MVCC（并发版本控制）以及后面的SOA架构（面向服务架构，软件接口组件调用）等
而DDD我的理解为:将微服务拆分的设计理念改造后嵌入到咱们的代码开发中，只是将服务改造成了领域，不同的领域做着自己相关的业务事情。它能更换的帮助《开发人员》理解：面向对象，系统解耦合，实现高内聚低耦合，并且达到复用的开发层次结构，举个浅显的例子：

一般电商微服务架构会划分为：

将其引入到DDD中就会划分为：

商品中心：负责商品的展示、导航、维护；

商品域：负责商品展示。领导，维护

订单中心：负责订单的生成和生命周期管理；

订单域： 负责订单的生成和生命周期管理

库存中心：负责维护商品的库存；

库存域：负责维护商品的库存；

交易中心：负责交易相关的业务；

交易域：负责交易相关的业务，例如，银行接口对接

促销中心：负责各种促销活动的支持

促销域：负责各种促销活动的支持

而开发的方式一般都是先设计数据库，在去写代码实现：而我对此也做了一个比较：

把各个相对应的层次，做相对应的事，需要扩展，或者业务变动，迭代，咱们可以不用关心之前写的代码逻辑，以及业务，只需要新启一个领域，或者在相同领域中新启一个实现类 调取之前业务或者领域功能模块接口即可实现，维护成本相当之低，相比MVC的代码层次，迭代，业务变动，扩展，咱们需要去Service层去读取和理解之前相关代码以及业务才可到相对应的代码处进行修改扩展等，然而代码风格每个人都有着自己的风格，读取和理解起来相当困难、
DDD它的缺点便是：代码臃肿，修改字段，极其繁琐，层次结构多，开发水平要求高，开发周期相对应较长

3.实践讲解：

好了，前面介绍了这么多，接下来我给大家介绍DDD的架构设计拆分，看看到底是什么东东
DDD一般架构分为：四边形架构，以及六边形架构
四边形架构便是：DIP（依赖倒置）

核心的定义是： 高层模块不应该依赖于底层模块，两者都应该依赖于抽象 抽象不应该依赖于实现细节，实现细节应该依赖于接口

按照DIP的原则，领域层就可以不再依赖于基础设施层，基础设施层通过注入持久化的实现就完成了对领域层的解耦，采用依赖注入原则的新分层架构模型就变成如下所示：

DIP分层

采用了依赖注入方式后，其实可以发现事实上已经没有分层概念了。无论高层还是底层，实际只依赖于抽象，整个分层好像被推平了，这就引入下一个架构六边形架构。

六边形架构（Hexagonal architecture）

六边形架构是Alistair Cockburn在2005年提出，解决了传统的分层架构所带来的问题，实际上它也是一种分层架构，只不过不是上下或左右，而是变成了内部和外部。在《实现领域驱动设计》一书中，作者将六边形架构应用到领域驱动设计的实现，六边形的内部代表了application和domain层。外部代表应用的驱动逻辑、基础设施或其他应用。内部通过端口和外部系统通信，端口代表了一定协议，以API呈现。

按照领域分层的模型，在应用层和领域层内置后，一个典型的六边形架构应用有两个端口，一个端口对应用户接口层，用于应用控制，一个对应数据访问层，用于数据获取和持久化。每个端口都可以对应几个适配器，该应用可以被自动化测试，系统层面的回归测试，用户交互操作，远程HTTP调用，REST调用或者其他。在数据方面，通过配置使用外部的数据库，可以是Oracle数据库，mock的数据库，测试数据库或生产数据库，从而实现应用和外部数据库的解耦。
另外值得一提的是，在六边形架构中，自动化测试和用户具有同等的地位，在实现用户界面的同时就需要考虑自动化测试。它们对应相同的端口。六边形架构不仅让自动化测试这件事情成为设计第一要素，同时自动化测试也保证应用逻辑不会泄露到用户界面，在技术上保证了层次的分界。
使用六边形架构的时候，我们应该根据用例来设计应用程序，而不是需要支持的客户数量来设计。任何客户都可能向不同的端口发出请求，但是所有的适配器都使用相同的API。
六边形架构的功能非常强大，可以