恰如其分的设计
愿景
是什么
：创建并交流团队展开工作的愿景。
怎么做
：语境、容器和组件图。
恰如其分的设计
结构
是什么
：理解主要的结构元素，以及它们如何基于架构驱动力组合在一起。
怎么做
：设计并分解为容器和组件。
风险
是什么
：识别和缓解最高优先级的风险。
怎么做
：风险风暴和具体的实验。
4
理解技术领导力的方式
，在其独特的环境下量化所需的预先设计
。
定义一个高层次结构，设定愿景，这很重要；在开始编码之前，绘制无数个类的详图，则多半不重要。搞清楚如何解决怪异的性能需求很重要，搞清楚每个数据库字段的长度就不太重要。
在范围之内你可以用任何一种xDD和你喜欢的敏捷实践来构建软件。
测试驱动开发，http://en.wikipedia.org/wiki/Test-driven_development
。
行为驱动开发，http://en.wikipedia.org/wiki/Behavior-driven_development
。
领域驱动设计，http://en.wikipedia.org/wiki/Domain-driven_design
。
责任驱动设计，http://en.wikipedia.org/wiki/Responsibility-driven_design
。
对我来说，原因很简单：你需要思考架构的驱动力
（影响最终软件架构的重要事情），包括下面这些。
功能需求
：需求驱动架构。不管怎么捕捉和记录需求（比如，用户故事、用例、需求规格书、验收测试等），你都要大概知道你在构建什么。
质量属性
：非功能需求（比如，性能、可扩展性、安全等）通常是技术方面的，也很难改造。理论上，这些都需要体现在初始的设计中，忽视这些属性会导致软件系统要么做得不够，要么做得太过。
约束
：约束普遍存在于现实世界，包括批准的技术清单、规定的集成标准、目标部署环境、团队规模等。再说一次，不考虑这些会导致你交付的软件系统与环境不匹配，增加不必要的摩擦。
原则
：是在试图为软件提供一致性和清晰度时你想要采用的东西。从设计的角度来看，这包括你的分解策略（比如，层、组件和微服务的对比）、关注点分离、架构模式等。明确概述一套初始的原则至关重要，这样构建软件的团队才会朝着同一方向出发。
部署注意项
部署和回滚策略是否已经定义？
部署部分就是软件
和基础设施
之间的映射。
接口主要技术指标
接口是否幂等？
约束注意项
已有系统和继承标准；
代码不会讲述完整的故事
，缺少关于复杂软件系统的辅助信息源会让团队在努力浏览代码时被拖累。
团队沟通频率和质量
想要敏捷，就要高效地表达。
C4方法
也很适合SharePoint，一些轻量级的文档可以成为未来的支持、维护和改进工作的一个很好的出发点，特别是如果项目团队有变化，或者如果项目在外包协议下交付。
合作提高了质量，也让我们可以讨论和挑战一些常见的基于自己已有知识、经验和喜好做出的假设。它也为代码集体所有制铺平了道路，有助于打破软件开发团队中常见的孤岛。
架构图应该包括技术的选择
凡事皆有可能，但每件事都有代价。解释那些代价有助于找到给定语境中的最好方案。
软件架构控制前提
团队是否经验丰富？
团队以前一起工作过吗？
团队有多大？
项目有多大？
项目的需求复杂吗？
有没有需要考虑的复杂的非功能需求或限制？
日常的讨论是什么样的？
团队或已有的代码库是否看起来已经混乱不堪？
动态要求
不断地转向，因为你选择的航线可能需要在途中调整。毕竟，敏捷方法已经向我们展示了，不一定预先就有（或需要）所有的信息。
基础角色要求
软件架构角色
需要通才。这肯定是在软件项目起航阶段掌舵的角色，包括管理非功能性需求，整理出对上下文和环境因素敏感的软件设计。
架构师软技能要求
账的局面。
润滑剂
：你经常需要退后一步，促进讨论，特别是团队内有不同意见时。这需要探索、客观，帮助团队达成共识。
政治
：每个组织都少不了政治。我的咒语是，离得越远越好，但你至少应该明白周围发生了什么，这样才能做出更可靠的决策。
责任感
：你不能因为失败就责备软件开发团队中的其他人，有责任感对你而言很重要。如果软件架构不能满足业务目标，无法交付非功能性需求或技术品质很差，那都是你的问题。
授权
：授权对任何领导角色来说都是一个重要部分，作壁上观和事必躬亲之间有一条模糊的界线。你应该学会在适当的时候授权，但请记住，你授权的可不是责任。
架构师软技能要求
领导力
：简单来说，领导力就是创造共有的愿景，并带领人们向着共同目标前行的能力。
沟通
：你有世界上最好的想法和愿景，但如果不能有效地传达给其他人，也是死路一条。这包括了软件开发团队内外的人，要使用适合受众的语言和细节水平。
影响力
：这是重要的领导技能，从毫不掩饰的劝说到神经语言编程或绝地控心术，它能够以多种途径实现。通过妥协和谈判也可以达到这样的目的。每个人都有自己的想法和计划，你在处理时还得让他们都不反感，并主动地去追求你需要的结果。好的影响力也要求好的倾听和探索能力。
信心
：信心很重要，是有效的领导力、影响力和沟通的基础。但信心不代表傲慢。
合作
：软件架构角色不应该被孤立，（与其他人）合作想出更好的方案是一项值得实践的技能。这意味着倾听、谦虚和响应反馈。
指导
：不是每个人都对你正尝试做的事情有经验，你需要对他们进行角色、技术等方面的指导。
辅导
：辅导是对人进行学习方面的指引，而非告诉他们怎么做一件事。作为领导，你可能会被要求去辅导团队中的其他人。
动力
：这说的是保持团队愉快、开朗和积极。团队要有积极性，才会跟随你这个软件架构师所创建的任何愿景。你还要面对团队中一些人不买1
2
软件架构角色
质量保证
软件架构角色，代码贡献
编写代码
软件架构角色
架构演化
软件架构角色
主动发现、减轻和承担高优先级的技术风险
软件架构角色2
2. 设计软件
设计软件的过程是软件架构角色的一部分，这一点应该在意料之中。这涉及要理解如何解决架构驱动力带来的问题，创建软件系统的整体结构，并为交付设定一个愿景。
软件架构角色1
架构驱动力
这个角色首先要理解业务目标和管理架构驱动力，其中包括需求（功能性需求和非功能性需求）和环境的限制。
所有的架构都是设计，但不是所有的设计都是架构。
网友评论