谈谈DDD（领域驱动设计）

前段时间组织了小红花的新一期分享快速搞定数字化项目——采用领域驱动设计(DDD)建设一个电商平台，听完池总的这个分享之后，我终于是把这两年重新热起来DDD（以下称为现代DDD）和我十几年前熟悉的DDD（以下称为古典DDD）对应起来了，在这里谈一谈。

DDD当然不是什么新概念，该思想源于2003年 Eric Evans编写的“Domain-Driven Design领域驱动设计”简称DDD，Evans DDD是一套综合软件系统分析和设计的面向对象建模方法。从Wiki来看，

领域驱动设计（英语：Domain-driven design，缩写 DDD）是一种通过将实现连接到持续进化的模型来满足复杂需求的软件开发方法。

领域模型是对业务模型的抽象，DDD是把业务模型翻译成系统架构设计的一种方式，它倡导：

• 把项目的主要重点放在核心领域（core domain）和域逻辑
• 把复杂的设计放在有界域（bounded context）的模型上
• 发起一个创造性的合作之间的技术和域界专家以迭代地完善的概念模式，解决特定领域的问题

这个其实是非常自然的方式，现代和古典DDD里都是一致的，只要关注业务，必然是这样做。比如做一个电商网站，那么用户、支付、订单、商品等，就分放到不同的模块里，做一个网络游戏，那么关卡、道具、图形、AI，也会放到不同的模块里，所以DDD其实和业务领域无关，也和语言无关，它就是一种解决业务复杂性的设计思想，不是一种标准规则的解决方法。

在古典DDD里，承载业务模型的是模块，简单来说，就是Java/Python里的包（package），C/C++里的DLLs，它们都在同一个进程里，通过import/#include等关键字建立规范的关系，有些复杂的状况需要类似IoC之类的惯例（方法）来解决，有时候急眼了也会飞线（injection）的方法来做，毕竟大家本质上都还是在同一个进程空间，可操作的手段很多，所以时间长了，缺乏治理，最初的架构设计腐坏，也会乱作一团，另外就是各个业务模块面临的压力不一样，但脱离不了同一台机器，扩展性没有得到极大的尊重和释放，这都给DDD的发展埋下伏笔。

在现代DDD里，这个问题得到了解决。首先是性能问题，业务模块不再在同一进程空间，以电商网站为例，当双十一之类的高端来临时，电商详情浏览量极大，那么可以把图片等静态文件单独做成服务（CDN），因为它无状态也无写入，所以扩展性非常强，可以部署到不同的进程、机器、机房、城市和国家，性能问题得到很好解决，现在已经没有因为静态文件读取占用了业务服务器带宽导致整站停止服务的问题了。

受此启发，越来越多的模块拆分为服务，比如用户，往往一个平台的用户账号是多个业务通用的，至少实现了跨机房级别的扩展能力，订单可能扩展能力更弱一些，但也能跨机器。一开始的时候，云原生技术的发展降低了这些服务部署、扩展、发现和管理的难度，现代DDD应运而生。类似HTTP API和RPC等进程间/服务间通信技术代替了import/#include等API级别的集成，也使得业务建模手段更加丰富。

完全说现代DDD是新瓶装旧酒也是不合适的，思想虽然还是原来的，但生产工具的进步促进了生产力的发展，现代DDD无可比拟的强大扩展性富有极大魅力，值得学习和应用。