准则：

  • 小既是美
  • 让每一个程序只做好一件事
  • 快速建立原型
  • 弃舍高效而取可移植性
  • 采用纯文本存储数据
  • 充分使用软件的杠杆效应（软件复制）
  • 使用 shell 脚本提升杠杆效应和可移植性
  • 避免强制性的用户界面
  • 让每个程序都称为过滤器

小准则

  • 允许用户定制环境
  • 尽量使操作系统内核小而轻量化
  • 使用小写字母并尽量简写
  • 沉默是金
  • 各部分之和大于整体
  • 寻求90%的解决方案

架构设计注意事项

期望的软件架构，应该是贯穿在其他被应用的生命周期里，应该包括以下的内容：

  • 系统间的关系 明确地指出该系统与其他系统的关系，是调用关系还是依赖关系。
  • 系统内关系 系统内各个子系统之间的关系，如前端应用于后端应用，以怎样的方式通信，需要怎样的通信机制。
  • 应用内框架 包含应用相关的框架、组件，并且清楚地表示出他们之间的关系。
  • 规范和原则 用户指导项目中的开发人员，编写出符合需求的代码，以构建出设计中的架构。

前端项目架构我们还要需要选择开发、使用那些UI组件。这也属于系统抽象架构部分。而关于这个组件提供的接口，则偏向于组件的详细设计，但是他也是属于要考虑的架构范围— 但并非是必须要考虑的范围。

功能性需求与跨功能性需求

系统架构中按照功能性来划分，需求可以分为功能性需求和跨功能性需求（非功能性需求）。功能性需求定义了一个软件系统或组件的功能，也是一个系统需提供的功能及服务。而跨功能性需求也是一个需求的一个重要组成部分，它指的是依靠一些条件判断系统运作的情形或者特征，而不是针对系统特定行为的需求。这些非功能性需求一般是隐形的，往往难以直接观察得出。

架构开发方法 4 + 1 视图法 （RUP 4 + 1）

  • 逻辑视图（logical view）：在设计期的模块、接口划分，职责及协作方式等。
  • 流程视图（process view）: 在运行期运行的数据同步，如在微前端的数据控制等。
  • 开发视图（development view）: 在开发期的框架、库、技术选型及其对应的编译。
  • 物理视图（physical view）：又称为部署视图。在部署期与持续交付相关的技术决策。
  • 场景（scenarios）：又称为用例视图，他使用一组用例或场景来说明架构。

4 + 1 视图法的设计流程如下：

  1. 架构人员根据需求创建相应的逻辑架构，开发人员进行详细设计。
  2. 架构人员和开发人员根据需求设计物理架构，再由开发人员根据物理架构进行对应的详细设计

架构开发方法：TOGAF 及 ADM

针对大型的企业架构来说可以使用 TOGAF （the open group architecture framework，开放组体系结构架构）的标准方式来设计企业架构。

ADM （创建企业级架构）下面对于8个阶段进行解释：

  1. 架构愿景。设定项目的范围、约束和期望。
  2. 业务架构。开发业务结构，用于支持设定的架构愿望。
  3. 信息系统架构。开发信息架构，用于支持设定的结构愿望。
  4. 技术架构。开发技术架构，用于支持设定的架构愿望。
  5. 机会及解决方案。为前几个阶段定义的架构进行初步实施计划和交付工具的识别。
  6. 迁移计划。通过最终确定的详细实施和迁移计划，阐述如何从基准体系结构迁移到目标体系结构。
  7. 实施管理。准备和开发结构契约，并对实施的架构进行监督，以确保实施项目符合架构的要求。
  8. 架构变更管理。对架构变更进行持续的监控。

每个阶段都有详细的步骤，及相应的产出规范。由于ADM 是面对大型企业结构的，其过程和步骤比较复杂。

参考国际开放标准组织官方文档

生成架构产出物

不论采用那种架构设计方式，都需要留下相应的结构文档，即：

  1. 架构图：它包含了系统的整体架构，用于显示地告诉开发人员，它们是如何构成整个系统的，以及每个部分之间的关系。同时，显示的表明哪些部分是第三方系统，以及它们与该系统之间的关系。
  2. 迭代计划：按照业务和技术的要求，按时间顺序排列出项目的实施计划。由于其中也包含了上线时间，所以也可以从上线时间往前推算出迭代时间。开发流程：定义开发人员的工作方式，诸如敏捷还是瀑布的开发模式、何种源码方式（主分支、GitFlow或者Feature Branch（功能分支）工作流），必要时还要提前准备相应工具和设备。然后，有针对性地开发流程一定程序的裁剪，以真正满足团队的开发。
  3. 技术栈及选型：确定项目中使用的语言、框架、库等相关的技术栈，以及相应的依赖等。
  4. 实例代码：在这些代码中展示架构的风格及相应的规范。
  5. 测试部署：明确项目的测试类型、测试流程，以及相应的人员在那些层级进行测试。
  6. 部署方式：定义应用的部署方式及相应的的部署方案。

持续集成方案：描述系统的各个模块之间（如前后端）如何集成，以及采用怎样的时间和频率来集成相关的模块。

架构设计原则

  • 不多也不少： 不做多余的设计，也不缺少关键部分。
  • 演进式： 不断地演进以使架构适应当前的环境。
  • 持续性：长期的架构改进比什么都重要。