[https://www.gitbook.com/book/yishuiliunian/ios-architecture-design-and-deploy/details]

iOS结构设计与实施

从11月份开始自己一部分工作重心开始往架构设计上进行转移。这个也是目前项目在质量上的要求决定的。这段时间和同事一起讨论如何设计和实施结构，也算是有些想法。写下来，算是总结，也在博客上和大家交流一下，欢迎拍砖。

当然，按照我以前的习惯，说点什么的时候，首先明确的是定义。但这一次可能有点例外了，因为关于“架构”，但目前为止业界也没有给出一个明确的定义。目前比较流行的有：组成派和决策派。

按照组成派的说法：软件系统的架构就是用来将系统描述为计算机组件以及组件之间的交互。Mary Shaw和David Garlan给出了更为明确的定义：软件架构={组件(component),连接件(connector)，约束(constrain)}。组件可以是独立的程序，比如数据库服务器，也可是子系统、框架、模块、类等不同粒度的软件单元，它们共同的特点都是承担一定的计算职责。连接件可以是过程调用、管道、RPC或者Web Service等，用于表示组件之间的相互作用。约束一般为对象连接时的规则，或指明构件连接的形式和条件。例如，上层构件可要求下层构件的服务，反之不行；两对象不得递规地发送消息；代码复制迁移的一致性约束；什么条件下此种连接无效等。

而决策派认为软件架构是软件一些重要方面决策的集合。这种说法的典型代表是RUP中对于软件架构的定义： 软件架构包含了关于以下问题的重要决策：

1. 软件系统的组织；
2. 选择组成系统的结构元素和它们之间的接口，以及当这些元素相互协作时所体现的行为；
3. 如何组合这些元素，使它们逐渐组成更大的子系统；
4. 用于指导这个系统组织的架构风格：这些元素以及他们的接口、协作和组合。

当然从其他的一些书籍中我们还能看到这样的一些描述：架构即约束、风险驱动的架构设计、质量驱动的架构设计。。。。。

无论哪种定义其实我感觉都在围绕着几个事情再讲：抽象、分治、知识[引自《恰如其分的软件架构》]。

抽象：对当前的问题域进行概括和精炼。尽可能的缩小问题空间。这个是个建模的过程。通过合理的抽象活动，对当前问题域进行建模。

分治：对将庞杂的大问题，拆解成相对规模较小的子问题。比如说要从北京到南极洲，可以拆解成从北京到美国，从美国到澳大利亚，从澳大利亚到南极，三个子问题。在编程中，我们常常使用的函数，类就是封装了一个个的子问题的解决方案。分治的必然结果就是职责划分，当然实现职责划分的方式，包括刚才说的函数、类。甚至包括模块和子系统等等方式。现在我们常用的Cocoapods包管理工具，就是一个很好的分治的例子。他讲IOS开发中常遇到的一些问题和需求，划分成一个个的pod。

知识：任何一个架构都不是凭空出来的。其必然是为了解决某个特定的问题而存在。为了解决这个问题，我们可能会提取出一些特定的知识来为解决改问题服务。当然这里的知识不止是像数据库技术，IO优化技巧这样的东西。甚至是，一些我们的app中遇到的特定问题，比如之前博客中说道的在SDK设计的时候，SDK在运行时污染了宿主环境，我们使用类似于VM的方式来解决。还有，使我们关于一些决定性的问题形成的公式，比如将布局代码统一写在layoutSubViews函数里面等等。

好了，上面说的三点是比较虚的东西。但是，这三点却是支撑我进行架构分析、设计和实施的核心思想。有点万剑归宗的意思。我个人认为，且不管结构设计的流派如何，上述三点及其衍生出来的方法论，对于架构设计来讲犹如巨鼎之三足。后面的整个过程中我们会反反复复的提及哈。