下至接口设计
上至技术选型
架构PPT少不了对ROI(投资回报)和TCO(总体拥有成本)陈述
想要在这个行业里有所作为,就需要克制对新鲜玩意的迷恋,开始问一些问题。
不管你是构建软件系统、网络还是数据库,任何成功的方案都需要你理解问题,并且设定一个愿景可以和每一个参与构建最终产品的人沟通。 不管何种领域的架构,主要就是结构和愿景。
应用程序的关注点是应用程序
谈论的是软件设计的低级别切面,通常只考虑单一技术栈
结构单元主要以软件为基础,包括编程语言和结构、类库、框架、API等,由类、组件、模块、函数、设计模式等加以描述
应用程序架构着重考虑软件和代码组织
可以看做是更大规模的应用程序架构
大多数软件系统是由横跨不同层次和技术的多个应用程序组成,每个部分都有自己的应用程序架构 要让整个软件系统工作起来,要思考如何组合这些单独的应用程序
大多数软件系统不是孤立的,系统架构要关注互操作性与环境中其他系统的集成
架构单元是各种软硬件,从编程语言和软件框架到服务器和基础设施。
系统架构描述为从组件和服务到子系统等更高层次的抽象
系统架构的定义大多数包括软件和硬件
是应用程序和系统架构的结合
从代码结构和基础到将代码成功部署到生产环境,与一个软件系统重要元素相关的所有东西就是软件架构
开发者的角度会考虑软件开发,关注点多数会放在代码上
还需要有人考虑以下事情:
不同的软件架构提供不同层次的敏捷
理解组织或业务的变化很重要,因为这能帮助你决定采用何种架构风格,可能是整体架构、微服务架构或者介于两种之间
所有的架构都是设计,但是并非所有的设计都是架构
架构反应了一个 系统成型的重要设计决策,而重要性则通过改变的成本来衡量
架构的定义提供了一个基准,去思考软件系统中哪些可能是重要的, 可能包括:
软件系统架构流程的一部分是搞清楚哪些是重要的以及为什么.
成功的软件项目不仅仅是好的代码,有时候要暂时跳出代码,总览大局
软件架构的好处:
每个软件项目都应该考虑多种因素,以评估必须多少软件架构的思考
构成软件架构角色应有的内容:
1.架构驱动力
非功能性需求和限制往往对软件架构有影响
2.设计软件 需要花时间解决利益相关者提出的问题
软件设计的一个关键部分是技术选择
3.技术风险
技术选择就是风险管理,当复杂度和不确定性高的时候降低风险,有利可图时再冒点险
技术决策需要评估和评审,包括一个软件系统的主要结构单元,下至开发过程中引入的库和框架
架构师要主动发现、减轻和承担高优先级的技术风险
4.架构演化
软件在这个交付过程中依据不断变化的需求和团队反馈来对其进行演化
架构师要在整个交付过程拥有和演化这个架构
5.编写代码
软件架构不一定只涉足日常的编码任务,但要持续地参与到交付中,积极的帮助引导和塑造它.
一个大型项目意味着要照看大局,可能没有时间写代码
一个写代码的架构师更有成效,更快乐
6.质量保证
最好的架构,糟糕的交付也能让原本成功的软件项目有失败.
只要是架构上显著的、业务上关键的、复杂的和高度可见的,都是一个项目的重要组成部分
需要务实的认识到不能保证每件事
软件架构师要懂技术,这样他们至少能回答以下问题:
技术面宽对软件架构很要,他们要能回答以下问题:
如果是软件架构师:
如果是软件开发者:
软件架构讨论的是重要的设计决策,重要性以变动的成本衡量
早点理解需求、约束和原则,有助于避免将来昂贵的返工
质量属性:
学习领域内常用的质量属性,在开始构建一个新系或者修改已有系统时,先关注这些常用的质量属性
处理非功能需求:
探索需求,搞清楚驱动力是什么. 我们的目标是获取一组特定的,理论上可以明确量化的非功能性要求. 比如:
开发原则: 1. 编码标准和规范 2. 自动化单元测试 3. 静态分析工具
架构原则:
原则通常是因为好的理由才引入,并不是任何时候都有好处。
构建软件的大小和复杂度,加上环境的约束,会帮助你采用哪些原则。
倾听团队成员的反馈会帮助你认清你的原则是否奏效。
大多数软件系统可以用几乎任何技术构建,如果有复杂的非功能性要求,比如高性能和可伸缩性,事情会变得棘手,必须清楚技术、架构的选择是否管用。
对于构建软件可采用的技术和可选的技能(人),很多组织都有约束
可以采用各种手段挑战约束,但不能忽视,否则就会交付一个无法与组织已有的IT系统环境集成的软件系统的风险
缺乏一致性的方法会导致代码库难以理解,维护和增强. 增加单独可移动部件的数量也会让部署、运营和支持变得复杂.