[DAY28] 战略设计的别扭事件

上一篇提到，要深入了解需求，需要大量的沟通，对应到 DDD 中非常重要的一环——与领域专家一同开会。理想情况是，聚集所有利害关系人，透过事件风暴确认需求後再开发，但实际执行会遇到一些问题。

事件风暴效率低？

对工具还不熟悉时，事件风暴动辄就是1、2小时起跳，安排多人的长时会议不容易，更难办的是人多嘴杂，往往最後仍没有达成共识。

除了多练习事件风暴的流程，另一种解法是，透过对领域专家的访谈，来了解他们的想法，再由开发团队（包括实作人员 ）收敛成规格与实作细节，最後再去确认共识。虽然一样耗时耗人力，但在讨论的过程，开发者不但能针对程序中不符合领域专家想像的逻辑或概念进行优化，新开发的功能也能更加有效的解决问题。

没有领域专家该怎麽办呢?

不是每个需求都会有对应的领域专家，尤其在新创团队，新的商业模式没有可参考的案例，甚至是仍在探索阶段。

以团队的经验而言，让开发者越早和需求者开始沟通可以降低成本；因为开发者可以从另一个角度帮助需求者厘清领域，也可以在心中先有个底。

而从程序架构的角度来看的话，有几个可以遵循的原则：

• 变动机率高的地方（需求越不确定、或是越重要）架构设计越弹性
• 延後决策

下篇会回顾导入 DDD 後专案是否有改进。