基于 MVC 实践领域驱动(DDD)的思考

背景

MVC 作为一个古老且经典的软件设计模式,基于分层架构的思想,在软件开发领域有广泛的应用。

但在软件系统日益复杂的今天,单纯的分层架构已经显得力不从心,不能应对当前复杂系统的架构需要。

在传统的 MVC 架构下,大概有两种实践,一种是重 Model,另一个是轻 Model。重 Model 把很多的业务逻辑都放在 Model 层。轻 Model 要么把业务逻辑放在 C 层,要么引入单独的 Service 层,编写公用的业务逻辑。

对于简单的业务这样做完全没有问题,而且能够很快的实施,但一旦业务变得复杂,各种业务逻辑相互交织,就很容易产生层层交织的面条式代码,难以理解和维护。

引入 DDD

为了解决这个问题,引入 DDD 是一个解决方案,通过 DDD 提供设计方法论,能够很好的指导我们进行领域建模,但 DDD 庞大且难以掌握,极度依赖个人经验,这给引入 DDD 带来了比较大的挑战。

所以,笔者就在思考,我们能否在 MVC 的基础上,分步骤的引入 DDD 的设计思想和原则,一个一个的解决我们面临的问题,而不是一上来就完全遵循 DDD 。

基于这样的思路,得以形成成文,下面从多个方面谈谈笔者的想法。

融合 DDD

我们将 DDD 的核心概念纳入到 MVC 中,通过 DDD 的核心概念指导架构。

限界上下文(Bounded Context)

限界上下文是领域驱动很重要的概念,通俗的来讲,我们需要通过划分限界上下文,将一个大的问题划分为若干个子问题,每个子问题都对应一个限界上下文,不同的限界上下文之间是低耦合的,它们之间的交互需要被严格限制。

通过限界上下文将一个大的领域,拆分出若干个独立的子域,每个子域解决其特定的问题。

为了在 MVC 中实践 DDD,我们首先需要合理的划分系统中存在的限界上下文,然后在每个限界上下文下合理的解决问题。

一个限界上下文下包含了对应的领域模型和领域服务,下面分别介绍。

领域模型(Domain Model)

领域模型可能会让我们很自然的想到 MVC 的 Model 层。他们之间的区别是领域模型是与数据库无关的,领域模型是在内存中的存在,由单独的持久化层(Repository)进行存储数据。

在 MVC 中,Model 没有更细的划分,但在 DDD 中,我们将其划分为实体(Entity)和值对象(Value Object)。实体与值对象的区别在于实体需要一个唯一标志,且有自己完整的生命周期,值对象则并不需要这些,值对象看起来就像一个复杂一点的属性,比如订单就是一个实体,而配送地址配送地址就是一个值对象。

领域模型关注实体以及其相关对象的领域约束和生命周期,比如订单实体需要有一个配送地址,那么这个地址的检查应该是领域约束的一部分,没有配送地址的订单就不能够被创建。

在领域模型中还有一个很重要的概念就是聚合(Aggregate),聚合就是一组相关对象的集合,它是数据修改和访问的单元,每个聚合都有一个聚合根(Aggregate Root)和边界。比如订单的上下文中,订单就是聚合根,订单的附属信息比如配送地址、联系人的修改和访问都需要通过订单对象进行。

在领域模型中,和 MVC 最大的区别是我们通过对象模型来构建领域模型,而不是通过数据库表记录,我们关注是领域对象本身,而不是如何存储它们。

领域服务(Domain Service)

在领域模型中,我们关注是一个订单及相关对象这样的个体个体间的业与务关系,而没有关注不同订单之间全局的关系,假如我们要实现按某些条件拆分订单,这样的逻辑领域模型是无法处理的,因为它缺少全局的信息。这个时候我们可以将其放在领域服务处理。

领域服务还能处理其他很多需求,比如唯一性验证,某些业务规则的验证等等,在笔者看来,凡是 在这个领域之内 ,无法放在领域模型的逻辑都可以放在领域服务下,但这应该是最后的选择,我们需要保证领域模型已经足够完备。

在 MVC 的角度,领域服务将原来分散在 Controller 或者 Model 的领域逻辑统一起来,作为单独的领域服务,领域服务再对上层提供服务。

应用层 (Application)

结合 MVC,DDD 中的应用层对应 MVC 的 Controller 层,它的主要目的接收外部数据输入,然后组装各个领域服务,对外提供能力。

此外,应用层的职责还包括对客户端输入数据的校验,用户访问权限的检查等。

验证如何做

对于一个系统来说,验证是保证系统功能正确的基础,很多地方有需要验证,有的验证是数据合法性的校验,有的验证是业务规则的校验,也有访问权限的校验。

在笔者接触的 MVC 结构下的感觉是,验证的处理比较随意,只要完成目的就行了,并没有考虑在什么位置是最合适的,最终出现的问题就是业务逻辑分散。一个业务逻辑需要找多个地方的代码才能串联起来。

结合 DDD,笔者认为可以把原来分散的各处的、不统一的验证逻辑分为三个部分,应用层验证、领域服务验证和领域模型验证,下面从外到内分别说明:

应用层验证

应用层验证主要处理外部输入的验证和权限的验证,而外部输入的验证又可以通过 Open API (https://openapis.org) 来定义,同时解决 API 定义、数据验证和 API 文档的问题,不用再维护单独的 API 文档,能够实现代码及文档。

更进一步,可以和前端打通,实现 sdk 的自动生成,实现部分验证逻辑的复用,在前后端分离的大趋势下减少同样的逻辑实现两次,降低前后端分离产生更多的不一致性。

领域服务验证

应用层的验证可以比做网关,它的作用是屏蔽从外网到内网的非法请求。而领域服务就是我们的内网,这里需要处理的验证都是和业务相关的,且跨多个实体的。比如用户邮箱的不可重复性。

通过领域服务的验证,我们能够保证在这个领域的全局内,所有的领域对象不会存在错误和冲突,保证系统是满足业务规则的。

领域服务的验证还可以进一步探索如何把验证规则抽象出来,以一种统一的方式来表达和编写,能够同时实现单个验证和批量验证,解决批量操作存在的性能问题,也能实现各种验证的灵活组合。这样代码层面来看就更加直观,便于修改和维护。这也是笔者在探索的东西。

领域模型验证

最后是领域模型的验证,如果说领域服务关注于全局,领域模型则关注于个体,个体与个体之前的关系是怎样的,需要满怎样的约束条件。

比如订单需要一个必填的收货地址,如果缺失收货地址,这个订单就不能够被创建,通过领域模型的验证,保证数据的完备性。

这一层的验证比较容易做的,很多框架都提供了相关的验证机制,我们只需要拿来用就行了。

结束语

本文在 MVC 的基础上最小化的引入 DDD 的限界上下文、领域模型、领域服务和应用层的概念,并与 MVC 的概念结合在一起,希望探索一个快速上手实践 DDD 的方法。如果读者你有什么疑问或想法,欢迎与我交流。

本文到此结束,更多精彩文章,尽在「代码写诗」,微信搜索「 代码写诗 」公众号即可关注。

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章