领域驱动设计团队文档指南

  一个团队在启动一个软件项目时首要的事情就是画一个上下文图，以帮助他们理解项目的背景和他们的核心领域，以及了解他们可能需要与之交互的其它环境。最重要的是在每个涉及到软件开发的人之间达成一种对领域的共识。Paul Rayner,咨询师、教练，解释了正在进行领域驱动设计的团队应该创作什么样的文档。

  Paul以终为始，理解为什么我们要编制文档，每个文档服务的目的是什么？考虑你的听众并使你的文档适用于他们。读者是偏向于技术还是倾向于业务方面，这是面向技术还是面向业务的文档？正如Paul所写：“尊重你的听众”。

  另一个重要的问题就是时间处理：文档是打算支持现在开发软件的团队，还是支持未来的发展？

  为了在开发期间支持团队，有利的文档（作为一种持续的、及时的、活跃的）更可能保持文档的正确性及可信度，而不是那些一次性和一篇应付所有的文档。

  为了未来的发展，Paul考虑通过那些在代码中没被发现的知识来支持测试或是其它产品，尤其是与文档相关联的。没有这种知识记录，没有人真正了解系统是怎样以它自己的方式结束的，知识丢失了。

  Paul也发现敏捷团队更喜欢轻量型的方法来描述系统需要做的，而不是更细节的需求规约。详细规约的一个问题在于设计决策通常很快被制定，在没有充分的领域知识与技术知识下，设计与实现被分离了。Paul引用了Mary Poppendieck的话：

  经常是，详细的需求列表与大量的故事迭代实际上是业余人员所做的坏的系统设计。

  BDD行为驱动的开发

  Paul是一个热衷于使用BDD工具来为系统创建生动文档的粉丝。他偏向于Cucumber这种工具，因为它鼓励分布式语言与技术实现的分离。

  Paul Rayner是一个经验丰富的设计教练和领导导师，专攻于DDD、BDD及精益/敏捷流程领域。