DDD之代码架构

本文适合于对DDD战术模式有一定了解的读者。

从复杂性谈起

要聊架构问题,其实要先明白架构想要解决的是什么问题。我认为代码架构主要解决的是两个问题:程序的复杂性和编程的复杂性。

依赖混乱导致了程序复杂

程序的复杂性,指的是程序里分层或抽象不清晰,导致依赖关系比较乱。这里的“依赖”其实可以比较简单地理解为,A使用了B。如果删除了B,A就不能继续正常工作了。AB可以指的是类、模块、分层等概念。

经过了很长一段时间的发展,现在软件界已经能够总结出一些比较好的设计模式、分层架构、甚至是基于maven/gradle等构件工具的模块化、代码分包、甚至是微服务拆分等手段,来尽量减少彼此之间的依赖,架构的本质就是要尽量做到“高内聚,低耦合”。

然而架构很难完美。现在市面上绝大多数后端Web项目用的是“三层架构”(或者更多层,但本质上是差不多的),即controller -> service -> dao。其中controller层和dao层处于依赖关系的两端,且职责比较清晰,一般不会有什么太大的依赖复杂性。但service层就不一样了,它承载了所有的主要逻辑,彼此之间相互调用是很正常的一件事,所以service层的依赖关系很容易变得错综复杂。这就会导致软件到后面会变得越来越难以维护。

DDD结合整洁架构可以让依赖变得清晰,比三层架构有更好的“高内聚,低耦合”特性。

技术和业务耦合导致了编程复杂

编程这件事为什么复杂?为什么只有程序员能做,甚至初级程序员还做不好?不就是CRUD(增删改查)加if-else吗?

其实主要原因是编程这件事,有很多技术上的东西。可能要与数据库打交道,可能会发送消息,使用缓存,处理并发,处理失败、超时问题等等。这些事情其实都是与业务逻辑无关的,可以说是纯技术上的东西。

而业务逻辑,才是真正的CRUD加if-else。开发人员在写业务逻辑的时候,像个把业务语言翻译成代码语言的工具人,其他时候我们才是工程师。我们很多bug,可能并不是技术层面的bug,而是由于开发和测试没有足够了解业务造成的,遗漏了业务上的某些点,产生了业务上的bug。

在三层架构,往往技术和业务是耦合粘连在一起的,至少代码层面上很难把它们分开,很难单独把“业务”方面的代码抽离出来。

但DDD可以,DDD可以把业务全部内聚在领域层,且领域层不依赖其它任何东西,只有最纯粹的业务。那我们是不是甚至可以把这一层的user case和单元测试、甚至是实现代码都给业务同学(或者是领域专家)写?毕竟只跟业务相关,且都是简单的if-else。

整洁架构

来看一下DDD与各种架构提出的时间线。

2003年Eric Evans出了一本叫《领域驱动设计-应对软件复杂性之道》的书。2005年六边形架构(也叫端口与适配器架构)问世,2006年CQRS和Event Sourcing在一次Greg Young的演讲中提出,2008年洋葱架构。

2012年,Bob大叔发文,说:我总结了之前的各种架构,比如六边形架构、洋葱架构、尖叫架构(他自己2011年提出的)等等,总结出了它们好像说的其实是一个东西,我把它们抽象整合一下,提出这样一个“整洁架构”。

整洁架构链接:https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

向内依赖规则

整洁架构图是一个同心圆。它的依赖规则是依赖方向朝内,每个环可以依赖它本身这一层及其所有内部的层,但不能依赖它外部的层。就像图中黑色的水平箭头所示的那样。

虽然图中只有四层,但它可以不止四层,可以继续细分或者向外扩展,只要满足向内依赖规则就行。

Entities

对应DDD的话,这一层是用来放实体、值对象、聚合等领域模型的。业务逻辑都应该尽量内聚在这一层,这一层是最纯净的,不需要依赖任何其它东西。

Use Cases

翻译过来是“用例层”,用于协调进出Entities层的数据流,通过调用和编排领域模型来实现用例。在DDD中,这一层通常是Application Service层,是很薄的一层,只用来做一些比较简单的事情。

Interface Adapters

这一层叫“接口适配层”,它其实是主要用来与外部进行适配的。比如Web请求进来的Controllers(写)和Presenters(读)。这一层会将User Cases或Entities层需要的数据结构与外层的数据结构做一个转换。比如操作数据库、调用第三方接口等。

Frameworks and Drivers

这一层主要是框架和驱动层,比如数据库驱动、WEB框架、UI等,日常编码中很少会在这一层编写代码。

跨越边界和依赖反转

就如同图中的右下角所示。我们的业务流程通常是先从controller进来,调用Use Cases层。但有时候Use Cases层需要调用presenter。如果直接调用,就破坏了“向内依赖规则”,这个时候可以用“依赖反转”来做。

简单来说,我们在Use Cases层定义两种抽象类或者接口:Use Case Input Port, 或者Use Case Output Port。Use Case Interactor去实现了Use Case Input Port,而Presenter去实现了Use Case Output Port。

这样Use Cases层就不用依赖外部的层了。同样的道理,也可用于对数据库、第三方接口等的交互场景。

代码

No Code, No BB, Show me the code!

我给大家找了一个Go语言版本的整洁架构代码实现,来一起分析一下它的结构。

Github地址:https://github.com/manakuro/golang-clean-architecture

文章地址:https://medium.com/@manakuro/clean-architecture-with-go-bce409427d31

首先看一下整体的结构:

.├── domain(对应Entities层)│   └── model│       └── user.go├── infrastructure(对应FrameWorks & Divers层)│   ├── datastore│   │   └── db.go│   └── router│       └── router.go├── interface(对应Interface Adapters层)│   ├── controller│   │   ├── app_controller.go│   │   ├── context.go│   │   └── user_controller.go│   ├── presenter│   │   └── user_presenter.go│   └── repository│       └── user_repository.go├── main.go├── registry│   ├── registry.go│   └── user_registry.go├── usecase(对应Use Cases层)│   ├── presenter│   │   └── user_presenter.go│   ├── repository│   │   └── user_repository.go│   └── interactor│       └── user_interactor.go

Entities层没什么好说的,就是放的领域模型。Use Cases层定义了presenter和repository的接口。并且在interactor中,使用了这两个接口。

// user_interactor.go中的Get方法func (us *userInteractor) Get(u []*model.User) ([]*model.User, error) {    u, err := us.UserRepository.FindAll(u)    if err != nil {        return nil, err    }    return us.UserPresenter.ResponseUsers(u), nil}

然后在Interface Adapters层,实现了上面定义的两个接口。在user_controller.go里面,调用user_interactor。

DDD与整洁架构

看了上面的整洁架构,发现是不是还是不能跟DDD的战术模式完全match上?

是的,DDD是用来解决软件的复杂性的,而真实的软件远比上面的demo代码复杂得多。其中两个很重要的架构上的概念CQRS、Event Sourcing、Domain Service等并没有在上面整洁架构的图中体现出来。

我也是疑惑了许久,最终在hgraca的博客里找到了答案。全部都在这张图上了:

博客原文:https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-it-all-together/

这不只有整洁架构,上面还有一些明显的六边形架构的样子。不过内部是整洁架构的模式,并且和DDD很好的结合了起来。我把它中间部分放大一些。

可以看到,处在最中间的是领域模型,然后是领域服务。这两环共同构成了领域层。更外面一层是应用层,应用层也包含了两个环,里面是App Services,外面是C/Q处理器、事件监听器等等。

然后再往外,是大红色轮廓包起来的Application Core。这一层定义了很多接口(也可以说是端口),比如持久化、第三方服务、搜索、CQ总线、事件总线等等。当然,也接收处理命令和查询。

思考,我曾遇到的问题

在之前的DDD项目上,我曾经遇到过一些战术模式上的问题,现在回过头去思考一下。

究竟什么时候需要领域服务?

可以一句话总结:当只使用领域模型做不到的时候。那两者都是在领域层,大家都不依赖外面的东西,什么情况下领域模型做不到,领域服务就做得到?

一个很常见的场景是创建模型的时候有业务逻辑。虽然创建模型通常是放在Factory里面,但Factory里面并不适合放业务逻辑。而这个时候领域模型还没有创建,自然就只能放在领域服务里面了。

当然了,DDD最佳实践是希望能够尽量消灭领域服务层,全部内聚在模型层,只是很难达到这种完美的情况。

在应用层需要查询其它数据怎么办?

有时候我们可能不止是需要当前这个聚合根的数据,可能还需要其它的数据。这个读取操作当然不可能放到领域层去做,通常把它放在应用层。但应用层通常是一个聚合根对应一个ApplicationService,正常的流程是调用Repository接口获取一个领域模型对象,然后对它进行操作,再保存回数据库。

那如果需要获取其它数据怎么办呢?尤其是可能与当前领域模型无关的数据,比如“最近评论时间”。

我们团队之前的解决方案是用了一个Query,Query的职责是去数据库查询,它可以查询部分字段。但为了防止它被滥用,团队规定它只能用于repsenter或者applicationService中“为了写的读”。

回过头去看整洁架构,这里的Query其实就是User Case Output Port。不过当时我们团队的Repository和Query都没有做抽象处理,也就是说并没有依赖反转,所以ApplicationService层依赖了它们,这与整洁架构的“单向依赖”不太相符,这里其实用上依赖反转会好一点。

领域事件究竟该在什么时候发送和接收?

这个也是一个比较有争议的点。首先看领域事件在什么时候创建,有人认为应该在领域层创建,有人认为应该在应用层创建。个人认为在领域层创建比较好,因为创建领域事件其实也算是一种业务逻辑,并且只是创建一个领域事件的话,不会依赖任何外部的东西,放在领域层没有什么问题。

那什么时候发送领域事件呢?按照整洁架构的规则,不应该在领域层发送,因为事件总线(或者事件发送器的实现)在最外层,如果在领域层发送,虽然有依赖倒置,但感觉也跨越太多层次了,不是一个好的实践。

那在应用层发送事件是一个比较好的方案。我们团队之前的方案比较奇葩,是在Repository的实现里面发送的。有点忘记当时为啥这样做了,不过现在看来,应该在应用层去做更合适一些。

事件接收的话,就像上面的图中所示的一样,放在应用层比较好(但在App Services外)。然后可以通过ApplicationService去完成业务逻辑。

跨聚合根的事务问题?

这个其实很难保证强一致的事务了,因为跨聚合根应该使用事件通信,但事件的实现方式有多种,如果是异步,那就保证不了强一致的事务。只能用一些技术手段去尽量保证最终一致。

怎样保证架构不被腐化?

根据之前的实践经验来看,代码架构是有可能随着时间腐化的。比如我前面提到的Query就是一个例子,得通过一些团队间的“共识”来保证它不被滥用。我们不能保证代码完全不被腐化,但是可以通过一些手段去保证依赖的层次不被腐化。

比较推荐的是使用maven/gradle的模块化,因为模块之间是有依赖关系的,只要我们不去改依赖的配置,就永远是单向依赖的。具体来说,我们可以把整洁架构上面的层级分成一个个模块,然后在配置文件里面定义它们的依赖关系。比如应用层模块,依赖领域层模块;接口和适配层模块依赖应用层模块和领域层模块。

永远的难题:定义合适的聚合根

最后谈一个比较难的问题,就是找聚合根。其实大家可能觉得,定义一个聚合根应该很简单,根据业务来就是了,比如用户、订单、商品、库存等等。但有时候我们很容易把聚合根定义得很大,因为无论聚合根多大,它都能够很好地解释。有个建模界的笑话是:我定义了一个“宇宙类”,它可以包含所有模型。

聚合根太大可能会有问题,比如代码过多、测试用例过多、性能不好等等。很有可能做着做着一个聚合根就膨胀了,这个时候你们尝试去拆分它,会发现并非像最开始现象的那样不能拆分。只是要找到合适的“借口”,要拆得有理有据。但总而言之,这是一件很难的事情。

(0)

相关推荐