什么是软件架构
软件架构 是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。软件架构会包括软件组件，组件之间的关系，组件特性以及组件间的特性。软件架构可以和建筑物架构相比拟。软件架构是构建计算机软件，开发系统以及计划进行的基础（蓝图），可以列出开发团队需要完成的任务。——维基百科
和盖房子一样，对于软件开发来说，最初，设计出软件的总体架构蓝图，思考各个模块之间的关系，实施一系列相关的架构决策。然后，选择软件开发所需要的一系列技术栈、框架等，讨论关于应用的上线、部署等流程问题。最后，才能进入软件的开发阶段。在开发过程中，还需要保证软件的质量，才能设计出符合要求的系统。
开发人员需要怎样的软件架构？我们期望的软件架构，应该是贯穿在它被应用的生命周期里，应该包含：
- 系统间的关系。明确地指出是调用还是依赖关系。
- 系统内关系。比如通信机制。
- 应用内架构。包含应用相关的框架、组件，并清楚表示它们之间的关系。
- 规范和原则。指导开发人员编码和构建设计中的架构。
架构的设计
架构设计不只是一个技术工作，它包含一系列复杂的工作，其范围包括软件工程、开发实践、业务交付等相关领域。为此，在进行架构设计的时候，需要进行一系列技术及非技术相关工作。
- （1）手机利益相关这需求。倾听业务人员、项目负责人等相关者需求，进行用户访谈，收集相关的需求。
- （2）与相应的技术人员（如开发人员、测试人员）讨论，了解架构上的潜在限制。
- （3）寻找潜在的可行性技术方案。
- （4）整理出功能列表中的功能性需求和跨功能性需求。
- （5）找出会严重影响开发的风险点。
- （6）和技术委员会、利益相关者反复确认方案（可选）。
- （7）对架构设计进行概念证明。
- （8）细化架构的部分实施细节。
- （9）结合技术和业务 ，进行需求排期。
对于不同的项目来说，以上步骤都会有所不同，有的可能会忽略一些步骤，有的可能会更细，包含更多的步骤。对于大部分项目来说，技术方案往往都是现成的。所以这个过程中，最重要的事情是收集相关的架构需求，从过往经验、互联网、同事等渠道，获得一些技术方案。整合多个方案或者对方案进行改进。而需求是决定这些架构方案的细节。
收集架构需求
架构并非从技术角度考虑问题，它需要从多方的利益出发，在满足利益相关者需求的同时，还要具备技术上的可实施性。所以，我们需要收集一系列资料：
- 了解相关者利益。
- 产品、业务负责人（PO)
- 产品经理，根据架构来决定项目计划和项目人员
- 架构师、开发人员，关心系统的构建、演讲及维护。
- 业务分析人员，关系如何分配和安排项目的迭代计划。
- 测试人员，设计合理的测试计划，如对系统集成部分的测试等。
- 更高级别的人物，公司战略相关……
- 寻找架构关注点。
- 性能（性能指标、并发量）
- 安全（数据安全、应对客户端和服务端攻击）
- 平台化（是否需要作为平台承载其他系统）
- 代码维护（开发上手难易度）
- 用户体验
- 明确跨功能需求。
按功能性来区分，需求可以分为功能性需求和非功能性需求。功能性需求定义了一个软件系统或者组件的功能，也是一个系统需提供的功能及服务。而跨功能性需求也是需求的一个重要组成部分，它指的是依靠一些条件判断系统运作的情形或特性，而不是针对系统特定行为的需求。这些非功能性需求一般是隐性的，往往难以直接观察得出。比如：
- 运行质量
- 演进质量
- 可用性、可维护性、可变性、可伸缩性
- 浏览器的支持范围
- 移动设备支持的版本
- 罗列技术风险点。
- 技术风险
- 第三方系统集成
- 受限制的线上运行环境
- 需求带来额外的技术膨胀，影响开发交付。
架构模式
架构模式也可以认为是架构风格。前端常见的架构风格有：
- 分层风格。
- MVC架构风格
- 发布-订阅风格
- 管理和过滤器风格
如果是后端架构，风格会更多。
架构设计方法
1、架构开发方法：4+1视图法
- 逻辑视图（Logical View）：在设计期的模块、接口划分，职责及协奏方式等。
- 流程视图（Process View）： 在运行期运行的数据同步，如在微前端中的数据流、控制流。
- 开发视图（Development View)：在开发期的框架、库、技术选型及对应的编译。
- 物理视图（Physical View)：又称部署视图。在部署期与持续交付相关的决策。
- 场景（Scenarios）：又称用例视图，它使用一组用例或场景来说明框架。
2、架构开发方法： TOGAF 及 ADM
TOGAF: 开放组体系结构框架 (The Open Group Architecture Framework )
TOGAF 是一个企业架构标准，分为如下 4个架构域：
- 业务架构： 定义业务战略、治理方法和关键业务流程。
- 应用架构：为将要部署的各个应用程序提供蓝图，并展示他们的交互及核心业务流程的关系
- 数据架构：描述一个组织的逻辑、物理数据资产及数据管理资源的架构。
- 技术架构：定义了支持部署业务、数据和应用程序服务所需的逻辑和硬件功能，他包含了IT基础设施、中间件、网络、通信、处理和标准。
在没有足够的时间和精力的情况下，很难建立一个涵盖 4 个架构域的详尽架构描述。此外，还有一套架构开发方法叫作 ADM，用于创建企业级架构。ADM一共分为8个阶段，如图：
- A 架构愿景。设定项目的范围、约束和期望。
- B 业务架构。开发业务架构，用于支持设定的架构愿景。
- C 信息系统架构。开发新系统架构，用于支持设定的架构愿景。
- D 技术架构。开发技术架构，用于支持设定的架构愿景。
- E 机会及解决方案。为前几个阶段定义 的架构进行初步实施计划和交付改进的识别。
- G 实施治理准备和发布架构契约，并对实施的架构进行监督，以确保实施项目符合架构的要求。
- H 架构变更管理。 对架构变更进行持续的监控。
生成架构的产出物
- 架构图
- 迭代计划
- 技术栈及选型
- 示例代码
- 测试策略
- 部署方式
架构设计原则
适度设计
不做多余过度设计，只需要考虑好扩展性。因为我们不知道未来的需求会变化成什么样时，预留的设计可能是多余的，也可能会影响系统的后续扩展。相反，如果架构考虑的不够，设计不足会使架构扩展性不强。
演进式
开发模式不同，软件架构的设计要求也不同。 在瀑布模式下，先设计好系统锁需要的一系列要素，进行软件的建模、详细的架构设计、文档编写，直至设计的工作完成。 在敏捷模式下，则是现有架构蓝图，实现对应架构的 PoC（概念验证）。然后再实现的过程中，基于PoC 产生的代码叠加业务代码。接着，在项目试试的过程中，不断地完善应用架构的设计，如软件建模等。
持续性
演进式指架构上一些变化，而持续性针对的是开发人员的变化。架构的持续性原则的意图是，敢于修正架构的错误部分。
- 技能水平的持续改进。
- 应用的持续改进。
- 设计能力的持续提升。
如果架构上有多个可演进方向，无法做一个合适的决策，那么可以在条件更加充分的时候在做决策，而不是浪费大量的时间盲目地修改架构，那样只会造成资源浪费。——延迟决策。
前端架构发展史
最初前端是没有架构的，因为只是简单的dom操作。随后发展动态生成HTML、模板分离，前端应用开始变得复杂，诞生出了一些MVC框架，如：Backbone，Knockout 等。
在2009年Node.js 出现之后，前端的软件工程不断地改善：
- 更好的构建工具。从 Grunt/gulp 到 rollup.js、webpack、vite
- 包管理。Bower、NPM、Yarn
- 工程多包管理 mongorepo，如 lerna
- 工程依赖自动化管理。如 renovate
- 模块管理。 AMD\Common.js 规范
- API管理。Swagger API、 Mock Server 成为标准实践，Swagger API 生成 TypeScript 代码等
- 组件化。前端应用其实由一个个小组件组合成区块，再到页面。
- 大前端。有前端来开发跨平台应用，如 Ionic、React Native、Flutter、electron 等。
系统变得越来越复杂，架构在前端的作用也变得越来越重要。MVC满足不了开发人员的足球，于是采用组件化架构，如 组件化+MV*。当我们为了解决跨框架，应用拆分独立，遗留系统迁移等问题时，又出现 微前端架构。
前端架构设计：层次设计
参考资料《前端架构：从入门到微前端》