BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 Jan Stenberg 关注 34 他的粉丝 ,译者 侯伯薇 关注 0 他的粉丝 发布于 2013年5月31日. 估计阅读时间: 2 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

对于做一个新软件项目的团队来说,应该做的第一件事就是绘制情境图(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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT