有关本人当下做的App项目架构的理念

为什么要做架构设计？

随着团队的人员越来越多，应用运营起来之后业务需求和功能需求日益增长，在没有良好的架构设计的情况下，维护起来会越发困难，因此架构设计是应用开发中不得不思考的问题，
归根结底架构设计的目的是为了降低业务开发门槛，使业务开发更容易，使工程代码易懂易维护。

怎么做一个工程架构？

代码追求

在架构之前首先我们要养成好的编码习惯，DRY和Kiss这个两个原理相信大家对有所接触。DRY即Don’t repeat yourself，也就是不要在工程内复制粘贴；Kiss即Keep It Simple，Stupid，架构设计不是为了追求炫酷和复杂度而是要让工程架构更简洁易懂，隐藏复杂的细节提供易用的API。

六大设计原则

Solid原则，是针对面向对象的程序设计提出的，即使在反思面向对象一些问题的现在，这一原则内的很多东西也有很重要的参考意义。
单一功能原则，不要考虑在模块内实现与它不相关的功能，比如在一个类中既要处理string MD5又要处理图片的解压缩，这就是明显的违反单一功能原则的例子。再往细说，其实在方法内也不应该处理过多的事情。
开闭原则，设计模块时要考虑对扩展开发对修改封闭，简单理解就是提炼不变的逻辑，将稳定的部分封装成模块的核心逻辑，对可扩展的部分进行注入。
里氏替换原则，指的是所有的子类都可以替换父类，但是一般情况下我们是不会通过子类去破坏父类的逻辑。接口隔离原则，对于client应该隐藏不需要的细节，隔离这些部分不去依赖它们，使API的依赖更加简洁。
依赖反转原则，指的是高层次的模块不应依赖低层次的模块，个人认为这是个伪命题，因为高层次的模块一旦依赖低层次的模块，那它就不是高层次的模块了。如果高层次模块确实需要依赖某些东西的时候，所依赖的东西应该是抽象的。
最少知识原则，开发人员在使用模块的时候，对该模块知道的越少才越好。

这六大原则其实翻来覆去都是在讲两件事情，一个是易理解的API设计，另一个是建立合理依赖关系。

基于MVVM的架构

image.png

可以提炼的是Common UI，比如对于有相似样式的控件，可以提炼出共用的代码作为Common UI，达到组件复用的目的。处理完登录后要将模型共享出去，这时可以封装一个AccountManager用来向服务器换取模型，其他地方就能通过这个模型来获取token或者用户信息。在UI Kit上做绑定并不容易，需要用ReactiveCocoa或者RxSwift这样的框架来将View和ViewModel绑定或者模型反序列化等等。最底层是App功能，在此之上是App通用业务层，这块提供可以相互使用的组件、模块。再往上的iOS通用层中其实很多东西在iOS的其他开发上都能够用到。

image.png

通常情况下一个公司会有几个App，在App中的一些通用逻辑也可能可以给其他App使用。经过MVVM的设计ViewModel和Model已经与App的UI解耦，可以很轻松的将ViewModel往上提一个层次让整个公司去使用，这时整个架构就会多出一个公司通用业务层。整个过程中MVVM指导了UI与业务逻辑组件拆分，UI与业务逻辑的解耦使得不同APP间的登录功能有共用的组件，通过丰富的iOS通用层组件使绑定、网络请求、数据反序列化变得更容易实现。架构设计需要产出的重要结果是三个通用层有丰富工具、模块，使大部分业务开发可以通过组合通用层的模块工具实现。

如何能设计好模块

设计好模块首先要了解设计原则，知道什么情况下会带来糟糕的依赖，并且要坚持这些原则。还要了解常用设计模式、模块设计方法，比如对MVVM有比较深入的理解就能对GUI层的逻辑做很好的拆分。最后也是最重要的一点就是不断反思改进，其实就是遇到坑的时候思考下为什么产生坑。

架构在项目中执行

在一个项目中执行好的设计原则或者优秀的设计，首先需要建立合理的工程文件结构，知道自己封装好的组件应该放在哪里。另外还要达成团队架构设计共识，切勿闷头开发。

架构（分层）中的几个概念

横向依赖就是在同一层中的模块之间相互依赖的描述；
纵向依赖就是上层对下层的依赖；
强业务逻辑：在一定时间尺度下，随着业务和产品的演进，变动比较大的业务区，比如：用户界面相关的所以业务；
弱业务逻辑：在一定时间尺度下，变动较小的业务区，比如：一般从Api中取数据，随着业务的变化，动到Api的概率比较小，所以为弱业务；