当前位置: 代码迷 >> 综合 >> 【华为云技术分享】如何设计高质量软件-领域驱动设计DDD(Domain-Driven Design)学习心得
  详细解决方案

【华为云技术分享】如何设计高质量软件-领域驱动设计DDD(Domain-Driven Design)学习心得

热度:70   发布时间:2024-01-25 00:50:48.0

DDD做为软件设计方法于2004年提出,一直不温不火,最近几年突然火起来了,为啥呢?正所谓机会给有准备的人,因为微服务的流行,大家都跃跃欲试把传统单体软件转成微服务架构,但理论很丰满,现实很骨感,光是分解微服务就让人找不到北,而DDD是歪打正着也好,富有远见也好,正好适合微服务转型设计,不火都难。

最近学习了领域驱动设计(Domain-Driven Design),感觉受益匪浅,那到底啥是DDD呢?这里分享一下学习心得。网上有很多详细的资料,感兴趣可以看看这个https://www.infoq.cn/article/implementation-road-of-domain-driven-design。

个人理解:DDD首先是一种设计思想,所谓思想就是回答“设计的本质是什么,主要逻辑是什么”这类大的问题。DDD强调要从业务视角思考怎么设计软件架构,设计一定要知道业务是什么样子的,业务的需求和问题是啥,有啥内在逻辑,而不是从软件技术技术本身出发,这个对设计而言就是大的方向问题。虽然这个方向说出来好像没什么,但是实践上很多软件人员更多是从软件本身开始设计,一遇到业务问题就绕道走,所以强调从业务出发是这个方法最有价值的地方,这种梳理就称为战略设计。

DDD不只回答了方向问题,也提供一套方法,软件设计是个高度逻辑化的工作,需要概念特别清晰,推导过程有章法可循。DDD提供了对业务描述的一套方法,先对业务实体进行抽象,定义了一些软件设计概念,如实体对象,值对象,聚合对象,服务等,也提供了对象关系之间的描述。这部分对业务人员来说理解起来不容易,但是一旦理解了,对业务理解也就更深入了。前面根据业务把战略设计好了,就可以利用这些软件概念把业务逻辑映射成软件架构,这种过程DDD称为战术设计。 

DDD还是一种具体的实践指导,在实际工作中,组织跨部门讨论是很难的,软件兄弟抓业务人员讨论就更困难了,一是大家思维模式差异比较大,沟通自然比较困难;二是大家都忙,不一定好找人,而且找到了业务人员也没啥设计概念,当面讨论都难深入,别提电话邮件了效果就更差了。针对这两点,DDD首先干的一个事情就是把业务人员拉在一起,澄清概念,互相理解对方做的工作,这个方法DDD称为统一语言。其次DDD还开发了事件风暴方法,一步一步指导大家操作得出结论,为了有好的效果,操作指导具体到讨论时用什么颜色的标签纸。

对统一语言的重要性我觉得怎么强调都不过分,这个对业务设计太重要了。比如在故障定位的业务架构设计中,深入讨论后发现很多基本概念都是不统一的,例如TT故障单到底指什么?故障范围到底怎么定义,什么叫根因。如果这些都不明确,软件自然就不会有高质量。

但是事件风暴方法我倒是持半信半疑态度,半疑是因为这类操作方法和业务场景有关系,看起来方法适合短时间内收集业务需求,而我司业务人员和软件开发集成在一起,不一定这么死板操作。半信是因为目前讨论的确需要一个好的形式,说不定有效,当然实践上我觉得先分组输出再集成讨论也是一种选择。

另外说说翻译问题,大凡直译的文章都令人费解,例如中文PMBOK把项目翻译成一种临时性工作,怎么看怎么别扭。DDD 中Domain一词翻译成领域,直译没有问题,但不符合信达雅的原则,说起来很绕。DDD是从软件公司的通用软件架构师的视角来思考怎么设计软件的,对软件架构师而言,要给各行各业设计软件,这种情况最难的是啥,就是理解千差万别的行业领域,所以老外理所当然在方法中突出领域这两个字,不过按照中文习惯翻译成业务驱动设计会更好理解。还有Bounded Context翻译成限界上下文,本意是强调内部的事情内部解决,具体定义只在业务模块内有效。我更愿意把它翻译成组件,只是这个组件需要有明确边界和职责。

最后贴几页故障定位架构设计材料,大家感受一下实际的应用例子,按照高内聚低耦合的理念,TOP DOWN一步步分析业务,会很方便的导出软件架构。

作者:华为云专家 秦广溥

  相关解决方案