前提

本文需要以系列前文的逻辑链条和结论为前提，如果没有阅读过前文的，可以阅读合集《老肖的领域驱动设计之路》。

故事背景

在2020年，我所在的研发团队维护着一个有近十年历史的SaaS软件系统，而这个系统又是整个公司的主营业务，用户活跃度非常高。当时我们面临的最大挑战就是系统迭代速度远远无法应付客户需求，每次迭代发布都是如履薄冰，我们对系统已经到了完全失控的边缘。

彼时的我，对于领域驱动设计的认知，并不通透，只是隐约感觉DDD能够帮助我们走出这个泥潭，我们非常渴求改变，但缺乏确定性的验证，对于如何改变并走向成功，我们并无把握，甚至我们连如何衡量是否成功，都无法定义出来。在这样的背景下，我们仍然积极地为作出改变做准备：

常言道，机会是给有准备的人的，很快这个机会就来了。

2020年9月，在公司CEO的领导下，我们成立了独立项目组，目标是从零开始，重新打造一套新的SaaS系统，以替换旧的系统，而新系统的核心目标是"保持系统持续的快速迭代"，对你没看错，新系统的核心目标，甚至与产品功能、商业指标没有直接关系。

后来，我们一致认为这个目标，是我们关于软件工程和领域驱动设计的认知质变的起点，它把改变了我们在需求分析、产品设计、系统架构时的核心决策依据，即"可维护性是最重要的事"，这就使得我们在行进过程中，很多决策都与以往有所不同，甚至是相反的。

可以说，这个目标，改变了一切。

我相信，大家肯定都会有担忧，把"保持系统持续的快速迭代"作为首要目标，那么商业层面就不考虑了吗？其实并不是这样的，实际上这是一个"既要也要"的要求：

与过去不同的地方是当客户需求与可维护性冲突时，我们怎么决策：

我们认为这个转变意味着，整个公司的决策逻辑，从短期拓展到长期，追求更长期的利益价值，愿意放弃短期利益，而最考验团队的，就是我们是否真的可以拿到"可维护性"这个长期利益。

如果大家有读过之前《关于领域驱动设计，大家都理解错了》一文，应该还记得我们关于复杂度的认知：

因此，我们认为要掌控系统的可维护性，就必须实行分而治之的策略，将复杂度限定在一个个有限的范围内，这个逻辑正好与领域驱动设计的理念不谋而合：

于是，我们在这个由CEO发起的战略级项目中，开启了一段神奇的领域驱动设计落地实践之旅，为了确保最终结果符合预期，我们甚至建立了一条"不准跨域"军规，当然本文重点是推导DDD与软件工程之间的关系，关于"不准跨域"的故事，可以到这里查看：

【DDD落地的铁律军规 - 产品研发都得遵守-哔哩哔哩】 https://b23.tv/ukX0uIx

现今已经到了2024年的后半年，也就是说上述的项目，已经经历了大约四年发展和迭代，中途我本人也因为个人的一些因素离开了团队，最近我特地向朋友了解项目的近况，他也是项目的核心架构师之一，得到了肯定的答复：

再看看目前我自己所带领的团队，经历半年时间把一个项目从失控边缘拯救回来，发展到目前与业务保持一致，迭代维护不再有畏惧和负担感的状态。种种迹象都表明，领域驱动设计是至关重要的。

对于确定不迭代的系统，意味着可维护性的意义就不那么重要了，对于科研类或者其它领域的软件，可能要解决的更重要的问题是"技术难题"等其它维度的问题。

回归到主题，我一直在思考"DDD是软件工程的第一性原理？"这个问题，过往的这些经历，越发让我坚信这一点，但如果让结论更加严谨，需要限定条件如下：

在这样的背景下，那么标题的答案是肯定的：DDD是软件工程的第一性原理！

如果你认同本文的推导逻辑和观点，那么我相信你一定会期望了解如何掌握DDD，下一期，我们将讲述学习和实践DDD的最佳路径。