领域驱动设计(DDD:Domain-Driven Design)

Eric Evans的“Domain-Driven Design领域驱动设计”简称DDD，Evans DDD是一套综合软件系统分析和设计的面向对象建模方法，本站Jdon.com是国内公开最早讨论DDD网站之一，可订阅DDD专题。

过去系统分析和系统设计都是分离的，这种割裂导致：对需求分析设计的结果无法直接落地为代码，而能够运行的代码却无法完整实现业务功能，同时，软件Bug频出，维护升级重写难度大。

DDD则打破了这种隔阂，提出了领域模型概念，统一了分析和设计编程，使得软件能够更灵活快速跟随需求变化。见下面DDD与传统CRUD或过程脚本或者面向数据表等在开发效率上比较：

ddd

DDD革命性在于：领域模型准确反映了业务领域语言，领域语言是每个行业的行话，正如科学需要数学语言；算法需要编程语言；法律需要法律术语；绘画音乐建筑等也有自己的艺术语言，专业领域都有领域语言。

DDD最大好处是：接触到需求第一步是首先理解其领域语言，提炼出领域模型。DDD让你首先考虑的是领域语言（在特定上下文中的含义），落地的代码能直观映射到领域模型。

DDD难点在于Bounded Context（BC:有界上下文/限界上下文），关键是在于"Context"：

Context：Context is King已经成为现代认知最基本的共识之一
Context在中文里或指：上下文、语境、情况、环境、情境、场景、境地、范围、阶段、局限、背景、周期、顺势、作用域、范式、来龙去脉、路径、道、假设、前提、预设、第一性原理、原因...

中文没有专门Context单词，导致人们忽视其通用广泛存在；另外，认知缺乏边界感也是阻碍之一。

识别上下文是界定问题在哪里，在界定的上下文边界内进行符号推理是解决问题。什么是Context上下文？

DDD是解决复杂中大型业务系统的一套行之有效方式，DDD认为很多原因都会造成软件的复杂性，我们不可能避免所有复杂性，一个好的领域模型是控制复杂性的关键。领域模型的价值在于提供一种通用的语言，使得领域专家、产品经理和软件技术人员联系在一起，沟通无歧义。

DDD 的优势：

DDD 有许多组成部分和概念，以下是其中的一些概念：

个人观点：

事件=点、上下文=线、子域=面
线由点组成，建议从事件活动点开始，从下而上涌现中发现上下文。
子域的面由很多上下文的线组成。
由下而上设计流程：点->线->面；而不是由上而下设计：面->线->点
DDD建模是一个探索发现过程，无法从顶层设计开始
由上而下是一种科学还原论方法，认为事物由分子组成，分子由原子组成，只要找到所有原子就能组装成任何一个物体，其实很多物体现象是由原子之间相互作用才有的涌现属性，如果拆分成单个原子反而找不到这些属性，1+1>2，大于2的属性不属于俩个1，而是两个1组合在一起才有的。
事物由下而上涌现产生，如果你颠倒次序，由上而下学习复制，你以为这样的复制还是原来的那个事物吗？上下颠倒制造复制一个就是原来的那个吗？这是在做模具吗？不是，世界不是用机械模具复制出来的。

DDD落地架构有：Clean架构、六边形架构、 CQRS、Event Source几大大相关领域。下图是传统以数据库为中心的架构与使用DDD实现以领域为中心架构的区别。

服务器后端架构发展两个阶段：

UI+Service+DataBase的多层SOA架构（上图左），这种服务+数据表模型的架构易使服务变得囊肿，难于维护拓展，伸缩性能差，见这里讨论或Spring Web 应用的最大败笔
DDD+ 模块化单体或微服务：DDD作为数据建模的升级，主要贡献在于领域界线的划分，界定界限以后，通过两种架构实现领域模型代表的业务功能：模块化单体或微服务架构。

DDD专门为解决复杂性而诞生，因此解决思路完全不同于传统的CRUD，但是DDD本身掌握起来并不会感觉复杂，从程序员角度看，DDD其实是研究将包含业务逻辑的ifelse语句放在哪里的学问，包括业务流程、业务规则、规则引擎、术语字典、DSL或正则表达式、商业智能和数据分析等都属于业务逻辑的范畴领域。

如需要深入了，可继续阅读此文：https://zhuanlan.zhihu.com/p/641295531