对DDD的第一次解读

微信扫一扫,分享到朋友圈

对DDD的第一次解读

图来自网络

软件架构的终极目标:最大化程序员的生产力,最小化运营的总成本。

前奏

目前我在看两本书《领域驱动设计精粹》和《实现领域驱动设计》,前一本比较薄,不到150页,后一本就非常厚实了,有500多页,那么读起来可能就会显得有点心理障碍,但如果要想更多了解DDD,还是要以第二本为主,第一本可以作为概要性阅读。

领域驱动设计,类似**驱动,我们也接触过不少,比如测试驱动,敏捷驱动等等。领域驱动设计,这六个字或者在前面再加上业务两字,业务领域驱动设计,最终的目标都是为了设计服务的,那么设计是设计的什么,肯定是应用程序系统架构,那么应用程序系统的架构有什么样的需求呢。

架构有两种需求:功能性需求和非功能性需求

功能性需求就是我们在使用一个系统的时候所接触到的,所用到的诸多功能,比如发布一个商品,展示一个统计报表,做权限的管理和控制等,代表的是一个应用程序系统架构能做什么。

非功能性需求是我们的这个应用程序系统架构是否做到了可监控、可扩展、是否高可用、高性能等,代表的是一个应用程序在运行时的质量。非功能性需求中,还有一个非常重要的点就是:快速安全的交付软件。

那么我们就随着如何快速安全的交付软件说起。 DDD重要的指导思想之一是将业务人员和研发人员拉在了一起。 敏捷开发的周期内,无论需求梳理会、回顾会还是计划会都没有业务人员的影子,总是研发和产品在交流。


在业务建模之后技术人员来考虑如何快速且安全的交付软件产品

随着软件架构的逐渐成熟,在我们已经认识的AKF立方体中,在X轴的服务器水平复制,和Z轴的数据分库分表,这两个方向上我们的技术都已经相对成熟,使得我们在抗住大访问量方面已经不再被动。

但唯独在Y轴这个方向上,业务对应服务的拆分,和应用程序被要求快速的交付,我们始终没有太好的解决方法。

而DDD正是致力于在这个方向上为软件开发人员做指导的 ,利用DDD如何快速的交付软件。

因为这是我的DDD学习笔记第一篇文章,就花费了上面的篇幅来做个浅显的对DDD的理解引入描述。接下来我主要谈一谈DDD学习中的战术设计中的一种:运用领域事件进行战术设计。

事件产生于核心域

领域驱动设计中涵盖的内容基本是两大内容,战略设计和战术设计,领域事件是属于战术设计的范畴内的。

那么是先有的事件还是现有的领域呢,我个人认为在动作发生关系上,是先有的事件,已经存在发生过去一段时间了。

比如我们在利用事件驱动开发的时候,常常借助的中间件就有很多,ActiveMQ、RocketMQ等等。后来我们有了领域的概念认知,那么就开始使用领域的思维来去思考事件:领域事件。

如今借助了领域的概念,我们相当于换了一种思考方式,好比 “横看成岭侧成峰,远近高低各不同”,最终都是山,但 “成峰” 的时候可能更能便于我们理解和认知我们的业务关系,我们就使用 “成峰” 的角度去思考。

假如在一个月前我还没有接触领域事件,上面也说了我们一直在用消息机制(消息中间件)解决问题。那么现在我开始学了领域事件给我带来什么变化或者新的认知呢。

首先,我觉得是统一了语言:领域事件,好比古人一手取了一根木棍,另一只手又取了一根木棍,两只木棍来回摩擦,生出火来。这件事情很伟大,但描述起来就比较费劲, 后面就有人总结说了叫做:钻木取火 ,这样传播起来就方便了,大家一听到钻木取火就知道是什么意思。

领域事件也是如此,因为之前毕竟你已经有了领域上下文的知识。

总结

没有DDD,我们业务中也是已经存在了边界,关系,交互,有了DDD之后,我们是依靠或者借助其帮我们梳理这些业务关系,划清业务边界,形成独立性、自治性、弱耦合的系统。

当我们阅读相关DDD书籍里面描述的对象和实践时候使用的对象,都没有变,那些对象都是一直存在的。但是,我个人认为DDD是一种思考业务问题、架构问题的方式, 学习了DDD知识以后就可以采用“DDD的思维方式”去理解和处理那些我们在工作中已经存在的对象。

但也要明白,它绝不是解决一切问题的银弹。

DDD就是一种工具,好比是一把剑,也可能有另外一种工具XXD,好比是一把刀,至于是剑厉害,还是刀厉害,主要看你使用的熟练程度。

参考书籍 《领域驱动设计精粹》和《实现领域驱动设计》 和《架构整洁之道》

Go语言系列(三)之数组和切片

上一篇

罗永浩:录制《脱口秀大会》吸引了很多女粉 实现了多年以来的目标

下一篇

你也可能喜欢

对DDD的第一次解读

长按储存图像,分享给朋友