70 | 怎么写设计文档?
许式伟
该思维导图由 AI 生成,仅供参考
你好,我是七牛云许式伟。
在这个过程中,有两个阶段非常关键:一个是 “产品设计”,一个是 “架构设计”。产品设计由产品经理主导,关注的是 “如何以产品特性来系统化地满足用户需求”。架构设计由架构师主导,关注的是 “业务系统如何系统化地进行分解与交付”。
“设计” 一词非常精妙。无论是 “产品设计”,还是 “架构设计”,其实谈的都是 “需求如何被满足” 这件事情的共识。无论是 “产品文档”,还是 “架构文档”,它们都是设计文档的一种,都有团队内及团队间的协同价值。
上一讲 “69 | 团队的共识管理” 我们已经从团队的协同角度,谈了共识的重要性。本质上,我们也是在谈 “设计” 的重要性。换个角度来说,一个企业的使命、愿景与价值观,何尝不是这个企业最高维度的 “设计” 呢?
产品经理与架构师是一体两面,对人的能力要求的确会比较像,但是分工不同,关注的维度不同。产品经理关注的维度,其关键词是:用户需求、技术赋能、商业成功。而架构师关注的维度,其关键词是:用户需求、技术实现、业务迭代。
今天我们谈的 “设计文档”,重点聊的是 “架构设计文档” 怎么写,但是本质上所有 “设计文档” 的内容组织逻辑,都应该是相通的。它们的内容大体如下:
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
设计文档在现代软件工程中扮演着关键角色,涉及产品设计和架构设计两个关键阶段。产品设计关注以产品特性满足用户需求,而架构设计关注业务系统的分解与交付。设计文档内容包括现状、需求和需求满足方式。在多个设计方案对比时,易实施性、可维护性、时间复杂度和空间复杂度是关键考量。交付物规格和实现原理是设计文档的核心内容,而模块的详细设计和系统的概要设计在接口描述和实现原理上有所不同。文章强调了设计文档的重要性,提倡在设计阶段多花时间,以获得更大的回报。文章内容全面地补充了各类设计文档,包括产品设计、系统的概要设计等在细节上与模块设计文档的异同。
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《许式伟的架构课》,新⼈⾸单¥68
《许式伟的架构课》,新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(12)
- 最新
- 精选
- 沫沫(美丽人生)许老师,怎么理解DDD和模块划分的关系呢?
作者回复: ddd 强调的是按领域的业务分解,这个不是我们这个架构课翻来覆去强调的原则么。每个软件实体都有自己的业务边界,这就是领域。基于这种思想进行架构,就是ddd。
2020-01-0727 - Sruby请问详细设计的时序图是中的对象是类吗?如果是类是不是还需要在时序图之前增加类图说明下各个类的作用。
作者回复: 广义的数据结构就是你说的类图,也就是说定义完数据结构还不够,把数据结构的接口也描述出来。
2021-01-043 - 章皓许老师,模块描述上,“一个最小化的核心系统 + 多个彼此正交分解的周边系统”,如何理解正交分解,这一点重要吗,我在罗列出的多个周边系统上,应该有什么章法,如何才是满足正交分解
作者回复: 彼此正交就是相互没有直接联系,就算有相互作用也是通过核心系统的接口进行。这里面难点是最小单位的核心系统,需要足够通用的接口方法来保证。
2020-02-231 - 小风我们团队的设计文档会从几个方面着手:1)系统整体用逻辑架构、数据架构、运行架构、部署架构、开发架构五个视图来描述;2)各模块的领域对象模型和接口设计;3)对于核心模块,再次用以上用五个视图拆解细化设计,关键的流程或算法用时序图或伪码描述。常规的增删改查业务和非常简单的业务模块不会过多在文档上体现,一带而过,团队内部达成共识,有通用的解决方案。2020-09-0317
- Aaron Cheung提供像样接口文档的都少 因为接口更改了文档都没有人改……2020-01-0338
- WadeYu我呆过的中小型公司,没有一个有做系统设计文档的,我猜大部分公司都这样,最多功能开发好后,再写接口文档,有时候这步都省了2020-01-0318
- 亢(知行合一的路上)感觉详细设计相当于把伪代码写出来,有些地方是占位符,开发代码相当于做填空题。2020-04-124
- sswrock前面的画图「实战」需要亲自动手coding,踩 填各种坑 可以帮助更好理解; 这部分的「思想」需要反复阅读,持续反思琢磨2020-01-051
- ifelse学习打卡2023-10-13归属地:浙江
- 程序员Artist这篇很重要,但是设计文档的示范图还是少了一点呀2022-07-06
收起评论