领域驱动设计之从零开始

最近一段时间在了解领域模型,之前拜读了下《领域驱动设计——软件核心复杂性应对之道》,结果看的云里雾里,晦涩的语句,不明所以的专业术语,加上翻译导致的语句流畅性,可以说观看体验并不是很好。然后同事推荐我先看《实现领域驱动设计》这本书,但是对于这种软件设计的书,稍微之前那本好点了。以前都是“talk is cheap, show me the code”,加上自己在这方面没啥经验积累,看的过程中,没啥共鸣。

接下来主要是自己在看的过程中的一些笔记和理解。

领域模型之贫血模型和充血模型

贫血模型:Model中,仅包含状态属性,不包含个行为,采用这种设计时,需要分离出DB曾,左门用语数据库操作。现在的web软件开发主要使用的就是贫血模式。
优点:系统层次结构清楚,各层之间单向依赖,缺点是不够面向对象

充血模型:Model中即包含状态,也包含行为,是最符合面向对象的设计方式。
优点面向对象,缺点比较复杂,对技术要求更高。
Spring data 的 Repository 是对充血模型的最佳实践

领域、子域和限界上下文

在DDD领域中,一个领域被分为若干个子域,领域模型在界限上下文中进行开发。

限界上下文是一个显示边界,灵越模型便存在边界之内。在边界内,通用语言中的所有术语和词组都有特定的含义,而模型需要准确的反映通用语言。

架构风格

在选择使用框架时,需要明确其使用目的:建立一种可以表达领域模型的实现并且用它来解决重要问题。

分层架构

分层架构主要是给复杂的应用程序划分诚实。在每一层内分别进行设计,使其具有内聚性并且只依赖于它的下层。这种架构模式类似于MVC框架。

  • 用户界面层:负责向用户显示信息和解释用户指令。比如在MVC框架中,这一层主要指的是Controller层。
  • 应用层:定义要完成的任务,并指挥表达领域概念的对象解决问题。对应MVC中service。
  • 领域层:负责处理基本业务规则,比如事物回滚,业务逻辑等。
  • 基础设施层:为上层提供通用的技术能力,个人理解这一层在MVC中指的是比如数据库操作等这些基础功能。

事件驱动架构

六边形架构

CQSR

CQRS 就是平常大家在 讲的读写分离,通常读写分离的目的是为了提高查询性能,同时达到读/写的解耦。让DDD和CQRS结合,我们可以分别对读和写建模,查询模型通常是一种非规范化数据模型,它并不反映领域行为,只是用于数据显示;命令模型执行领域行为,且在领域行为执行完成后,想办法通知到查询模型。

REST

RESTful风格的架构将‘资源’放在第一位,每个‘资源’都有一个URI与之对应,可以将‘资源’看着是ddd中的实体;RESTful采用具有自描述功能的消息实现无状态通信,提高系统的可用性;至于‘资源’的哪些属性可以公开出去,针对‘资源’的操作,RESTful使用HTTP协议的已有方法来实现:GET、PUT、POST和DELETE。

聚合

聚合就是指一组相关对象的集合,我们把它作为数据修改的单元。每个聚合都有一个聚合根(root)和一个边界(boundary)。边界定义了聚合内部有什么,而根则是一个特定的entity,两个聚合之间,只能通过根引用去向深入引用其他引用变量。

例子还是沿用电商系统中的订单和商品模块。在聚合模式中,订单不能够直接关联到商品的规格信息,如果一定要查询,则应该通过订单关联到的商品,由商品去访问商品规格。在这个例子中,订单和商品分别是两个边界,而订单模块中的订单entity和商品模块中的商品entity就是分别是各自模块的root。遵循这个原则,可以使我们模块关系不那么的盘根错节,这也是众多领域驱动文章中不断强调的划分限界上下文是第一要义。

资源库

严格来说,只有聚合才拥有资源库。

管理事务

对于事务的管理绝对不能放在领域模型和领域层中。通常来说,与领域模型相关的操作都是非常细粒度的,以致于无法用于事务管理。

一般来说,事务的管理应该放在应用层。

博主 wechat
钟意作者
客官,赏一杯coffee嘛~~~~
0%