一文揭秘DDD到底解决了什么问题(1)

简介: 一文揭秘DDD到底解决了什么问题

image.png

DDD作为架构设计思想帮助微服务控制规模复杂度,那它是怎么做到的呢?


一、架构设计是为了解决系统复杂度

谈到架构,相信每个技术人员都是耳熟能详,但如果深入探讨一下,“为何要做架构设计?”或者“架构设计目的是什么?”类似的问题,大部分人可能从来没有思考过,或者即使有思考,也没有太明确可信的答案。


1.1 架构设计的误区

1.1.1 每个系统都要做架构设计/公司流程要求有架构设计

知其然更要知其所以然,不能仅仅因为其他公司都在做架构设计而盲目跟从,而应该深入理解架构设计的目的和必要性,根据实际需求进行合理的设计。如果架构师或设计师只是为了找点事做而进行架构设计,不仅会浪费时间和人力,还会拖慢整体开发进度。此外,其他公司的架构设计并不一定适用于当前项目,如果强行引入,很可能会导致架构水土不服、运行不流畅等问题,最终需要不断重构或者推倒重来。因此,架构师或设计师应该深刻理解为何要进行架构设计,避免生搬硬套,针对具体需求进行合理的设计,才能保证项目的顺利进行。

1.1.2 架构设计是为了追求高性能、高可用、可扩展性等单一目标

持有这类观点的人看似具备一定架构经验或基础,但实际上他们无论面对什么系统或业务,都会不顾一切地追求这些目标,导致架构设计变得复杂、项目实施时间拖延、团队内部不和等问题的出现。这些问题使得整个项目进展缓慢,系统稳定性差,出现问题难以解决,甚至加入新功能也需要花费大量时间。这些情况不是危言耸听,而是广泛出现的现象。因此,架构师或设计师必须深入了解系统和业务需求,根据实际需要合理设计,不可盲目追求“高XX”目标,才能确保项目开发进度和系统的稳定性。


1.2 架构设计的真正目的

整个软件技术发展的历史,其实就是一部与“复杂度”斗争的历史。架构也是为了应对软件系统复杂度而提出的一个解决方案,其主要目的是为了解决软件系统复杂度带来的问题。

那到底什么是复杂度呢?John Ousterhout教授在 A Philosophy of Software Design 书中提到,复杂度就是任何使得软件难于理解和修改的因素

复杂的系统有一些非常明显的特征,John教授将它抽象为变更放大(Change amplification)、认知负荷(Cognitive load)与未知的未知(Unknown unknowns)这3类。

变更放大(Change amplification)指得是看似简单的变更需要在许多不同地方进行代码修改。系统开发者之前没有及时重构代码,提取公共逻辑,而是省时间Ctrl-C,Ctrl-V式代码开发(这样做不会影响已有的稳定模块,不需要做比较多的回归测试,上线风险小)。当需求变化时,需要改动多处代码。

认知负荷(Cognitive load)是指系统的学习与理解成本高,开发人员的研发效率大大降低。

未知的未知(Unknown unknowns)是指不知道修改哪些代码才能使系统功能正确的运行,也不知道这行代码的改动是否会引发线上问题。这一项是复杂性中最糟糕的一个表现形式。


1.3 系统复杂度的六个来源及通用解法

本段参考 参考5

1.高性能 2.高可用 3.可扩展性 4.低成本 5.安全 6.规模

1.3.1 高性能

软件系统中高性能带来的复杂度主要体现在两方面:

1.一方面是单台计算机内部为了高性能带来的复杂度;

2.另一方面是多台计算机集群为了高性能带来的复杂度。

1.3.1.1 单机复杂度

计算机内部复杂度最关键的地方就是操作系统,计算机性能的发展本质上是由硬件发展驱动的,尤其是 CPU 的性能发展。而将硬件性能充分发挥出来的关键就是操作系统,所以操作系统本身也是随硬件的发展而发展的,操作系统是软件系统的运行环境,操作系统的复杂度直接决定了软件系统的复杂度。

操作系统和性能最相关的就是进程和线程。

  • 进程:用进程来对应一个操作系统执行的任务,每个任务都有自己独立的内存空间,进程间互不相关,由操作系统来进行调度。
  • 多进程:为了达到多进程并行运行的目的,采取了分时的方式,即把 CPU 的时间分成很多片段,每个片段只能执行某个进程中的指令。
  • 进程间通信:为了解决进程在运行时相互通信的问题,人们设计了各种进程间通信,包括管道、消息队列、信号量、共享存储等。
  • 多线程:多进程让多任务能够并行处理任务,但本身还有缺点,单个进程内部只能串行处理,而实际上很多进程内部的子任务并不要求是严格按照时间顺序来执行的,也需要并行处理。为了解决这个问题发明了线程,线程是进程内部的子任务,但这些子任务都共享同一份进程数据。为了保证数据的正确性,又发明了互斥锁机制。有了多线程后,操作系统调度的最小单位就变成了线程,而进程变成了操作系统分配资源的最小单位。

操作系统发展到现在,如果要完成一个高性能的软件系统,需要考虑如多进程、多线程、进程间通信、多线程并发等技术点,而且这些技术并不是最新的就是最好的,也不是非此即彼的选择。

在做架构设计的时候,需要花费很大的精力来结合业务进行分析、判断、选择、组合,这个过程同样很复杂。例如,下面的系统都实现了高性能,但是内部实现差异很大:

  • Nginx 可以用多进程也可以用多线程
  • JBoss 采用的是多线程
  • Redis 采用的是单进程
  • Memcache 采用的是多线程


目录
相关文章
|
6月前
|
数据库
DDD架构浅谈
DDD架构浅谈
139 4
|
设计模式 存储 缓存
初探DDD
基于学习《殷浩详解DDD:领域层设计规范》后的动手实践,简单总结,以及个人理解
|
运维 数据挖掘 测试技术
一文揭秘DDD到底解决了什么问题(4)
一文揭秘DDD到底解决了什么问题
101 0
一文揭秘DDD到底解决了什么问题(4)
|
存储 安全 大数据
一文揭秘DDD到底解决了什么问题(3)
一文揭秘DDD到底解决了什么问题
69 0
一文揭秘DDD到底解决了什么问题(3)
|
存储 负载均衡 算法
一文揭秘DDD到底解决了什么问题(2)
一文揭秘DDD到底解决了什么问题
105 0
一文揭秘DDD到底解决了什么问题(2)
|
存储 安全 大数据
DDD到底解决了什么问题
DDD作为架构设计思想帮助微服务控制规模复杂度,那它是怎么做到的呢?
21737 1
DDD到底解决了什么问题
|
存储 设计模式 运维
DDD的关键理解
当我们在学习DDD的过程中,感觉学而不得的时候,可能会问:我们还要学么?这的确引人深思。本文基于工作经验,尝试谈谈对DDD的一些理解。
DDD的关键理解
|
存储 安全 架构师
一文揭秘 DDD 到底解决了什么问题
一文揭秘 DDD 到底解决了什么问题
285 0
|
安全 程序员 微服务
DDD战略战术
DDD开篇总结》[1]的前三篇已经阐述了几个内容 1.DDD是什么2.复杂系统的特征3.DDD如何应对复杂系统4.模型概念5.软件开发流程 但一般DDD资料中都会分为两部分讲述:战略和战术,所以按这两种分类,重新归纳整合一下
371 0
DDD战略战术
|
存储 数据库
DDD之形
DDD现在已然变成哲学,正因为是哲学,所以法无定法,到底怎么具体怎么实施,各显神通,心法固然重要,但心法有几人能真正领悟,一说就懂,一问就不会,一讨论就吵架;所以还是从外形看看,收集一些实践后的形态,由表入里,以形学形,慢慢品 看下面两个分层,左边是Vaughn Vernon 在《实现领域驱动设计》一书中给出了改良版的分层架构,他将基础设施层奇怪地放在了整个架构的最上面;右边就是DDD最标准的分层形态
170 0
DDD之形