DDD是软件工程的第一性原理？
本文书接上回《DDD建模后写代码的正确姿势》，关注公众号（老肖想当外语大佬）获取信息：
-
最新文章更新；
-
DDD框架源码（.NET、Java双平台）；
-
加群畅聊，建模分析、技术实现交流；
-
视频和直播在B站。
前提
本文需要以系列前文的逻辑链条和结论为前提，如果没有阅读过前文的，可以阅读合集《老肖的领域驱动设计之路》。
故事背景
在2020年，我所在的研发团队维护着一个有近十年历史的SaaS软件系统，而这个系统又是整个公司的主营业务，用户活跃度非常高。当时我们面临的最大挑战就是系统迭代速度远远无法应付客户需求，每次迭代发布都是如履薄冰，我们对系统已经到了完全失控的边缘。
彼时的我，对于领域驱动设计的认知，并不通透，只是隐约感觉DDD能够帮助我们走出这个泥潭，我们非常渴求改变，但缺乏确定性的验证，对于如何改变并走向成功，我们并无把握，甚至我们连如何衡量是否成功，都无法定义出来。在这样的背景下，我们仍然积极地为作出改变做准备：
-
我们对自己的客户和业务有比较充分的了解，技术甚至跟着产品经理一起去拜访客户
-
我们打造了一套定制的开发框架（也就是现在DDD框架的早期原型），以更准确地用代码表达业务
常言道，机会是给有准备的人的，很快这个机会就来了。
一个改变一切的目标
2020年9月，在公司CEO的领导下，我们成立了独立项目组，目标是从零开始，重新打造一套新的SaaS系统，以替换旧的系统，而新系统的核心目标是“保持系统持续的快速迭代”，对你没看错，新系统的核心目标，甚至与产品功能、商业指标没有直接关系。
后来，我们一致认为这个目标，是我们关于软件工程和领域驱动设计的认知质变的起点，它改变了我们在需求分析、产品设计、系统架构时的核心决策依据，变成“可维护性是最重要的事”，这就使得我们在行进过程中，很多决策都与以往有所不同，甚至是相反的。
可以说，这个目标，改变了一切。
有什么不同之处
我相信，大家肯定都会有担忧，把“保持系统持续的快速迭代”作为首要目标，那么商业层面就不考虑了吗？其实并不是这样的，实际上这是一个“既要也要”的要求：
-
要保持系统持续的快速迭代
-
要满足客户需求
与过去不同的地方是当客户需求与可维护性冲突时，我们怎么决策：
-
过去：选择满足客户
-
现状：选择保持可维护性
我们认为这个转变意味着，整个公司的决策逻辑，从短期拓展到长期，追求更长期的利益价值，愿意放弃短期利益，而最考验团队的，就是我们是否真的可以拿到“可维护性”这个长期利益。
DDD是正解
如果大家有读过之前《关于领域驱动设计，大家都理解错了》一文，应该还记得我们关于复杂度的认知：
-
系统复杂度与元素的数量和元素的关系有关；
-
元素的关系对系统复杂度的影响远远大于元素的数量所产生的影响；
因此，我们认为要掌控系统的可维护性，就必须实行分而治之的策略，将复杂度限定在一个个有限的范围内，这个逻辑正好与领域驱动设计的理念不谋而合：
于是，我们在这个由CEO发起的战略级项目中，开启了一段神奇的领域驱动设计落地实践之旅，为了确保最终结果符合预期，我们甚至建立了一条“不准跨域”军规，当然本文重点是推导DDD与软件工程之间的关系，关于“不准跨域”的故事，可以到这里查看：
【DDD落地的铁律军规 - 产品研发都得遵守-哔哩哔哩】 https://b23.tv/ukX0uIx
项目的现状
现今已经到了2024年的后半年，也就是说上述的项目，已经经历了大约四年发展和迭代，中途我本人也因为个人的一些因素离开了团队，最近我特地向朋友了解项目的近况，他也是项目的核心架构师之一，得到了肯定的答复：
-
项目目前仍保持较好的可维护性，迭代没有陷入过去那种困局
-
中间也经历过做一些不太符合长期利益的需求
-
可维护性是靠团队不断坚守业务、模型、代码边界清晰和一致性获得的
-
业务、模型边界清晰不意味着与满足需求对立
再看看目前我自己所带领的团队，经历半年时间把一个项目从失控边缘拯救回来，发展到目前与业务保持一致，迭代维护不再有畏惧和负担感的状态。种种迹象都表明，领域驱动设计是至关重要的。
第一性原理
对于确定不迭代的系统，意味着可维护性的意义就不那么重要了，对于科研类或者其它领域的软件，可能要解决的更重要的问题是“技术难题”等其它维度的问题。
回归到主题，我一直在思考“DDD是软件工程的第一性原理？”这个问题，过往的这些经历，越发让我坚信这一点，但如果让结论更加严谨，需要限定条件如下：
-
软件系统是长期迭代的
-
软件系统是业务向的系统
在这样的背景下，那么标题的答案是肯定的：DDD是软件工程的第一性原理！
后续
如果你认同本文的推导逻辑和观点，那么我相信你一定会期望了解如何掌握DDD，下一期，我们将讲述学习和实践DDD的最佳路径。
