需求与策略
这里可以举一个之前的例子。在一个查询A+B的页面，有一个字段叫"备注"的字段，A和B上都有备注字段，有的公司需要看A的，有的公司需要看B的。为了解决这个问题，一开始定的Solution是通过Office Rule来控制每一个公司显示哪个字段。最后修改成了，页面会同时查询出A和B的备注字段，用户可以自己配置页面的显示列来自定义需要看哪个字段，这样就省去了给已经非常复杂的Office Rule继续添加字段的工作。
需求的文档化
作者的观点是，最好的也是唯一需要的需求文档，就是可以运行的代码。
对于这个观点其实我不是特别同意，毕竟一个复杂的需求，看起来代码肯定不如文字来的快。而且我们查看代码的时候，总是要看下对应的Story来帮助理解。
对于需求，其实用户真正需要的是一个相对高阶的模糊的需求，而程序员更偏向于对细节感兴趣，庞大的需求文档就这么诞生了。用户对于非常详细复杂的需求文档肯定是不感兴趣的，对于这种沟通的最好的最好折中方式就是"用户故事"。它知识描述了整体应用的一部分应当做什么样的改动。
维护一张术语表
DD这个东西非常重要，而且提供方应当是BA。不然就容易让负责不同模块的程序员自由发挥，对后续的维护会造成很大的困难。之前参加了DDD的培训，老师也是着重强调了一个同一的术语对于DDD的开发是至关重要的。
网友评论