见字如面，我是军哥！
前几天，我和朋友架构师伦哥讨论关于公司里是否用 DDD 的问题，我觉得挺好玩，每个人都有自己的观点，对于 DDD 很多人陌生或看了网上资料对于DDD 的使用场景介绍和本质还是了解的不够深，容易人云亦云。
大家来看看我们讨论，一定对你理解 DDD 有非常大的帮助！
架构师伦哥：最近真是头疼。产品经理跟催命鬼似的，要不停的新功能，产品每次上新功能像修一堆bug。感觉自己天天都在加班，累得跟狗一样。
我：这说明业务在飞速增长啊，是好事啊。。
架构师伦哥：业务增长是不错，但现在团队用的是微服务架构，一个小组管好几个服务，新功能一来就往里塞，乱得跟麻花似的。这样下去真不行，看来得引入DDD，搞搞领域驱动设计了。
我：我劝你还是别碰 DDD 的好，实施 DDD 一定得满足四个条件，否则你大概率你们团从一个坑跳到另一个坑，而且 DDD 的坑巨多。
架构师伦哥：不会吧，我研究了DDD，看了好多视频，也看好多相关书籍，觉得挺好的。大公司都在用，通过领域和界限上下文识别，实体、值对象、聚合、服务什么的，能把业务流程和要素理得清清楚楚。对开发肯定有好处呀。
我：DDD的好处是肯定的，但首先得满足第一个条件，DDD的前期投入大，收益是后期的事。如果公司业务还在摸索阶段，重点是快速试错，需求来得快、变得也快，DDD可能跟不上。
架构师伦哥：这个我懂，我们公司虽然不是行业老大，但业务已经过了摸索阶段，现在主要是优化用户体验，扩展新功能。
我：那你们满足实施DDD的第一个条件了。第二个条件，DDD鼓励各部门用统一语言建模和沟通。光你们团队想搞DDD不够，得公司层面支持，基于DDD理念规范沟通方式，设计和产出，各部门通过事件风暴等方法识别业务领域和界限上下文，然后分配任务。这不是你们一个团队能搞定的。
架构师伦哥：这个我还真没细想，我就想着把手头的需求做个领域划分，分析分析实体、值对象什么的。如果DDD还涉及到职责划分，那肯定得各部门领导支持，我们一个团队哪能决定做啥不做啥。
我：对，DDD 要求公司架构支持灵活的职责划分和协调。第三个条件，团队执行层面也有挑战，DDD不是具体框架和工具，虽然 SpringBoot 全家桶提供了一些支持组件，但怎么做好业务领域设计还是挑战，需要开发人员深刻理解DDD 的核心思想，同时掌握面向对象编程，才能做好详细设计、服务分层和规划。不然就是空谈概念，最后还是写出一堆面条代码。
架构师伦哥：这要求有点高啊，既要部门协作，又要团队成员精通。
我：刚才说的三个条件还不够，还有第四个条件，最重要的是企业文化的支持。
架构师伦哥：军哥，你一向很实际，怎么今天说起这么虚的东西了？
我：因为这关系到KPI考核，比如项目进度、个人绩效什么的。DDD有前期投入，怎么评估项目进度，业务方可能嫌你慢。或者你团队辛苦一番，服务划分、可扩展性、稳定性都做好了，不用加班了，怎么让团队的工作得到领导的认可也是个大问题。
架构师伦哥：看来 DDD 还真不是随便能碰的，从公司到部门再到个人，各方面都得准备充分才行呀。
我们的讨论结束了，你有什么观点？欢迎评论区留言。
最后，我最近弄了一个架构群，讨论业务架构，基础架构，云原生，安全，支付，AI、区块链，全链路测试测试架构，技术管理等备领域知识，如果你感兴趣，加我微信备注架构，我拉你入群哈～
目前已经有近 100 人加入。
如果你已经在群里，请忽略～
如果你发现加的人太多加不上的话，请加这个微信（jeff_cheng02）
综上，希望今天这篇文章对你帮助！
全文完，觉得我说的不错的话点个赞或者在看吧！
以往热文推荐：
更多精彩，关注我公号，一起学习、成长
扫一扫
502
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
