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

日常产研迭代常见的问题

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

首先，针对业务价值方面

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

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

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

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

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

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

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

最后，软件的技术实现可能错误地改变软件原有的业务规则

需求交流的时候，大家彼此都没什么问题。但是，随着开发过程中的很多不确定因素，比如：临时插入紧急事情导致研发计划被打乱、研发时间大大超出合理范围、技术上无法对需求进行落地等等。那么最终交付的产品功能，有可能就跟需求交流时的设想大相径庭