开发团队为什么需要DDD？
唐智
讲述：初明明大小：3.75M时长：04:06
此前，在由 ThoughtWorks 举办的领域驱动设计峰会 DDD-China 2019 上，InfoQ 记者就开发团队为何需要 DDD、目前业界实践 DDD 的挑战等问题对中兴通讯资深软件架构师张晓龙进行了采访。以下为重点内容。
张晓龙认为，开发团队真的需要 DDD。DDD 思想贯穿了整个软件开发的生命周期，包括对需求的分析、建模、架构、设计，和最终的代码实现，甚至对代码的测试与重构。代码是业务的核心资产，开发团队肯定是代码的编写者和守护者。
对于开发团队而言，需要关注以下几点：
第一，统一语言，让团队成员可以做到无障碍沟通，不管是什么角色都能基于同样的画面进行讨论；
第二，团队中各个角色都围绕领域模型开展工作；
第三，代码物理设计标准化，比如说在分层设计时，基础设施层怎么设计，应用层怎么设计，DTO 应该放在哪儿，领域层中各个建模元素如何组织？
更进一步，在分层架构中，应用层更加关注横切面的东西，比如上报告警、给用户发送 Email 等，这些最好都集中放到应用层里面。但触发是在领域层发生的，应用层怎么知道？可以通过领域事件来实现依赖反转，即应用层订阅领域事件，领域层发布领域事件。
在中兴通讯，核心业务属于通信行业，DDD 的应用场景跟互联网企业有着很大差别，中兴通讯的技术与业务兼具复杂性，其软件规模大，功能复杂，特性交叉，还有高质量、高性能、高可靠的要求。
张晓龙举例提到，中兴通讯在开发团队中实践 DDD 的经验具体而言有以下几点：
第一，领域专家下团队，和团队一起交流和协作；
第二，教练指导，开展战训营，定期 review；
第三，在架构、设计、编码和工程实践方面，不仅采用 DCI、DSL、正交设计、组合式设计，还要遵守编码规范和纪律，运用嵌入式 C/C++ 最佳实践，此外还要保证有持续交付的流水线和每日 Code Review。
DDD 的困局
最近几年 DDD 的火爆也给业界开发团队带来了一些迷思，比如，为什么我的 DDD 推行不下去？为什么我的 DDD 做起来总是跟敏捷一样，最后都变了味？
张晓龙总结了 DDD 目前面临的几大困局：
第一，领域案例面比较窄。目前业界的 DDD 实践案例并不多，而且很多案例是偏向互联网领域的，对于工业领域、嵌入式领域和操作系统领域基本没有涉及；
第二，DDD 书籍非常少，而且大多数书籍是以 Java 或 C# 写的。如果开发团队用的是 C、C++、Python 或 Go 语言，基本没有可参考的书籍，难度也就更大一些（尤其是 C 和 C++）；
第三，各个巨头公司，比如谷歌、微软、BAT 等，很少组织、参与或赞助 DDD 峰会，没有形成引导作用，业界自然也就少有跟随效应；
第四，开发团队要么找不到领域专家，要么领域专家无法与开发团队长时间保持沟通，导致实践中出现偏差；
第五，DDD 落地有一定的门槛，对开发者的技能和素质都有较高的要求。
针对以上几大困局，张晓龙也给出了自己的解决方案：
培训 OOA、OOD 和 OOP 的基本知识，并实战演练，不断弥补与高手的差距 ；
领域专家和团队一起工作，确保大家头脑中的画面是一致的；
DDD 建模要有文档交付物，并和代码同步演进，以便不熟悉代码的人员也能看到并理解领域驱动设计成果的全貌。
软件开发没有银弹，DDD 也不是万能的。如果开发团队真的决定用 DDD 的思想指导软件开发，就一定要跟随时代的脚步，吃透 DDD 这个旧瓶里装的新酒。
以上就是今天的内容，希望对你有所帮助。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(3)
- 最新
- 精选
xmeng6662
lane我说DDD 就是玄学，尤其战略，哪有那么多领域专家，战术 六边形是值得推荐的，然后加上面向对象 模式 和 代码检查插件 就行了
好片一锅端应该说明DDD能够解决业务和设计哪些痛点，比如复杂多变需求场景下如何发挥DDD的优势。
收起评论