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

对于做一个新软件项目的团队来说，应该做的第一件事就是绘制情境图（context map），帮助他们理解情境和核心领域是什么，以及他们可能需要与哪些其他情境交互。最重要的就是要让所有与开发这个软件相关的人员都对领域有一致的理解， Paul Rayner 是一位顾问和教练，作为对问题的回应，它说明了实施领域驱动设计的团队应该创建什么类型的文档。

Paul 以终为始，先理解为什么我们要创建文档；每种文档的目标是什么？ 考虑一下你的受众，并让你的文档适应他们的需要。读者是偏向技术层面还是业务层面呢，这是面向技术还是面向业务的文档呢？ 正如 Paul 写到： “尊重你的受众”。
另一个重要的问题与时间相关： 这个文档是要当前在团队开发软件的时候为其提供支持，还是要支持将来的开发？

对于支持开发中的团队的情况，Paul 建议持续记录文档（作为持续进行、即时、活动的文档）而不是创建（一次完成不再改变的）文档，那更可能会保持文档正确而值得信任。
对于将来的开发，Paul 考虑到，在代码、支持性测试或者其他产品特别是与文档相关的内容中找不到相关的知识。没有这种知识文档，就没有人真正知道系统最终会是什么样子。

Paul 发现敏捷团队通常更喜欢使用轻量级的方法，来描述系统需要做什么，而不喜欢更详细的需求说明书。详细说明书的一个问题在于，设计决定通常做出得过于匆忙，对领域和技术的知识都准备不足，从而使设计与实现分离。Paul 引用了 Mary Poppendieck 的话：

经常看到的现象是，详细的需求列表和故事的 backlog 实际上都是业余选手所做的很糟糕的系统设计。

BDD
Paul 是使用 BDD 工具来为系统创建实时文档的狂热分子。他倾向于使用 Cucumber 工具，因为它使用的方式可以把普遍的语言和技术实现分离开来。

Paul Rayner 是一位经验丰富的设计教练和领导力导师，擅长 DDD、BDD 和精益与敏捷过程。在 DDD Exchange 2012 上，Paul 发表了演讲： 驱动建模漩涡的领域场景

查看英文原文： Documentation Guide for Teams Doing Domain-Driven Design