当前位置: 首页 > 编程学习 > 软件工程 > 领域驱动 > 正文

用DDD设计一个电商网站(二) 项目架构

2018-04-22 来源:博客园/Zachary_Fan

一、前言

上一篇我们讲了DDD的核心概念(附上链接),并且设计了我们的上下文映射图,那么接下来就准备开始立项了,本篇文章的部分知识点可能对一部分人来说比较基础,可以选择性的阅读。

在这之前我们平常用的最多的应该就是3层架构了,这里也不展开描述了,大家都是在3层的陪伴下一路走来的~

DDD所使用的传统分层架构是松散分层,也就是上层可以访问任意层级的下层,而不是仅限于当前层的下一层,这是有别于3层架构的。如下面2张图的区别图:

【图1】

【图2】

Application:这层的职责是对接收到的数据做一些非业务性验证,事务的控制,最重要的是协调多个聚合之间的操作。这里应该可以清晰的表达出整个操作所做的事情,并且与通用语言是一致的。

Domain:这一层是DDD设计的核心,这里不但需要精确合理的表达出通用语言的每一个细节,另外如何把对象合理的定义为聚合、实体、值对象也是重中之重。这里不但关系着整个项目的复杂度,也是战术建模的体现,任何的一行代码都是对业务的准确定义,应该是恰到好处。一个清晰简洁的战术建模才可以应对后续的快速变化。

Infrastructure:这里是辅助性的一层,也是整个项目的基础。好比这里存放着一砖一瓦,最终建造什么模样的高楼在于用它的地方。主要包括,仓储的实现(我们存放数据的地方)、一些通用的支撑性类库。

二、六边形架构

在[Vaughn Vernon]《实现领域驱动设计》一书中多次提到对DDD主张六边形架构的概念,六边形架构对于保证限界上下文内的领域概念的清晰性有着重要的作用,那么什么是六边形架构,如下图3(摘自[Vaughn Vernon]《实现领域驱动设计》一书)。

【图3】

在当今越来越提倡开放合作的大环境下,引用的多样化的Service,和在自身系统达到一定规模之后的分布式治理,越来越需要通过协作进行工作,那么如何提升协作的效率变得越来越重要。提高各个应用程序的自治性,是一种有效提升协作能力的手段。从上图中看出为了保证领域模型所在的应用程序的干净简洁和自治性,各种适配器作为"防腐层(在上篇中有提到)"在整个程序的最外层保护着当前的“界限上下文(在上篇中有提到)”不受外部入侵。

所以在我们的整个设计中需要注意对涉及到外部系统交互的地方的抽象,通过面向接口、依赖注入等方式做到外部的变化对自身系统的影响最小化。