DDD的组织转型路线图
大家好，我是范钢老师。时间过得真快，《DDD落地深水区》的这个系列又经过了好多篇文章，从架构决策、组织规划，到整洁架构的设计实现。通过这些文章，让大家身临其境地去感受，当你在实际项目中，在实践DDD时，你所面临的难题、你应具备的思考过程、你的抉择，以及最终的设计。然而，所有这些都是在架构层面的，即决策软件本身该如何设计。但开发一套软件系统的关键因素不仅仅在于软件本身的设计，还在于人，那些开发者，一个一个的团队，该如何去组织他们，有条不紊地按照DDD的规范开展开发工作，一行一行地编写代码，把整个系统设计开发出来。因此，今天我们就换一个角度，从组织管理的角度探讨，DDD该如何落地转型。
前面我们谈到，DDD的真正优势不在于开发新项目，因为新项目的业务并没有那么复杂，DDD的优势发挥不出来。DDD的真正优势在于维护老项目，当很多老项目随着业务的变更而变得越来越复杂，维护成本越来越高时，团队就希望能够转型DDD。通过引入DDD领域驱动设计，运用领域驱动的思想来梳理和规划业务需求，挖掘与探索未来的业务；通过领域模型来指导高质量的软件开发，以降低运维成本，提升研发速度，起到降本增效的作用。
然而，从传统的软件开发模式，要转型到领域驱动的开发模式，不论从研发人员的设计理念，到整个研发的流程管理，都是一次巨大的转变。从设计理念上，要求研发人员从过去只关注技术，向着更加深入地理解业务转变。领域驱动的设计思想认为，研发人员只有更加深刻地理解业务，才能开发出客户真正感觉好用的软件系统。业务理解越深，开发出来的软件才越专业。基于这样的设计思想，需要通过调整研发管理制度与流程，让研发人员能够更好、更早地参与到对业务需求的理解与讨论中。
譬如，前面探讨过，在敏捷团队中引入事件风暴会议，以及在非敏捷团队中引入原文分析法等建模方法。不论采用哪种方法，殊途同归，都是在需求分析与设计开发之间增加一个过程：领域建模的过程。通过这个过程，以开发人员更加熟悉的方式去学习和理解业务，从而开发出更加专业，让用户更趁手的软件系统。
在这个过程中，与研发团队相关的产品经理、需求分析、架构师，其职责分工、工作方式、产出物，都将发生巨大的变化。很显然，DDD的组织转型，就是要通过改变团队的组织形式与开发流程，去适应这种改变。
正因为如此，我建议期望DDD转型的公司或团队，通过“小步快跑”的方式，先从小范围实践开始，由简入深、循序渐进地逐步导入领域驱动的设计方式，最后再逐步扩大，最终推广到整个公司的软件研发。在这个过程中，逐步摸索，最终建立起适用于领域驱动的研发流程与制度规范。
小范围团队实践
1. 情况调研
在领域驱动导入的初期，可以通过筛选，选择几个基础比较好、积极性高的团队进行小范围的实践。在这个过程中，选择合适的团队尤为重要。可以通过一个调研，对各个研发团队进行摸底。哪些团队尝试过DDD？哪些团队对学习新事物有积极性？以及这些团队开发的业务系统是什么技术架构？是否采用了微服务的技术架构？让最初的转型更加容易和顺畅。这些方面都可以成为选择与考量的基础，毕竟万事开头难。
2. 知识导入
选择好了实践团队以后，首先需要对他们进行领域驱动的知识导入。DDD是有学习门槛的，领域驱动的设计思想，领域建模的设计过程，以及如何落实到数据库的设计、微服务的设计，都需要学员仔细学习与掌握。
3. 实战演练
在知识导入的基础上，马上就开始进入实战环节。是骡子是马，要拉出来遛遛。空对空地去学习基础知识是没有意义的，要通过实际的项目真实地去演练领域驱动设计的整个过程。在演练过程中，需要相关的不同角色，包括产品经理、需求分析、架构师，甚至测试人员，以角色扮演的方式全程参与。
1）演练新项目的开发过程
虽然DDD更适合维护老项目，但一上来就开始进行老项目的改造，并不是一个值得提倡的做法，毕竟走都没有学会就开始学着跑容易闪着腰。把现有的软件项目中的一部分当成新项目来练手，是一个不错的选择。
每个团队选择自己所开发的软件系统，但暂时忘掉现有的设计，仅仅只有需求文档的情况下，模拟新项目的开发。在当前需求文档的基础上，让产品经理、需求分析、架构师与研发人员一道，召开事件风暴会议，测试人员参加旁听。通过事件风暴会议，在产品经理、需求分析、架构师的帮助下，由研发人员最终完成过去没有完成的领域建模，并不断细化。在这样的基础上，产品经理与架构师还可以站在更高地层面去规划，各个业务系统的定位与相互的交互，进而重新地去梳理与思考，甚至发现一些与过去完全不同的分析与设计。
在第一个阶段领域建模的基础上，研发人员开始基于领域模型完成数据库设计、微服务设计、程序设计等后续工作。与此同时，测试人员根据需求开始编写测试脚本。在这个过程中，架构师为他们做好技术支持，并制订开发规范。
通过以上的分析与设计，最终得到的是目标架构，就是未来我们期望的那个，基于DDD设计的、更加优化、更易于维护的架构。后面会基于这样的基础，与现有的架构进行比较，制定可行的改造计划，逐步将现有系统向DDD转型。
2）需求变更的开发过程
DDD的作用不仅仅在于开发新项目，更重要地是维护老项目。实践团队在模拟新项目开发的基础上，根据以往的情况开始模拟需求变更的过程。当拿到变更需求以后，产品经理、需求分析、架构师与研发人员一起，基于之前的领域模型进行新需求讨论，最后形成领域模型的变更。接着，研发人员根据领域模型的变更，进而更新数据库、微服务、程序代码，最终实现新需求。
在这个过程中，实践团队一边在模拟变更的过程，一边也在思考和制定未来需求变更与维护的制度与流程，并在未来的实战中不断演进和优化。譬如，当需求变更到来时，与过去不同的是，我们应当首先对领域模型进行分析、设计与变更，然后再指导程序的设计与变更。
4. 制订改造计划
以上的演练，是研发团队暂时忘掉了当前系统而进行的设计演练，但DDD最终是要落实到实际项目中的。因此，实践团队在以上演练的设计成果的基础上，对比现有系统的设计，制订更有利于DDD转型的项目改造计划。在这个过程中，架构师应当更好地起到整体规划、规范设计、方案优化的重要作用。通过以上的改造计划，逐步让实践团队今后能够按照DDD领域驱动的方式去设计开发新功能，并维护变更现有功能，完成DDD的转型。
5. 制订开发规范
在经过以上实践团队的不断实践与摸索，在QA等相关管理人员的帮助下，逐步制订出适用于DDD的产品研发流程与规范，特别是与现有制度相结合的流程与规范，并不断地演进与优化。
6. 搭建开发平台
DDD要能够顺利落地，搭建一个支持DDD与微服务的开发平台，尤为重要。前面多篇文章都提到了这个平台的设计开发思路。采用DDD以后，不应当使开发变得更繁重，而是变得更轻松，才能得到研发人员的认可，使推行更加顺畅。因此，在以上DDD实践的过程中，架构师要带领一个平台开发团队，将DDD中那些比较繁重而冗余的Controller、Repository、Factory等代码，都抽象并下沉到底层平台中，并支持微服务间的远程装配。
相关链接：
大范围的经验推广
在以上实践团队的基础上，公司将能够逐步总结出一套适用于自身的开发规范与平台支持。在时机成熟以后，就可以逐步推广到其它的项目与产品线。但不同的项目与产品线，因自身情况的不同，实践DDD可以选用两种方式：
1）仅领域建模型
我们永远需要考虑问题的复杂性与多样性。一些较早的老项目，由于自身技术架构的约束，不能按照DDD的要求落地到开发编码。这时，可以将DDD仅作为业务需求梳理的工具，完成前期领域建模的工作，但不映射到最终的程序开发。
2）完整实践型
另一些基础较好的项目，只需要进行一些有限的改造，就可以完全满足DDD转型的需要。这种情况，就可以参考之前实践团队的经验，制订相应的改造计划，向DDD逐步转型。
总之，DDD转型，理想很丰满，现实很骨感。我们永远需要在未来的收益与现实的成本中进行折中，选择一个性价比最大的方案，理性地做出抉择。
然而，也有同学提出了不同的意见。在AI智能大模型席卷的今天，现在谈DDD还有什么意义？未来人工智能是替代整个人类，还是成为我们提高生产力的工具？我认为是后者。未来人工智能不能替代人，却能代替我们完成更多低层次的编码工作。然而，人工智能不是无所不能，而是需要我们人从更高的层次给它提需求、制定编码规范、监督它的工作。
因此，未来更加需要精通DDD的人，更加需要通过DDD为人工智能制定规范，让人工智能更加高质量地去编码。而我们则基于DDD的规范，去深入理解需求、指导人工智能的设计，并以此来规范和监督它的工作。所以，在AI智能大模型的浪潮中，DDD不是已死，而是将迎来全新的发展。后面我将通过另一个系列文章，为大家讲解AI时代的DDD落地实践，敬请期待。
如果对以上内容感觉有用，欢迎关注、点赞、转发！
（待续）
扫一扫
825
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
