领域驱动模型设计与微服务架构落地(四)之DDD分层架构设计

本文主要是介绍领域驱动模型设计与微服务架构落地(四)之DDD分层架构设计，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

那么聊完领域模型之后，其实我们会发现，接下来，很多的程序员可能就会直接上代码，因为很多的程序员觉得这个你的战略设计跟我们落地的代码没有关系。哪怕你可能说得天花乱坠，可是做为底层的开发人员，我只关心手头上的功能有没有实现，实现完成之后有没有BUG。

那么我们该如何对于我们的系统进行分层呢?

实际上到了今天为止，大家应该已经见到过很多系统的分层方式，包括我们最常见的三层架构。这也要感谢我们程序员前辈们的努力，让我们已经不用去写那种代码纠缠在一起，整个项目只有一个大的包，各个模块耦合及其严重，扩展性还差的代码了。

很多同学其实在学习架构设计的过程中会有一些误区，会认为MVC架构好像就是三层架构，其实不然，三层架构是一个分层式的软甲架构设计，他对于项目并不挑剔，任何项目都可以使用三层架构，至于好不好用，那是另一说，但是毕竟能用。

而MVC架构则是一个设计模式，也就是说，在我确定了使用分层式架构的三层架构后，我可以根据项目的需求来确定是否使用MVC模式。

不过我们可能只是清楚我们使用的是三层架构，而并不清楚为什么要进行这样的设计，那么为什么要将我们的架构分层呢？其实咱们刚才也已经聊过了。无非就是你如果不进行架构分层，就有可能会导致代码纠缠在一起，整个项目只有一个大的包，各个模块耦合及其严重，扩展性还差。那么我们的架构分层实际上就是为了帮助我们解决这些痛点。用专业的属于来描述，我们的分层架构设计就是为了帮助我们达到高内聚，低耦合，复用以及扩展性。这四个点。

其实我们计算机领域当中还有很多经典的分层架构，比如TCP/IP模型，就可以是四层架构或者五层架构，而OSI七层模型，不过这些都只是网络分层。

而我们的三层架构，实际上就是表现层、业务逻辑层、数据访问层

首先，我们的表现层，实际上他就是展示给我们用户的层面，对应到项目当中实际上就是你们的servlet或者Controller。

而我们的业务逻辑层，实际上对应到你们的代码层面就是我们的service层，也就是说，他是用来处理我们的业务逻辑的。

而我们的数据访问层，则是直接对我们的数据库进行增删改查操作的。这个也就是我们的Dao层或者Mapper层。

而很多的同学我相信都使用过这样的架构，因为这种架构已经是以及传统CS架构的升级版，它能够将我们的业务逻辑以及数据库访问层面进行隔离。让这个两个非常重要的点能够进行解耦。

1. 四层架构

我们的领域驱动设计为了能够更好贴合业务进行落地，我们也经常会使用分层架构设计，这样做能够更好的凸显领域模型。

传统的三层架构实际上我们能够很明显的发现，我们的数据库将会做为架构起点，我们会从数据库层面开始分析以及设计，但是我们的DDD他的重点其实不在数据库，而是在领域模型，我们会将领域模型做为我们的分析基点，向上进行衍生。进而进行分层设计。

实际上，我们的Eric Evans在《领域驱动设计－软件核心复杂性应对之道》这本书中提出了传统的四层架构模式。

大家可以看到这张图，这个就是我们的四层架构，首先它分为四个层级，分别是

User Interface为用户界面层（或表示层），负责向用户显示信息和解释用户命令。这里指的用户可以是另一个计算机系统，不一定是使用用户界面的人。也就是说，其实大部分的情况，后端向前端展示信息，我们的前端也相当于我们的用户，后端则是暴漏接口。完整内容聚合操作。这里一般代码中会写到装配器，控制器。以及我们的model，不过这里的model是对外暴漏的model。因为我们的实体有可能不会直接对外暴漏，而装配器会对model进行模型转化，包括这里还会有转换过后的模型。
Application为应用层，定义软件要完成的任务，并且指挥表达领域概念的对象来解决问题。这一层所负责的工作对业务来说意义重大，也是与其它系统的应用层进行交互的必要渠道。比如我们的线程调度task，应用服务service等等。但是这里的service不是指的我们的具体的业务逻辑，而是指代的与模型，也就是实体无关的业务逻辑。
Domain为领域层（或模型层），负责表达业务概念，业务状态信息以及业务规则，也就是我们的领域模型。这里特别强调，其实我们的四层架构的业务与我们的实体实际上是放在一起的。我们是通过业务与实体来建立的一个完整的领域模型。一般我们的事件event、模型mpdel，包括模型中的工厂类，领域服务类，对象Vo，实体，Entity，聚合，还有我们的领域服务，比如分页操作，都会放在这里。
应用层传递消息，为领域层提供持久化机制，为用户界面层绘制屏幕组件，等等。基础设施层还能够通过架构框架来支持四个层次间的交互模式。

分层架构可以简单分为两种，即严格分层架构和松散分层架构。在严格分层架构中，某层只能与位于其直接下方的层发生耦合，而在松散分层架构中，则允许某层与它的任意下方层发生耦合。

传统的四层架构都是限定型松散分层架构，即Infrastructure层的任意上层都可以访问该层（“L”型），而其它层遵守严格分层架构。

并且我们的上层架构可以调用下层架构，而下层架构则不能向上进行调用。