（一）DDD——字节一面挂了，面试官问DDD，我却不知道

本篇是DDD相关文章的第一篇，为什么要写DDD系列的文章呢？因为最近接到同学私信，说有机会面试字节，前面回答的还都不错，但是后面面试官问了他一些DDD的问题，他只是听过这个词，但是具体不太了解。最后面试没有通过，反馈就是技术比较扎实，但是领域架构方面了解得不足。挺可惜的。确实，在面试过程中，后面针对架构或领域思想的问题相当于拔高内容了，回答得好会很加分出彩，答得不好整体面试结果评分也不会太高。所以，思来想去，打算陆续出一些文章，根据自己对DDD相关著作的理解，进行整理+配图，让原本生涩的理论掀开面纱，展露出它原本美丽的模样。

日常产研迭代常见的问题

在介绍DDD（Domain-Driven Design：领域驱动设计）之前，我们先回顾一下，现阶段的产品迭代中常常出现的一些问题，以及这些问题会导致什么。通过对问题的总结和分析，再回头看一看，DDD能帮我们解决什么？

首先，针对业务价值方面

面对繁杂的业务需求和团队中良莠不齐的技术人员，如何确定哪些需求可以真正的传递业务价值？如何去针对业务价值高低进行需求优先级的排序？

其次，针对领域专家与开发人员之间的关系

在开发过程中，最大的鸿沟之一就存在于领域专家和开发人员之间。领域专家关注交付业务价值上，而研发人员关注在技术实现上。

即便让他们一同工作，他们之间的协作也是表面的，这时候，在所开发的软件中便产生了如下的一种映射：

• 将业务人员所想的映射到开发者所理解的。这样一来，软件便不能完全反映出领域专家的思维模型。
• 随着时间的推移，这种鸿沟将增加软件的开发成本，而随着开发者转到其他项目或者离职，本应该驻留在软件中的领域知识也就丢失了。

第三，针对多个领域专家之间的关系

当多个领域专家之间存在分歧的时候，他们各抒己见的对业务需求进行影响，而没有一个“地方”可以让他们坐下来统一分歧，然后“一致对外”。在这种分歧的情况下，会很大程度的导致相互矛盾的软件模型。