没有一种架构是可以满足所有迭代的需求的
前言
架构并不是只限于技术选型
是架构设计作为软件生命周期的一部分，并不是说开始的时候 设计完成后就会一成不变，软件的生命周期包含了迭代、维护、重构等过程，架构设计亦是如此，所以说架构是需要变化的，目的就是适应当前情况的开发场景。
而架构产生的时间，必定是受到当时的约束条件，如人力、团队技术积累、时间、业务定位等等需求。所以，当前架构可能并不能满足未来的需求，我们要开放对待这个问题，只要当前的架构符合一定的设计原则，未来进行架构的演进就不是问题。
“架构”这个词解释也没有一个明确的定义，每个层级，每个场景都有自己的解释，所以到底什么是架构呢？
软件架构的定义
软件架构（software architecture），是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。
-摘自百度百科
其实软件开发和盖一栋大楼一样，都需要规划、设计、实施等一系列的阶段，最开始设计建筑图纸，主体架构，还要考虑绿化、材料、安全等因素。经过一系列的决策，才有一套成熟的建筑施工方案，按照规范建造，才能保证质量和速度。
而开发一个软件或前端工程也是一个“建筑”的过程,我们要通过业务来定位系统间的关系，讨论技术栈和框架的选用，根据当前团队的技术水平进行技术的选型、考虑各个模块间的界限和交互，上线部署策略，问题回滚策略等一系列的决策才能设计出符合当前情况的技术架构。
前端开发过程中需要怎样的架构
大体来看基本要求点如下：
- 符合当前的业务定位
- 前端架构必须具有可实施性
- 必须匹配当前技术储备
- 有足够的人力资源去完成
- 具有可伸缩、可扩展性
【因地制宜】应该是开始设计架构的基本准则，每套架构的产生都有他的外界因素影响，所以，各个公司，各个团队之间的架构不能照搬，如果强制搬过来，可能会适得其反，就像你那 alibaba 的技术架构去搬到 初创 公司，那是根本行不通的，人员，资源不匹配，是没办法去实施架构的。
因此我们在项目前端开发的生命周期中期望的架构应该具有哪些要点呢？
- 准确的业务定位，业务可能是影响架构的主要因素之一，所以我们要找准业务上的定位
- 明确与其他系统之间的关系，确定与其他系统的层次关系，相互间的通讯依赖等
- 设计好系统内子模块之间的关系，如A业务模块需要与B模块交互，该采取怎样的方式
- 基础模块明确，项目中，必定含有基础模块去提供一些公用的方法，数据去提供给各个子模块
- 组件规划，这就是再细一层的规划了，制定组件的交互方式，开发范式
- 开发规范和上线流程，用于指导开发中的过程
架构设计 setp
设计需要进行一系列的技术及非技术的相关工作
- 收集利益相关者的需求，产品经理、业务人员、项目负责人等
- 与相应技术人员进行讨论，确定架构上的潜在限制和要求
- 寻找可行性的技术方案
- 细化技术方案细节，确定一些功能列表中的技术可行性
- 确定风险点
- 与技术人员反复讨论，集合大家意见
- 对技术方案进行demo的概念验证
- 结合当前业务，细化架构的部分实施细节
- 进行排期
架构设计原则
不同的架构师可能会有不同的观点，但是能被人大多数架构师认同的有一下三点
- 不多也不少：不做多余的设计，也不缺少核心部分
设计过少则为设计不足，会使一个框架的伸缩性和扩展性不强，不能灵活的面对即将产生的业务需求的迭代。 设计过度也不一定是件好事，针对未来的技术框架或者需求的变更，我们不能保证目前的架构就一定能兼容这些变化，过度设计反而会让我们一会的架构重构产生很多无用的开发变更，增加成本反而得不到相应的输出价值。
- 演进式：不断的演进以架构适应当前的环境
适应环境能够生存下来的物种，并不是那些最强的，也不是最聪明的，而是那些对变化做出快速反映的。 -达尔文
演进事架构是指在开发过程中，预先设计好重要的部分如系统模块通信，功能模块划分，具体组件颗粒度等，然后在编码过程中，再进行细颗粒度的划分，遇到不适合的地方，进行快速的反应，找到最优解，最理想的状态是，20%的计划，80%的演进设计
- 持续性：长期的架构的改进
持续性和演进式有一定的共同性，演进式的目标是在开发过程中进行架构的细化，持续性则指在迭代过程中进行框架的进阶，在迭代过程中，难免会出现架构不符合当前状况的情况，我们要灵活应对，进行持续性的优化，这样才能在迭代开发过程中，做到最优框架的目的
【延迟决策】有时候“拖延症”也并不一定是坏处，哈哈，开个玩笑，在我们设计架构的时候，会经历一系列的方向决策，但是一个框架的发展并不是总是一帆风顺，当遇到演进方向决策的时候，没有找到最优解，我们可以进行延迟决策，等等，也许就会有答案，这样也许会比当时匆忙做出的决定要更符合预期。
前端架构设计的层次
不同阶段构成架构的因素是不同的，基于这个思路，架构设计可以分为四个层级
1.系统级
对于其他业务系统，我们该如何设计之间的通信、协作、交互。比如A系统承载了内容库模块，B系统需要用其中的选择内容组件，我们设计了一套csi。去托管通信
- 对于前后端的服务通信方式。ws or http，鉴权，config记录等
- 对于报错收集处理的基础信息建设
- 是否采用微前端等架构
2.应用级
应用级是指多个子应用直接的关系设计，可能是子应用，子模块，lib包、共享模块等，也就是架构设计的进一步细化
- 脚手架的设计，可以规范应用的基础，有利于快速的构建子模块或者子应用，加入一些格式化插件，可以有效的防止一些不符合要求的代码上传到远程仓库
- lib包设计，可以把一些公用的，细颗粒度，重复利用性高的作为一个lib包抽取
- 组件系统模板，基础组件设计好模板，有利于提高开发效率
3.模块级
模块级是深入到子应用的级别的层次，颗粒度更加细化，包含一些设计模式和UI层面的规定，比如，单项还是双向数据流，采用的UI模板，公共css等
4.代码级
代码级的层级用于规范开发人员的代码，提高代码质量，此层次要做的工作有：
- 初期的开发指导文档
- 开发过程中的 codeReview
- 定期的技术交流分享
- 开发文档或代码注释的生产
【小结】 本文在作为一个引子，先介绍了对于架构的一个认知，简单的说明了在开发过程中我们需要怎样的步骤去设计一个架构，以及架构设计中我们应该注意什么，及架构设计者应该关注的层次，接下来的文章会更深入的介绍下前端架构
持续更新
- 【来聊一聊前端架构之二】前端架构的落地实施
- 【来聊一聊前端架构之三】构建符合当前项目的架构开发流程
- 【来聊一聊前端架构之四】前端脚手架在项目中的应用
- 【来聊一聊前端架构之五】前端架构中组件化的拆分
- 【来聊一聊前端架构之六】微前端架构在项目中应用
关注一波哦~
参考：《前端架构 从入门到微前端》
