《ddd第二篇》- ddd在交易系统中的应用-爱代码爱编程
目录
洋葱架构详解
1、前言
在交易中台中主要使用的是基于四层架构的洋葱架构，并同时应用了CQRS、事件驱动架构设计。
2、四层架构&洋葱架构介绍
四层架构
1.用户界面层（User Interface Layer）：负责与用户交互，包括图形界面、命令行界面、API等，有时也可单理解为用户接口层，即为端上提供接口的层；
2.应用服务层（Application Services Layer）：负责接收及处理用户请求，并通过协调各个领域服务完成应用程序的业务逻辑。
3.领域层（Domain Layer）：负责实现业务领域的核心逻辑，处理业务流程、规则等。领域层使用领域实体（Entity）、值对象（Value Object）、聚合（Aggregate）等模型与其它层进行交互。
4.基础设施层（Infrastructure Layer）：包括与外部系统的交互、数据库访问、缓存、消息队列等底层实现，为上层各层提供支持。
四层架构在实践中又可分为：
-
严格分层架构：某层只能与位于其直接下方的层发生耦合
-
松散分层架构：允许某层与它的任意下方层发生耦合。
-
特点：更加灵活，比较适合传统分层架构向DDD分层架构的演进。
-
四层架构相比传统MVC三层架构来说，Model层更加细分，第一层职责更加明确。
洋葱架构
四层架构如果说是纯理论性的，洋葱架构是更加偏实践性的，洋葱架构通过更加细致的分层及职责划分让软件架构各个领域或分层更加规范和明确。
洋葱架构详解
应用构建在领域模型上，系统设计人应更关注领域的划分及设计，不要太多关注技术实现。层之间依赖及调用时，只能外层调用里层，里层不能调用外层，里层感知不到外层的存在。内层是原则（规则），外层主要是实现机制。
在代码依赖上也是从外向内的，内环中的代码不应该知道外环中的任何东西。
Domain Model：业务模型，对应DDD中的Entity、值对象等
Domain Service：核心业务逻辑
Application Service：应用的输入输出层
User Interface/Tests/Application：适配器层
原则
洋葱架构是由多个同心层构成，它们相互连接，并朝向代表领域的核心。它是基于控制反转（Inversion of Control，IoC）的原则。该架构并不关注底层技术或框架，而是关注实际的领域模型。越往里面抽象级别越高，最外层的圆是低级别的具体细节。越往里面内容越抽象，并且封装更高级别的原则，最里面的圆是最通用的。
依赖性
圆圈代表不同的责任层。一般来说，越靠近内层，就越接近于领域和业务规则。外圈代表机制，内圈代表核心领域逻辑。外层依赖于内层，而内层则对外圈一无所知。通常情况下，属于外圈声明（包括方法、类、变量或任何软件实体）不能被内圈引用。
例如在数据模型上，外层的数据格式不应该被内层使用，API场景中使用的数据格式可以与 DB 中用于持久化的数据格式不同。数据流可以使用数据传输对象。每当数据跨层/跨界时，它应该以方便该层的形式出现。例如，API 可以有 DTO，DB 层可以有 Entity Objects。
数据封装
每个层/圈封装或隐藏内部的实现细节，并向外层公开接口。每个层定义便于内层使用的数据模型，以最小化层与层之间的耦合。比如User Interface与Application Service、与交互的模型，Application Service层Domain层都会定义不同的数据模型。
3、交易系统中的设计
四层架构调用链接、各层职责
各层之间数据模型传递规范
场景层也不一定必须需存在，服务层直接进行模型转换为DO后，调用各个子域服务；
重点关注各层之间模型是如何使用及传递的；
电商业务交易创建订单DDD分层及类依赖关系
三、DDD架构优缺点
DDD优点
-
DDD更擅长用于解决复杂的系统之间的架构分层设计，通过提前确定好各个层的职责及边界，能让系统架构更加规范和清晰；
-
在复杂的业务系统中，通过DDD中明确合理的分层，能让开发更聚焦解决某一层或某一领域的问题。
-
通过这种设计可以降低层与层之间的依赖，也可以很容易用新的实现来替换原有层的实现。
-
有利于标准化，利于各层逻辑的复用。
DDD缺点
-
DDD相比传统MVC架构有比较高的理解和学习成本；
-
DDD不是万金油，如果是一个在短期和未来都相对比较简单的一个系统如若使用DDD的话会让开发者非常痛苦；
-
使用DDD架构进行后代码量会显著增加，短期内也会不太容易看到收益 ；
DDD入门请看上一篇内容