这些都搞不明白，还想要落地DDD, 像话么？

文末赠书，千万不要过！

开发大型软件最难的部分并不是实现，而是要深刻理解它所服务的现实世界的领域。领域驱动设计（Domain-Driven Design，DDD）是一种处理高度复杂领域的愿景（Vision）和方法，它主张在软件项目中把领域本身作为关注的焦点，维护一个对领域有深度认知的软件模型。

领域驱动设计（DDD），其实就是以领域模型驱动软件设计。要理解 DDD，关键是理解什么是 DDD 所指的领域模型，但在此之前，还是应该先认识一下软件开发的过程。然后，基于此认识重温一下 DDD 在战术以及战略层面的若干关键概念。

2004 年，DDD（领域驱动设计）这一软件开发的方法与愿景经由建模专家 Eric Evans 的经典著作Domain-Driven Design: Tackling Complexity in the Heart of Software 正式面世，当即获得了广泛关注和高度评价。17 年间，网上越来越多关于 DDD的文章和讨论。为什么我们现在还不停地讨论 DDD？为什么DDD仍然如此重要？

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

实践证明，DDD 提出的方法不仅行之有效，而且历久弥新。

关于“产业互联网即将进入黄金时代”的说法，大多是众多传统企业希望借力最新的信息化，特别是互联网工具（即所谓“互联网+”），提升内部效率和对外服务的能力。传统产业中的很多领域概念和业务流程并不一定为普通的开发者所熟知——这与“消费互联网”不同，显然人人都是消费者。所以，传统产业的信息化急需可以快速梳理并深刻地认知领域，以及能构建高质量领域模型的技术人才。DDD 可以说是技术人员升职加薪的“神兵利器”。

我在工作中看到的情况是，越来越多的技术人员在自己的求职简历上写上了“熟悉（或精通）DDD”的描述。确实，Eric Evans 的经典著作以抽象、凝练著称，可谓字字珠玑，甚至很多资深技术人员都不能领悟其中玄妙。所以，我也认同掌握 DDD 是一件足以让技术人员引以为傲的事情。

可以说，DDD 是公认的解决软件核心复杂性的“大杀器”。但是，在软件开发中实践 DDD 是需要付出相当大的成本的。也就是说，大家的普遍看法是：实践 DDD 是一个先苦后甜的过程，一个项目要不要采用DDD，最好先看看它值不值得。

但是一个项目值不值得使用 DDD 有时不好判断。大项目往往是由小项目发展而来的，很多从小项目演化而来的大系统最终变成开发团队的噩梦，噩梦的根源几乎无一例外地在于软件的概念完整性遭到了破坏。而DDD正是维护软件概念完整性的良药。如果在项目中实践 DDD 的成本不高，那么即使是小项目，从一开始就使用 DDD 不是一件很美好的事情吗？

在软件开发项目中实践 DDD 到底有何难处？

实践DDD首先需要面对的一个（也许是最大的）难题是：难以描述的领域模型。DDD 想要构建的领域模型是什么？按照 Eric Evans 的观点，领域模型不是一幅具体的图，而是那幅图想要传达的思想；不是一个领域专家头脑中的知识，而是那些经过严格组织并进行选择性抽象的知识。

听起来是不是有点玄奥？系统分析师、产品经理到底要拿出什么样的领域模型才能说“我的工作已经做到位了”？这个模型到底是不是可以实现的？开发人员、测试人员到底有没有理解这个模型？大家的理解是不是一致的？

说到底，一个领域模型要想有用，它必须足够严格。如何使用一种严格的方式描述经过严格组织并进行选择性抽象的知识呢？

问题的答案很自然地指向了 DSL。

其实，Eric Evans 早就意识到了这一点。他曾经在访谈中说：

更多前沿的话题发生在领域专用语言（DSL）领域，我一直深信 DSL 会是领域驱动设计发展的下一大步。现在，还没有一个工具可以真正给我们想要的东西。但是人们在这一领域比过去做了更多的实验，这使我对未来充满了希望。

可以告诉大家的是：在项目中运用 DDD 可以不像大家想象的那么痛苦，DDD 并不是只适用于大项目，使用 DDD 并不一定需要牺牲敏捷性，一切的关键在于 DSL 的运用。

我和我工作过的团队曾经在多个项目中使用 DSL 实现了 DDD 的真正落地。独乐乐不如众乐乐！现在，我把这些实践经验写在了《深入实践DDD：以DSL驱动复杂软件开发》一书中分享给大家。

《深入实践DDD：以DSL驱动复杂软件开发》

内容简介

关于作者