软件开发的本质
大多数普通人在听到“软件开发”这个词语的时候，会联想到这样一幅画面：一群穿着格子衫、桌子上摆着二次元手办的又瘦又高的眼镜仔坐在电脑前，对着屏幕上各种千奇百怪的代码敲打键盘，从白天直到黑夜。
这些给程序员加上的定语我们暂且不提，但软件开发并不是仅仅意味着编写代码。无论是在公司里上班，还是大学里几个伙伴的合作，软件开发的本质都是：编写代码来满足某种需求。公司雇佣程序员，是为了让程序员创造能够提升公司业绩的软件，进而满足公司盈利的需求；大学的伙伴合作，是为了创造一些好玩的软件，满足伙伴之间求知探索的需求。
由此我们可以看到，代码的编写是一种过程，服务于作为最终目标的需求。在软件开发中，需求占据了主导地位。
软件开发的难点
在软件开发中，人们往往会受到时间、成本、资源上的各种限制，或者是受到市场变化的影响，从而修改既定的需求。在软件开发的维护阶段，人们又经常会发现既有的代码设计难以让他们编写新的代码来满足新的需求。所有的这些问题都会导致生产效率的降低，进而导致公司的盈利空间的萎缩，程序员失业风险增加！
让我们看看一个例子：假如你是张三，老板给你下达了一个任务，让你编写代码，完成一个微信的投票小程序。当你信誓旦旦地接下了任务，埋头苦干了几天之后，老板突然告诉你：我们不做小程序了，能不能直接做成一个投票网页，DDL 不变行不行？你很可能无法说“不”，只能拼命想办法把现有的代码迁移到网页上。你会希望自己编写的一部分代码能够被直接复用，这样就不需要再重新编写。
因此，软件开发的难点在于：如何更好地适应不断变化的需求。
软件开发的救赎之路
自计算机诞生以来，前前后后几代的程序员都在不懈的探索这个难点的解决之道。在这个旷日持久的斗争中，人们将自己的实践经验总结下来，形成了一个个经典的编程范式。从某种意义上来说，这些编程范式就是一个个建模工具，对复杂多变的问题进行建模，从而得出一些普遍性的、不变的规律，进而简化人们的工作。
例如，我们在初中时学到：牛顿为了解释物体的运动，建立了经典力学模型，大大推动了人类天文学等学科的发展。类似地，在上世纪 80 年代，Smalltalk 的程序员为了解决桌面程序的代码过于繁复杂糅的问题，创造性地提出了 MVC 模式，为适应桌面程序中复杂多样的需求提供了一个优秀的工具箱。
MVC 模式全称 Model-View-Controller，将桌面程序划分为模型、视图和控制器三个层面，分别进行编码，使得程序员可以在同一个时间点仅关注一个层面的代码，符合关注点分离原则（SoF），同时写出的代码很容易符合单一职责原则（SRP），大大提升了程序员的编码以及维护的效率。
对那些还没有踏入企业工作的大学生来说，这些经典的编程范式也并非毫无价值，它们可以指导你作为一名程序员，将 if-else 摆放在合适的地方、将复杂的逻辑进行合理的分割等，别忘了，这些范式都凝结着老一辈的的程序员的宝贵经验。
我们今天要讲的 DDD 也是一种凝聚了几代程序员的心血的经典编程范式。它诞生于本世纪初，立足于改善当时 J2EE 或 Spring+Hibernate 等事务性编程模型只关心数据，造成失血模型不能很好地结合业务需求的问题。
在本节的末尾，我想引用一句史蒂夫·乔布斯的话：”设计并不仅仅是感观，设计也是产品的工作方式“。这句话不但阐释了他个人对设计的理解，也十分契合我们所讲的内容以及接下来将介绍的 DDD。在后文中，我会再次提到这句话，并向大家诠释 DDD 作为一种设计是如何塑造软件的工作方式的。