做架构要考虑的事情
- 调用网络API
如何让业务开发工程师方便安全地调用网络API？然后尽可能保证用户在各种网络环境下都能有良好的体验？ - 页面展示
页面如何组织，才能尽可能降低业务方代码的耦合度？尽可能降低业务方开发界面的复杂度，提高他们的效率？ - 数据的本地持久化
当数据有在本地存取的需求的时候，如何能够保证数据在本地的合理安排？如何尽可能地减小性能消耗？ - 动态部署方案
iOS应用有审核周期，如何能够通过不发版本的方式展示新的内容给用户？如何修复紧急bug？
什么样的架构叫好架构？
- 代码整齐，分类明确，没有common，没有core
- 不用文档，或很少文档，就能让业务方上手
- 思路和方法要统一，尽量不要多元
- 没有横向依赖，万不得已不出现跨层访问
- 对业务方该限制的地方有限制，该灵活的地方要给业务方创造灵活实现的条件
- 易测试，易拓展
- 保持一定量的超前性
- 接口少，接口参数少
- 高性能
设计模式原则
- 单一职责原则
一个类只负责一个功能领域中的相应职责 - 开闭原则
一个软件实体应当对扩展开放，对修改关闭 - 里氏代换原则
所有引用基类（父类）的地方必须能透明地使用其子类的对象。 - 依赖倒置原则
高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象，其核心思想是：要面向接口编程，不要面向实现编程。 - 接口隔离原则
使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。 - 迪米特法则
一个软件实体应当尽可能少地与其他实体发生相互作用。
总结
设计模式是为了更好的代码重用性，可读性，可靠性，可维护性。
单一职责原则告诉我们实现类要职责单一
里氏替换原则告诉我们不要破坏继承体系
依赖倒置原则告诉我们要面向接口编程
接口隔离原则告诉我们在设计接口的时候要精简单一
迪米特原则告诉我们要降低耦合
开闭原则是总纲，告诉我们要对扩展开放，对修改关闭
