01 | 软件建模与文档：架构师怎样绘制系统架构蓝图？

作者回复: 1 架构师的核心产出是设计文档，工程师的核心产出是代码。当然架构师也需要写代码，工程师也可以做架构，当架构师写代码的时候，他的角色就是工程师，当工程师做架构的时候，他的角色就是架构师。所以，架构师是一个角色，而不是一个职位，当你承担架构设计这个角色，以产出架构设计文档作为你的核心产出的时候，你就是架构师。 2 这篇专栏中有一张架构的架构图，架构设计文档的价值是相关人能否从架构文档中得到自己想要的信息。文中多次写到，老板和客户看你的文档能否知道未来这个系统长什么样，需要多少台服务器。工程师看你的文档，能否知道未来开发怎么做，模块有哪些。文档就是蓝图，在工作没有开始的时候，大家就知道未来的工作该怎么做，做出来的东西是什么样。

编辑回复: 老师在思考题里提到的www.draw.io，或者亿图图示。都可以试一试哦

作者回复: 两个图样子长得很不一样，看起来不会混淆。 应用场景中，如果关注对象间交互，用时序图；如果关注一个业务的流程，用活动图。比如，描述一个处理逻辑的分支判断，不涉及到多个对象的交互，那就只能用活动图。

作者回复: 亿图

编辑回复: 有示例文章，我联系您

作者回复: 谢谢提醒，不同UML绘图软件虚实线不同，编辑的时候换了图导致文图不符。 删掉虚实线的说明，不重要。

作者回复: 是的，接口设计和库表设计是在详细设计阶段。 接口设计一般就是请求响应参数描述，不需要画图，而且因为变化比较频繁，建议单独写一个《接口设计文档》。库表设计可以用逻辑数据模型或者物理数据模型，不过这些模型UML不支持，需要使用其他建模工具，具体画法可以参考网盘设计一文

作者回复: 迭代需求如果只是在原有设计方案上修改、扩展一些小的功能，我认为不需要做设计。 文中的建议的设计文档是整个系统的设计，在立项的时候进行的设计，系统迭代维护的过程中，如果有涉及到架构重构、或者影响到架构的较大的新增特性开发，可以在原来的架构文档中进行修改。 类图挑选有代表性的画出来就可以了，如果都是CRUD，没必要都画。

编辑回复: 每周一、三、五各更新一篇正文~

作者回复: 本专栏所有设计案例都是样例文档