DDD | 领域驱动设计初探

4,294 阅读2分钟

一起养成写作习惯!这是我参与「掘金日新计划 · 4 月更文挑战」的第2天,点击查看活动详情

DDD 不是大家常说的“带带弟”,而是程序猿傍身的正经好技能,DDD指的是领域驱动设计,是一种架构设计方法论,提供一种思想进行业务领域建模。帮助我们拆解业务、划分业务、确定业务边界,继而可以更好地实现技术架构的演进。

天启

2004年,DDD(领域驱动设计)这一软件开发的方法与愿景经由建模专家Eric Evans的经典著作《Domain-DrivenDesign:Tackling Complexity in the Heart of Software》,即《领域驱动设计:软件核心复杂性应对之道》正式面世,当即获得了广泛关注和高度评价。

image.png

Eric Evans这本《领域驱动设计:软件核心复杂性应对之道》固然前无古人,但也向我们程序员抛出了一大问题,即如何将DDD付诸于实践。十年之后,Vaughn Vernon的这本 《Implementing Domain-Driven Design》,即《实现领域驱动设计》也许为我们给出了答案。

在接下来的很长一段时间内,随着微服务、中台等概念的兴起,DDD的针对复杂软件的解决之道以及解决技术负债的天然能力,一时间使其炙手可热。

为什么会有对DDD的需求?为什么DDD会逐渐风生水起?

在商业组织中,主张“技术为业务服务”的企业总可以在理论上立于不败之地。诚然,DDD主张在软件项目中把领域本身作为关注的焦点(换句话说就是技术人员要懂业务)符合这种思想,但真正难能可贵的是,DDD提供了切实可行的应对软件核心复杂性的方法。

难点

实践DDD首先需要面对的一个(也许是最大的)难题是:难以描述的领域模型。 实践DDD是一个先苦后甜的过程,一个项目要不要采用DDD,最好先看看它值不值得。

启发

孔子说:“学而不思则罔,思而不学则殆”,只是通过编码实践来学习业务知识,却不从思想层面去思考这些业务知识,就会陷入无头苍蝇般的忙碌中,并夸大每个项目或产品的特殊性,在不相信“银弹”的路上走上极端。