领域驱动设计的实践–CQRS&EventSourcing资源-CSDN下载

14 浏览量 2021-02-24 07:28:39 上传评论收藏 188KB PDF 举报

资源详情

资源评论

资源推荐

领域驱动设计的实践领域驱动设计的实践–CQRS&EventSourcing

1、前言

领域驱动（Domain – Driven Design）设计的理念在于建立一系列既符合软件所处领域本身又适合软件分析开发需要的领域模

型。命令查询与职责分离（Command Query Responsibility Segregation）和事件溯源（E、vent Sourcing）是为一种领域驱

动设计的实践。

本文旨在简要介绍CQRS & Event Sourcing，希望能够给大家在设计业务系统上提供一种新的思路和选择。

2、领域驱动设计

在开始介绍CQRS之前，有必要先了解DDD中的一些基本思想和概念。

各行各业都有业务系统和软件开发的需求。比如Fintech公司会开发贷款业务系统，证券公司会开发股票行情交易软件，旅行

社会开发在线旅游网站。虽然作为程序员，我赞成大家都能博学多才，上晓天文，下知地理。但是毕竟术业有专攻，做贷款业

务系统时，我们需要请教信贷专家；研发股票行情交易系统时，我们会和交易员一起讨论；实践旅游网站时，兴许我们需要请

教资深的旅行家……

那么当我们和领域专家围坐一起，高谈阔论之时，我们怎样才能做到有效的沟通，而不是鸡同鸭讲呢？DDD给了我们如下一

些启发：

1、确定的领域模型（Domain Model）

明确的领域模型是一切的基础。

一个良好定义的领域模型一般会有以下几个特点：

该模型应该包含所有来自领域专家的知识

该模型可以让开发团队很清楚的界定领域边界，并且判断知识的上下文一致性

开发者可以将该模型以代码的形式进行表述

该模型可以方便地应对来自领域的变化

2、通用的语言（Ubiquitous Language）

对于领域中的名词，概念，所有的开发者和领域专家会采用同样的词汇，并且有着同样的理解。

比如在支付系统中，“渠道”可以是“微信支付”，“连连支付”，而不是“工商银行”， “招商银行”。如果开发者和领域专家的理解不

同，那最后设计出来的产品势必南辕北辙。

3、实体（Entities），值（value）, 服务（Services）

实体：有一个全局唯一的标识，并且在整个生命周期中不变。

比如在支付系统中，一个交易（Transaction）就是一个实体。每个交易都有自己独有的交易ID。

值：值没有一个唯一的标识。比如在支付系统中。

交易的状态可以分为：“创建中”，“处理中”，“成功”，“失败”。　所以交易的状态就是一个值。

服务：除了实体和值之外，对于描述的动作，领域驱动的设计认为这是一个服务。

比如在支付系统中，与第三方支付绑定银行卡的行为，我们就可以认为是一种服务。

4、聚合（Aggregate）和聚合根（Aggregate Root）

相对于实体，值和服务是用来进行领域驱动设计中的建模模型。聚合和聚合根则是根据领域的原则分割并且描述实体之间的组

合。

想象一下，如果一个系统中有许多用户，每个用户都可以修改部分数据。那么如何保证数据的一致性问题：

当每一个用户修改数据时，将数据库中所有的表都锁定。确实，这样可以保证强一致性，但是这肯定不是一个用户体验好的系

统，并且性能十分糟糕

当每一个用户修改数据时，只将部分数据锁定。如此在用户的可用性和系统的一致性上能取到权衡

本内容试读结束，登录后可阅读更多

下载后可阅读完整内容，剩余3页未读，立即下载

评论0

内容反馈

weixin_38675970

粉丝: 5

最新资源

资源上传下载、课程学习等过程中有任何疑问或建议，欢迎提出宝贵意见哦~我们会及时处理！点击此处反馈

feedback-tip