小伙伴们，新年好！感谢大家对「 IT老兵哥 」原创文章的支持顶赞，❤️❤️❤️！把有价值的知识或经验分享给更多人，在分享中提升个人价值，这是我写作、分享的初衷和动力，在新的一年里我会更加努力，也希望能够继续获得各位小伙伴的支持！坚持原创不易，如果文章有价值，千万要记得手动点个「 ? 」哦，^_^
祝大家新年在家庭、事业和生活上都有新的进步，我们一起加油干！⛽️⛽️⛽️
年前我们一起聊了 程序员为什么要懂架构、架构是什么 和架构都有哪些类型 这三个话题，今天我们来看看架构师是怎样开展工作的，他/她需要对接上下游哪些角色，以什么作为工作输入，最终要对外输出什么产物。这些内容既有助于我们跟架构岗同事更好的协作，也可以作为是否往架构转型的参考，接下来我们一起揭开架构师的神秘面纱吧！
1. 架构设计的输入是什么？
软件系统最终要构建成什么样，这是由项目干系人的各种要求决定的。通常，我们将这些要求归集在产品需求文档之中，这份产品需求就是架构设计的输入。我们可以将这些需求划分为：
- 功能需求：完成某项业务需要的功能操作，例如：共享单车客户端软件需要支持单车定位、扫码解锁等。
- 质量需求：每项功能操作要达到什么样的质量要求，例如：易用性、可靠性、安全性、性能等等。
- 商业需求：软件系统需要以什么样的成本、迭代速度推向市场，如何提升产品的市场竞争力等等。
2. 架构师要对接哪些角色？
这些需求源自项目干系人、商业管理、商业竞争、法律法规、技术环境、政治约束和生命周期等不同维度的诉求，架构设计就是要区分这些需求的优先级权重，然后找出相对最优的方案来平衡满足各个方面的诉求，最终基于这个架构设计方案研发出相应的软件系统推向市场，并收集市场反馈输入到下一次迭代演化当中。
因此，架构在开展工作的过程中需要对接老板、产品、项目、开发、测试、安全和运营等各种岗位角色，他们都是架构需要关注和服务的内部客户，他们的痛点就是架构工作的驱动因素。
3. 架构设计的输出
- 关键场景（Key Scenarios）：分析产品需求并从中提炼出关键的业务场景，架构设计必须要通过这些关键业务场景的验证，例如：共享单车的关键业务场景包括：用户注册登录、支付账号绑定、单车租借归还等。
- 逻辑视图（Logical View）：为了实现关键业务场景，整个软件系统从逻辑上需要划分成多少个子系统。如果关键业务场景比作一幕话剧，那么逻辑视图就是出演话剧的主要角色，它是面向最终用户，对功能需求负责。
- 过程视图（Process View）：过程视图是以逻辑视图为基础的，逻辑视图是系统的静态结构，过程视图是系统的动态流程。如果把关键场景比作故事剧本，逻辑视图就是角色人物，过程视图就是让这些角色人物把故事剧本演练一遍，在该视图中每个角色人物的分工定位和交互关系都会被明确下来，集成人员可以根据它来验证系统。
- 开发视图（Development View）：通过逻辑视图、过程视图确定了子系统的划分和职责定位，开发视图就是明确每个子系统采用什么样的技术栈来实现，包括编程语言、开发框架、分层结构、项目工程等。开发视图主要是输出给编程人员，编程人员基于此就可以开始编码实现相关的工作了，所以说架构设计就是桥接需求和实现的。
- 物理视图（Physical View）：待构成整个系统的子系统都开发完成之后，我们需要将这些子系统部署到真实的物理环境当中，物理视图就是明确每个子系统需要什么规格的软硬件环境，分别部署到哪个网络区域，不同网络区域是否要开通防火墙，以及每个子系统需要部署多少个实例才能满足业务需求等，它主要是面向系统工程师。
4. 架构设计的工作流程
- 分析产品需求梳理出关键业务场景；
- 基于关键场景划分子系统，输出逻辑视图；
- 基于关键场景、逻辑视图确定业务交互流程，输出过程视图；
- 基于逻辑视图、过程视图确定子系统技术栈，输出开发视图；
- 基于逻辑视图、过程视图和开发视图确定部署方案，输出物理视图。
今天暂时先分享到这里，接下来我们还要继续聊架构，敬请关注哦。坚持原创不易，如果你觉得有价值，麻烦动动手指点下文 「 ? 」按钮，让更多小伙伴可以看到，老兵哥会更有动力坚持分享的。另外，我后续还会分享职业规划、应聘面试、技能提升、影响力打造等经验，欢迎 关注 本专栏或歪信公主号 「 IT老兵哥 」！
- 软技能-热门文章：（首发公众号）
- 2020 来了，你的 2019 晒好封存了吗？
- “花式”裁员套路深，你知道吗？
- 遭遇裁员，如何渡过心理危机？
- 如何在寒冬中找到好工作？
- 2C 还是 2B，跟找工作有什么关系？
- 大公司 vs 小公司，你会选哪个？
- 记住这一点，不怕找不到好工作！
- 跳槽，跳还是不跳，该怎么跳？
- 程序员“求包养”攻略揭秘
- 很努力了，为什么我还在原地踏步？
- 硬技能-热点文章：
