软件架构与框架

描述软件架构与框架之间的区别与联系

定义

• 软件架构：软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。设计软件架构就是把系统分解为一些部件，描述这些部件的职责及它们之间的协作行为。
• 软件框架：软件框架是面向领域（如 ERP、计算领域等）的、可复用的“半成品”软件，它实现了该领域的共性部分，并提供了一些定义良好的可变点以保证灵活性和可扩展性。也就是说软件框架是领域分析结果的软件化，是领域内最终应用的模板，是特定语言和技术的架构应用解决方案。

区别

简单来说，两者的区别在于架构不是软件，而框架是软件。

软件架构不是软件，而是关于软件如何设计的重要决策。软件架构决策涉及到如何将软件系统分解成不同的部分、各部分之间的静态结构关系和动态交互关系等。经过完整的开发过程之后，这些架构决策将体现在最终开发出的软件系统中；当然，引入软件框架之后，整个开发过程变成了“分两步走”，而架构决策往往会体现在框架之中。

框架是一种特殊的软件，由实际的代码构建而成，它并不能提供完整无缺的解决方案，而是为你构建解决方案提供良好的基础，是软件系统、子系统的半成品。软件框架为具体的解决方案提供了基础，提供了基础服务和可扩展点，同时软件框架也建立了一些约束，开发人员在此基础上进行特定业务功能的定制开发。

• 框架是具体语言和技术相关的，而架构与具体语言和技术无关。
• 框架是集成了你的代码和多种第三方解决方案的工具，让你聚焦 业务逻辑代码 而 不是技术实现。

联系

软件架构是引导如何设计软件框架的重要决策。它决定了软件系统如何划分，在一定程度上描述了被划分的各个部分之间的静态、动态关系。软件架构的决策体现在软件系统的框架中。

框架是一个可实例化的、部分完成的软件系统或子系统，它为一组系统或子系统定义了架构，并提供了构造系统的基本构造块，还为实现特定功能定义了可调整点。在面向对象环境中，框架由抽象类和具体类组成。（A framework is a partially complete software (sub-) system that is intended to be instantiated. It defines the architecture for a family of (sub-) systems and provides the basic building blocks to create them. It also defines the places where adaptations for specific functionality should be made. In an object-oriented environment a framework consists of abstract and concrete classes.）

——《面向模式的软件体系结构（第一卷）》

总而言之，软件架构指导软件框架的设计，而软件框架是一种或多种架构的组合的实现。

以你的项目为案例

• 绘制三层架构模型图，细致到分区

  

• 结合你程序的结构，从程序员角度说明三层架构给开发者带来的便利

  • 总的来说，使用三层架构可以做到关系分离、高级服务与低级服务分离、特定于应用的服务与一般性服务分离。三层架构可以减少耦合和依赖性、增强内聚性、提高潜在的复用性并且使概念更加清晰。这可以使得不同层的开发者之间专注于本层开发，而无需考虑除本层以外的开发。在我的程序中，UI层、Domian层和Technical层三者之间的耦合度很小，从而使得各层的开发相互独立，大大提高了开发和调试的效率。
  • 封装和分解了相关的复杂性，有利于提供开发效率。在我的程序中，显示菜单数据、处理订单数据和存储交易数据相互分开，数据流得到了有效组织和管理，从而大大减少了开发复杂度。
  • 较低层的复用性较高，为开发者减少了重新开发的麻烦以及代码量。
  • 通过逻辑划分，有利于开发者进行高效的团队开发。

  • 各个层次清晰，每个层次都提供了接口定义：

    • 很容易用新的实现替换原来的层次实现。例如对sql进行性能优化，并不会影响其他层的代码结构。有利于后期维护。
    • 有利于实现切面编程，减轻业务的复杂程度，加快编码效率。
    • 每个层次的定位明晰，业务处理的内容明确。依据层次，可以划分不同的分工。开发人员可以只关注整个结构的其中某一层。
    • 接口定义也提供了良好的可扩展性。例如数据库从mysql切换到oracle，只需要通过配置来切换。

  • 接口设计需要符合对扩展开发，对修改关闭的原则，增强了系统的安全性

研究 VUE 与 Flux 状态管理的异同

• 同： Flux 思想是为了解决传统 MVC 架构不能有效解决大型业务中复杂数据流的管理问题而产生的一种软件架构思想。VUE 和 Flux 的状态管理都是基于 Flux 思想的有效实现，通过对数据流进行严格管理来规范数据在 Web 应用中流动方式的框架。

• 异： VUE 与 Flux 在状态管理上的差异主要体现在对数据流的管理方式不同。

  • Flux 通过强制数据的单向流动来解决业务数据复杂度的问题。它主要将一个应用分成四个部分：

    • View： 视图层
    • Action（动作）：视图层发出的消息（比如mouseClick）
    • Dispatcher（派发器）：用来接收Actions、执行回调函数
    • Store（数据层）：用来存放应用的状态，一旦发生变动，就提醒Views要更新页面

    

    Flux 数据流的顺序是：

    View 发起 Action --> Action 传递到 Dispatcher --> Dispatcher 接收 Action，并通知 Store 进行更新 --> Store 更新状态并通知 View 进行改变 --> View 收到通知后，更新相应页面内容

    在这个过程中，数据总是单向流动，任何相邻的部分都不会发生数据的双向流动。这保证了数据流的清晰。

  • VUE 的状态管理由vuex实现。VUE 没有使用 Dispatcher 来接收 Actions 、执行回调函数并通知 Store 改变状态，而是通过使用 Mutation 来改变状态。VUE 的状态管理的核心概念如下：

    • State: Vuex 使用 单一状态树 —— 是的，用一个对象就包含了全部的应用层级状态。至此它便作为一个『唯一数据源(SSOT)』而存在。这也意味着，每个应用将仅仅包含一个 store 实例。
    • Getters: 从state中获取状态值
    • Mutation: 更改 Vuex 的 store 中的状态的唯一方法是提交 mutation。Vuex 中的 mutations 非常类似于事件：每个 mutation 都有一个字符串的 事件类型 (type) 和 一个 回调函数 (handler)。这个回调函数就是我们实际进行状态更改的地方，并且它会接受 state 作为第一个参数
    • Action: 类似于 mutation，不同在于：Action 提交的是 mutation，而不是直接变更状态；Action 可以包含任意异步操作。

    

    VUE 的状态变更相当于是 action 产生的副作用，mutation 的作用是将这些副作用记录下来，这样就形成了一个完整数据流闭环，数据流的顺序如下：

    在视图中触发 action，并根据实际情况传入需要的参数 --> 在 action 中触发所需的 mutation，在 mutation 函数中改变 state --> 通过 getter/setter 实现的双向绑定会自动更新对应的视图。

参考文档

1. 软件框架和软件结构的区别
2. 一图胜千言：谈框架和架构的区别
3. 什么是Flux架构？
4. 浅谈前端状态管理（上）
5. 浅谈前端状态管理（下）
6. Vue 和 React 对比
7. Flux 架构入门教程
8. 关于 Flux, Vuex, Redux 的思考