DDD精粹速读(二)

cnblogs 2024-08-24 08:13:27 阅读 75

前言

在上一篇文章中,我介绍了领域驱动设计(DDD)的战略设计,以及如何处理大局。本篇文章将深入探讨领域驱动设计(DDD)的核心——战术设计。

Vaughn Vernon 在他的书《Implementing Domain Driven Design》(实现领域驱动设计)中巧妙地将战略设计比作登山者规划攀登路线,而战术设计则比作他们所使用的工具。

战术设计

战术设计为我们提供了有用的指引和结构,帮助我们在领域模型中创建丰富且纯粹的业务逻辑表达。当我们需要为一个复杂或潜在复杂的领域建模时,这些指引尤为有价值。

在DDD之外,实体通常会被建模为具有多个属性,这些属性可以被模型代码的调用者(客户端)更改。这样一来,客户端需要自行执行业务规则(例如,价格不能为负)。其结果是,业务逻辑往往分散在我们的应用程序中,通常位于应用层/服务层或控制器中。

战术设计建议我们的领域模型应该是封装所有与系统服务的上下文/子领域相关的业务逻辑的地方。它位于我们应用程序的“核心”,并且不依赖于外部的架构层。

系统的行为通过领域模型的公共方法暴露出来,这些方法代表了用户希望执行的有意义的任务(例如,SubmitOrder,ReserveItem)。模型的客户端只能调用模型的这些方法。领域模型是使用统一语言构建的。

战术设计工具箱中,有一些结构使领域建模变得更加简单且有效。

实体

在战术设计中,实体是具有身份的事物。其属性可能会随时间而改变,但实体本身依然是同一个实体。实体由其身份定义,而非其属性的值。

例如你,一个人类(显然)。即使你改了名字,你仍然是同一个人类。如果你有一个拥有相同属性的双胞胎,你们两人也不是同一个人类。实体的内在身份独立于其属性。

值对象

值对象,与实体不同,它完全由其值定义,没有身份。例如棕色这种颜色;它无法改变,否则就会变成另一种颜色。它由其值定义且不可变。

一种特别有用的值对象类型是命令,它表示系统必须响应的行动请求。

在实体的属性中,应优先使用值对象而非原始类型,以封装与值对象相关的验证或业务逻辑,例如质量不能为负(在大多数领域中!)。

聚合 / 聚合根

通常,我们需要跨多个实体进行验证以强制执行业务规则。

例如,“新用户的电子邮件地址必须唯一”。

为了执行这一规则,我们必须将提供的地址与现有用户的地址进行比较。我们通过在单个对象中构建聚合体,即实体和值对象的集合,以便在模型中实现此类验证。

聚合体中的顶级对象称为聚合根。聚合体内的对象的变更必须通过聚合根进行。聚合体可以引用其他聚合体,但只能通过聚合根的ID进行引用,以保持封装性。

领域事件

当我们与领域专家交流时,他们经常提到已经发生的事件及对这些事件的响应。我们使用领域事件及相应的处理程序来对此进行建模。

有时还包括集成事件,以区分应该在成功的数据库事务之前或之后处理的事件,尽管这也可以通过其他方式处理。

示例

上述四个结构是我们领域模型的核心构建模块,仅凭这些我们就可以对复杂领域进行清晰的建模。

例如一个订单聚合根的方法:Confirm()。在这个方法中,我们可能会验证订单包含一个或多个订单项,并且订单的状态为“待处理”,然后将订单状态更新为“已确认”,并触发一个OrderConfirmed领域事件。我们可以处理此事件,以在其他聚合根中实现副作用,如交付限界上下文中的出货聚合根。

仓储

在DDD中,仓储专门操作聚合根。它负责获取聚合根,在此我们可以调用一个公共方法来更改其内部状态,然后持久化更新后的聚合根。流行的ORM已经内置了出色的支持来处理这种场景。仓储的实现不在领域模型内部,尽管其接口/合同可能存在于领域模型中。

应用层服务

应用层服务将来自外部世界的命令/请求路由到我们的模型中。它们构成了一个薄的编排层,在这里注入基础设施问题(如仓储实现),并调用聚合根的相关公共方法。

需要注意的是,应尽量保持应用层服务的“简洁”,我们希望所有的业务逻辑都在应用的核心中。

领域服务

当我们必须在多个聚合体之间协调功能时,会发生什么?这是否构成“业务逻辑”?

是的!一种解决方案是领域服务。它类似于应用层服务,但位于核心领域内部。它包含构成业务逻辑的编排逻辑。通常,这一连串的事件通过领域事件及相应的处理程序表达得更好。

总结

如果你只会做基本的算术,数学是有用的。如果你会做张量计算,它也很有用,但你不会从张量计算开始。

以类似的方式,DDD是一门深奥的学科。有很多书籍从高度学术的到极其实用的都有。著名的《蓝皮书》是关于该主题的原始参考文献;它以相当学术的观点提供了对DDD的详细定义。相对的,《红皮书》讲述了三个开发团队在采纳DDD过程中的故事,使得DDD的概念变得自然且实用。对于听觉型学习者,还有许多启发性的演讲,如同事 Andrew Harmel-Law 的演讲。

关注我,紧跟本系列专栏文章,咱们下篇再续!

作者简介:魔都架构师,多家大厂后端一线研发经验,在分布式系统设计、数据平台架构和AI应用开发等领域都有丰富实践经验。

各大技术社区头部专家博主。具有丰富的引领团队经验,深厚业务架构和解决方案的积累。

负责:

  • 中央/分销预订系统性能优化
  • 活动&券等营销中台建设
  • 交易平台及数据中台等架构和开发设计
  • 车联网核心平台-物联网连接平台、大数据平台架构设计及优化
  • LLM Agent应用开发
  • 区块链应用开发
  • 大数据开发挖掘经验
  • 推荐系统项目

目前主攻市级软件项目设计、构建服务全社会的应用系统。

本文由博客一文多发平台 OpenWrite 发布!



声明

本文内容仅代表作者观点,或转载于其他网站,本站不以此文作为商业用途
如有涉及侵权,请联系本站进行删除
转载本站原创文章,请注明来源及作者。