DDD起源
DDD,为 Domain-driven design 领域驱动设计的简写,一句话概括,就是:软件代码的结构应该要和业务领域相匹配。
我们先来看看在软件架构演变历史中,DDD是怎么发展起来的,如下图:
(图片来源于我的博客IT宅(itzhai.com,公众号:Java架构杂谈)的另一篇文章:架构演变之路:为何要搞微服务架构?)
-
早在60年代就有了OOP,这个时候,人们就开始意识到面向过程的编程模式对于构建大型软件不太友好,于是开始探索以现实世界的对象的方式去思考编程;
-
直到了1982年,出现了OOAD(面向对象分析和设计),为OOP的落地提供了指导思想,同时作为解决复杂的业务场景的利器;
-
2000年之后,随着计算机渗透到越来越多的行业,以及互联网的兴起,软件的复杂性增加了,如何应对日趋复杂的软件呢?这个时候,
Eric Evans
写了一本书:“Domain-driven Design: Tackling Complexity in the Heart of Software” (领域驱动设计-软件核心复杂性应对之道),促使人们开始以业务模型去思考软件的设计。但是,人们并没有立刻认识到领域模型的重要性,反而觉得这种软件思想太过于复杂了,于是DDD继续沉睡; -
在2013年,
Vaughn Vernon
写了一本关于DDD的书籍:“Implementing Domain-Driven Design”(实现领域驱动设计),提供了一个DDD落地的指导思想,让人们对DDD更加触手可及了; -
诸如
DDD
和EIP
之类的软件设计自2003年左右就已经开始实践起来了,此时一些团队将应用程序开发为模块化服务,并促使了微服务架构的诞生。-
微服务架构的产生,需要相关技术的支撑,随后的几年,大家把玩各种微服务技术,玩的不亦乐乎:RPC、服务网关、负载均衡、配置中心、消息中间件、分布式任务调度、服务容错、日志监控、DevOps…似乎掌握了这些技术,就离技术的天花板更进一步了。随着微服务技术的不断发展,人们发现每次升级微服务技术,都要对系统进行大量改造,有什么方法可以把业务代码和技术代码更加彻底的隔离开来呢?
-
与此同时,随着业务的演变,人们不断痛苦的拆分微服务。一不小心,拆分过细,导致业务开发更加复杂了。这个时候,人们才开始思考:怎么才能更加合理的拆分微服务呢?
-
终于,大家把目光投向了今天的主角:DDD。
DDD的设计目标:
- 基于领域模型的复杂设计;
- 将项目主要重点放在领域和领域逻辑上;
- 启动技术专家和领域专家之间的创造性合作,不断的迭代改进特定领域问题的概念模型。
基于DDD的设计思想,我们开始把目光回归到软件的核心:业务,开始思考如何让技术更好的为业务服务。
某种程度上来说,面向对象、DDD的思潮,掀起了微服务的狂潮,同时人们在微服务中踩到的技术和服务拆分的坑,促使人们重新意识到DDD的价值。
DDD是万能的吗?
DDD不是银弹,建议将其用于复杂业务,使得可以更好的制定域的通用术语,降低业务的理解难度。
对于简单的业务,DDD不仅不能体现DDD的优势,反而会让开发工作变得更加复杂。
另外,对于探索性的新业务,由于业务模型不能明确下来,也不建议使用DDD,否则会面临不断大力度重构业务领域的问题,导致新业务进展缓慢。在领域知识体系尚未建立的情况下,单体架构可以实现快速开发和迭代。