浅谈领域驱动设计

1 前言¶

在读领域驱动设计（DDD，Doamin Drive Design）时有很多的感悟，而且我发现很多实际工作中的一些设计思想在其中都被提及并且被以一种可说明的方式阐述，这给了我极大的触动。

这越发的证实技术的成长之路与人生无异，绝不能仅仅靠“碰”或试错去变强。去学习一些优秀的理论思想，并在实践中进行吸收进化，才是高效的成长之路。

这次DDD文章仍旧准备以系列文章推出，期望能给大家带来帮助。

2 误区¶

国外的程序员我并不了解，但国内的程序员们有挺多误区的，甚至在调侃中成为了主流思想。在谈DDD之前，我想先跟大家聊一聊几个重要的误区。

2.1 写代码才叫研发¶

这误区的行成于入行的初期，产生的后果极其致命。

很多人都觉得“只有当指尖在键盘上挥舞，一行行的代码从屏前蹦入眼帘时，才称得上开发”。我们不在乎开发的是什么？解决了什么？质量又如何？他们只想享受那个过程，并自豪的认为自己与众不同且价值不菲。

我们厌恶一切文档，认为编写文档不仅枯燥且毫无意义，不仅消磨了我们的意志还影响产品的交付进度。

以上的种种其实都是源于知识的匮乏。研发本是一个创作性的工作，却被硬生生的活成了搬砖工作，ctrl+c和ctrl+v成为技术的解决方案，成为了后期故障的借口。但这不怪我们，因为国内又有多少公司真的在乎“技术核心”的？，需要只是复制产品，而不是开创产品。庆幸的是，这在受到以漂亮国为首的国际势力打压下出现了转机，国内从上至下开始重视技术自主可控，未来的IT界必然是技术优先，人才优先的，短视的公司必然成为历史，无论它的规模如何。

那么什么才叫研发？大的是技术方案的提出者、制定者，而小的是技术方案的实施者，也许角色不同但他们都必须为结果负责，而结果的我很喜欢“敏捷铁三角”：

交付价值
保证质量
满足约束（时间、范围、成本）

它真该被刻入每一位研发的脑子里。

我们先谈谈“交付价值”，研发最最最重要的永远是“交付价值”，没有之一，这一点不光研发工程师需要知道，技术经理、项目经理也都应当清楚。技术是实践的产物，如果不能产生价值那么它的存在将毫无意义，因此如果你是在做一个能解决用户问题的产品，那么就应当以交付解决用户问题所需的产品功能为目的去努力，而产品是包括研发过程中产出的一切文档，程序以及最后运行的设备（如果需要的话），因此程序员是需要同时具备文档编写能力、程序研发能力以及设备调试能力的，而这样综合能力是需要一定知识作为支撑的，绝不是ctrl+c和ctrl+v可以做到的。

接着我们再谈“保证质量”，有多少程序员真的把质量作为研发的一部分的，无数的core仍旧唤不醒内心的那份责任。这里引用任正非说的一句话“每一个研发办公区的白板上都应该写上质量2字”，而我觉得，不愿保证质量的研发都应该被彻底封杀。

为了保证质量，我们需要有CI/CD的能力，单元测试的能力、系统测试的能力以及其他可调式的手段，这需要整个技术团队的共同努力，它包括研发团队、测试团队以及运维团队。

最后谈“满足约束”，开公司不是慈善，做产品也不是玩玩，任何项目都不能忽略“时间”、“范围”和“成本”的影响，因此技术的应用需要更灵活，不能为了追求高技术和无限推高“时间”和“成本”，也不能为了交付而无限的缩减“范围”，研发们需要学会时间折中、范围折中以及成本折中：

时间折中：我们可以通过提高内聚，降低耦合以保留重构空间，使用非最优解但能明显降低时间成本的技术方案，这样不仅降低后期优化或扩展成本，也为当前腾出足够的时间。
范围折中：在时间紧张的情况下，我们可以通过去除低优先级的需求来保证主需求的实现，以交付可使用的产品，在后续迭代过程中再根据需要去将那些去除的需求从新加回迭代计划。
成本折中：任何主体去开发产品，都是为了获利，因此控制成本是必须去做的。当出现成本高涨问题时，应当尽快识别出那些成本与收益不符的需求，及时剔除以保证产品的收益。如果整体产品在评估后仍旧无法满足成本控制需求，应当及时叫停项目以止损。

所以什么才叫研发？交付价值、保证质量、满足约束，它们就是研发工作的一个概述。

2.2 x语言第一语言¶

2.3 底层才叫技术¶

3 什么是上下文¶

4 如何识别上下文¶

引用¶

[1]: 《领域驱动设计 —— 软件核心复杂性应对之道》 [美] Eric Evans