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