面试必问：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 的时间分成很多片段，每个片段只能执行某个进程中的指令。
• 进程间通信：为了解决进程在运行时相互通信的问题，人们设计了各种进程间通信，包括管道、消息队列、信号量、共享存储等。
• 多线程：多进程让多任务能够并行处理任务，但本身还有缺点，单个进程内部只能串行处理，而实际上很多进程内部的子任务并不要求是严格按照时间顺序来执行的，也需要并行处理。为了解决这个问题发明了线程，线程是进程内部的子任务，但这些子任务都共享同一份进程数据。为了保证数据的正确性，又发明了互斥锁机制。有了多线程后，操作系统调度的最小单位就变成了线程，而进程变成了操作系统分配资源的最小单位。

操作系统发展到现在，如果要完成一个高性能的软件