软件开发都是从混沌到清晰的一个结构化抽象的过程。在动笔写代码之前，我们需要搞清楚几个问题：
(1) 系统解决什么问题？
(2) 系统如何与环境交互？
(3) 系统的流程如何组织？
(4) 系统需要支持的变化范围是什么？等等。
思考清楚了这些问题，我们就可以抽象出符合我们需求的系统结构。本篇就来聊聊常用的系统结构。
1. 分层结构
分层结构是目前应用最广泛的软件结构，在该结构中，各子系统按照层次的形式组织起来，上层通过接口调用(或其他契约方式)使用下层的服务，而下层对上层则一无所知。最典型的是三层结构，以及由三层结构衍生出来的多层结构。
分层结构的优点包括：
(1) 可以有效降低系统的耦合性，提高内聚性，降低系统复杂度；
(2) 良好的可扩展性，提供了一个灵活框架，实现业务逻辑的高效重用；
(3) 易于维护。
2. 交互型结构
交互型结构也是应用广泛的软件结构，该类结构可以很好地抽象组件之间的交互关系。常见的交互型结构有MVC(Model-View-Controller)、MVP(Model-View-Presenter)、MVVM(Model-View-ViewModel)等。
2.1 MVC
MVC是目前Web开发领域的主流架构风格。
MVC结构将应用程序分成是三个核心部分：模型、视图、控制器。在该结构中，模型和视图可以直接交互，也可以通过控制器将其转换为间接交互。间接交互更符合松耦合的设计思想。首先，控制器接收来自视图的用户请求，并决定调用哪个模型来处理，模型将业务处理完成后，将结果返回给控制器，控制器调用相应的视图来格式化输出数据，并由选定的视图呈现给用户。
Model层承载底层业务逻辑，该层越厚越好，因为它是和界面最为无关的部分，也是最容易跨平台实现的部分。Model层实现越多的底层逻辑，Controller层就越简洁，对跨平台开发较为有利。
View: 处理应用程序中界面呈现的部分。
Controller: 应用程序中处理用户交互的部分。可以有很多个Controller，分别负责不同的用户交互需求，这些Controller是可以被“正交分解”的，使得彼此完全没有耦合关系。一个Controller模块，可能包含一些属于自己的辅助View，也会接受View层委托的一些事件，由事件驱动自己的状态，最终通过调用Model层的接口来完成某项业务。
2.2 MVVM
View层要呈现Model层的数据，有可能需要知道Model层详细的数据结构，这就要求Model层可能需要为View层提供一些专享的只读访问接口，但在实际使用中，要保证这些接口不被扩散使用。
View层根据Model层数据绘制界面，看似很简单，而实际上，在实际呈现的过程中，可能为了提升效率，进行一些局部更新的优化。在局部更新的优化比较复杂时，就不得不在Model和View之间，额外引入一层ViewModel来达到这一目的。ViewModel是了View的界面呈现而设计的Model层，它的数据组织更接近于View层的表达，和View层的数据呈现一一对应的关系。
MVVM的结构如下：
2.3 MVP
MVP结构更加明确地规定了Model和View之间不能存在直接交互。Presenter作为Model和View的协调器，确保二者之间的交互通过Presenter来进行。
在了解了以上几种数据结构之后，在实际使用中，我们应该如何选择系统结构呢？两条重要的规则是：
(1) 最低耦合原则：即不同的子系统或模块之间有最少的交互频率，使用简洁而自然的接口进行数据交互；
(2) 单一职责原则：一个子系统或模块只干一件事情。
