领域驱动设计之认知篇

这篇具有很好参考价值的文章主要介绍了领域驱动设计之认知篇。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

学习DDD的意义

作为技术人,都有一个成为大牛的梦。

有些人可以通过自己掌握了比较底层、有深度、有难度的技术来证明自己的能力。

但对于绝大多数的应用研发工程师来说,其大部分的时间精力,会被消耗在读不懂、讲不清的屎山代码中,以及复杂多变的业务迭代中。很少会有需要去接触高深技术的机会,即便是接触了,也很少有实践应用的机会。

所以对于应用研发工程师来说,提高架构设计的能力,预防屎山代码的产生,高效、高质的应对多变的业务需求,便是证明自己能力的关键。而DDD便是一个从业务层面指导架构设计的较为完备的理论体系。

领域驱动设计之认知篇

 文章来源地址https://www.toymoban.com/news/detail-482323.html

DDD诞生的背景

这里我想从我个人的理解,分享下DDD产生的背景。(个人见解)

我们都了解,软件诞生之初,就是几个简单的指令,那时候写代码,真的就是写二进制,通过纸带打孔的方式来交给机器运行。

随着发展,软件指令变得多样,软件也变得复杂,便又有了软件研发上,从汇编语言到高级语言,再到面向对象编程的产生。

软件本身功能的强大还不够,为了应对社会的发展变化,就要求软件自身有更好的扩展性,这便有了设计模式、设计原理等理念的产生。

在社会普遍信息化的今天,软件更是被普及应用在了在各行各业、各种领域。软件面临的复杂度,不再仅仅是技术方案本身的复杂度,更多的是要面对软件所属行业、所属领域的业务本身的复杂度。前者我们称之为偶然复杂度,后者我们称之为本质复杂度。DDD便由此产生。

DDD,中文名字叫领域驱动设计,"领域"一词,表示的是一个业务范围。它强调从业务角度去设计软件。

经典DDD书籍《领域驱动设计:软件核心复杂度应对之道》,这里所说的软件核心复杂度,应该指的就是上文说的本质复杂度吧。

DDD为什么难学

DDD诞生之初,是一个纯粹的理论体系,它包含了各种复杂且难以理解的概念。

在接下来的发展中,又有追捧者根据自己对DDD的理解,发展出不同的落地方案,比如:六边形架构、洋葱架构、CQRS、ES、整洁架构等。这就使得DDD的知识体系更加复杂。

再加上DDD理论本身并不是一个放之四海皆准的方案,需要具体场景具体判断,这就大大提高了DDD的学习应用门槛。所以我经常开玩笑说:DDD最大的价值就是用来吹牛逼。

领域驱动设计之认知篇

 

DDD的核心目的

与设计模式在实际研发中的应用一样,DDD的应用也需要我们在合适的场景选择合适的设计。那么如何判断场景合适与否呢?

要回答这个问题,需先搞清楚,DDD的设计理念的核心目的是什么。

DDD标榜自己是治理核心复杂度,但我想问,复杂度为什么需要被治理?复杂度可以通过治理被降低吗?

首先,复杂度为什么需要被治理。这是因为人的认知能力是有限的,当事物的复杂度超出一定范围,就会给人带来认知负荷,阻碍人们对事物的理解。

其次,复杂度能否被降低。个人更倾向于Linus Torvalds所认为的:复杂度并不会因为被治理而降低。比如操作系统,虽有各种设计,但依旧复杂。毕竟要实现的功能摆在那。

复杂度虽然不能被降低,但我们可以通过一些手段,比如分离关注点、封装屏蔽细节等,来降低复杂度给人们带来的理解上的难度。

所以,我更相信,与其说DDD是治理核心复杂度,不如说DDD的核心目的是提高系统的可理解性。

了解了DDD的核心目后,我们就可以通过这样的方式来判断,在某个场景下是否适合引入DDD的某个理念:引入DDD的设计理念后,系统(代码)是否更清晰、更易理解。

这里还需要强调的是:DDD是提高可理解性的手段,可理解性才是核心目的。当在某个场景下,该手段不能帮我们提高可理解性时,那就果断放弃。千万不要为了用DDD而用DDD。

领域驱动设计之认知篇

 

关于可理解性

可理解性,也就是我们搞清楚一个事物的难易程度。

其重要性不言而喻:一个难以理解、难以搞清楚的系统,一定是一个难以维护的系统,其迭代效率一定是较低的,Bug率一定是较高的,质量绝对是堪忧的。

根据熵增理论,一个系统如果没有外力的干预,一定会变得越来越杂乱。伴随着系统的杂乱,人们对系统的理解也会变得越来越困难。

所以,个人觉着系统的可理解性的重要性绝不亚于可扩展性,甚至优先级高于可扩展性。

那么DDD有哪些比较关键的手段来提高系统的可理解性呢?我认为有这么几个比较关键的点:统一语言、领域分解、领域建模。

统一语言,它通过边界清晰的、完整一致的抽象命名,来降低人们的认知负荷。犹如人类将所依赖的食物一致的划分为蔬菜、水果、粮食等。

领域分解,它通过分治的手段,实现关注点的分离,从而降低认知负荷。比如,计算机包括了CPU和内存等模块,当你想要搞清楚计算机是如何实现计算的。你只需要把注意力聚焦在CPU上,而几乎不需要被其他模块的实现细节所干扰。

领域建模,它利用面向对象的设计,较为直观的映射业务现实,从而提高可理解性。比如,地球仪就是对地球的建模,如果想清楚的了解地球,地球仪一定比地图更直观。

总结

个人认为,学习一门技术,首先要搞清楚这门技术能帮我们实现什么目标,解决什么问题。接下来才是学习这门技术的具体手法和技巧。只有这样,我们才能在一个清晰的目标下,有目的、有选择的甚至是优化改进的,应用这些手法和技巧。

所以本文主要是认知篇,介绍了DDD的背景和难点,以及重要的DDD能够帮我们实现的核心目标:提高系统的可理解性。

有了本文章的铺垫,下篇文章,我将重点介绍DDD中,那些比较重要、比较有价值的手法和技巧。

 

 

到了这里,关于领域驱动设计之认知篇的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 《领域驱动设计》:从领域视角深入仓储(Repository)的设计和实现

    一、前言 “ DDD设计的目标是关注领域模型而并非技术来创建更好的软件,假设开发人员构建了一个SQL,并将它传递给基础设施层中的某个查询服务然后根据表数据的结构集取出所需信息,最后将这些信息提供给构造函数或者Factory,开发人员在做这一切的时候早已不把模型看

    2024年02月08日
    浏览(72)
  • DDD领域驱动设计(六)

    领域对象需要资源存储。存储手段多样化,常见就是数据库,分布式缓存,localCache.资源库的作用,就是对领域的存储和访问进行统一管理对象。在抽奖平台中。通过下面这种方式组织资源库。

    2024年01月24日
    浏览(60)
  • 领域驱动设计四论

        经过多年的研究与思考,实践与总结,本人逐渐对 DDD 有所领悟,本文以一个较短的篇幅,提纲挈领地梳理出 DDD 的核心脉络,希望与各位做一探讨。 1776 年亚当斯密发表《国富论》,标志着经济学的诞生。2004 年,一本名为《领域驱动设计·软件核心复杂性应对之道》的

    2024年02月08日
    浏览(41)
  • 领域驱动设计入门指南

    ​ 领域驱动设计(Domain-Driven Design,简称DDD)是一种软件架构风格,它强调在软件开发过程中紧密关注业务需求和领域知识。本文将简要介绍领域驱动设计的核心概念,帮助人开始学习和实践领域驱动设计。 什么是领域驱动设计? 领域驱动设计是一种软件开发方法,它侧重

    2024年02月11日
    浏览(27)
  • 05.领域驱动设计:掌握领域事件,解耦微服务的关键

    目录 1、概述 2、领域事件 2.1 如何识别领域事件 1.微服务内的领域事件 2.微服务之间的领域事件 3、领域事件总体架构 3.1 事件构建和发布 3.2 事件数据持久化 3.3 事件总线 (EventBus) 3.4 消息中间件 3.5 事件接收和处理 4、案例 5、总结 1、概述 在事件风暴(Event Storming)时,我们

    2024年02月22日
    浏览(38)
  • 领域驱动设计&事件驱动框架&命令查询责任分离&测试驱动开发

    领域驱动设计: DDD 事件驱动框架: Event Driven Architecture 命令查询责任分离: CQRS(Command Query Responsibility Segregation) 测试驱动开发: TDD 入口是系统外部客户访问系统内部的端口。常见的入口如http, rpc, 命令行,外部消息(消费kafka,rocketmq或者zk, etcd的通知消息)。 入口的职责:解析外部

    2024年02月04日
    浏览(33)
  • 领域驱动设计(Domain Driven Design)之建立领域模型

    在实际项目中,模型设计者往往过早陷入具体构造块类型的识别,比如实体、聚合、领域服务,而忽略了领域模型表达领域概念的目的。我们应该基于领域概念设计领域模型,然后再采用合适的模式降低领域模型的复杂度,进一步增加领域模型的表达能力。 领域模型的作用,

    2024年02月03日
    浏览(28)
  • 领域驱动设计实践框架-COLA的解读

            Cola作为当前比较优秀的领域驱动设计最佳实践框架越来越被更多的技术人所知晓。先抛出COLA 4.0:应用架构的最佳实践_张建飞(Frank)的博客-CSDN博客_cola架构 是关于COLA4.0最新的内容介绍。然后个人对于读了这篇文章后,对于其中的架构理念和其中的各组件的设计加

    2024年02月03日
    浏览(25)
  • 聊一聊对领域驱动设计中“领域”这个词语的理解与分析方法

    百度百科对领域的解释: 领域具体指一种特定的范围或区域 领域一般指的是业务的问题域,领域是有边界的,边界内,规定了我们要做什么,要做的范围,软件项目从开始到交付的过程中, 所有涵盖的业务,每个业务模块或者方向都有自己的业务范围和问题 比如做家装行业

    2023年04月14日
    浏览(32)
  • 领域驱动设计DDD实际项目落地最佳实践

    领域驱动设计(Domain Driven Design,简称:DDD)设计思想和方法论早在2005年时候就被提出来,但是一直没有被重视和推荐使用,直到2015年之后微服务流行之后,再次被人重视和推荐使用。 下面我来介绍一下DDD设计思想和方法论,同时结合我们在实际项目中应用总结和思考。 目录

    2024年02月08日
    浏览(42)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包