echo编辑整理，欢迎转载，转载请声明文章来源。欢迎添加echo微信(微信号：t2421499075)交流学习。
基础架构需要遵循什么？设计产品架构应该需要考虑哪些因素？功能的完整性、效率、安全性、可扩展性？设计架构并不是越完美越好，越是完美的架构投入就越是高昂。在我们实际的市场应用中，我们可以看到很多的项目，基本没有太多的考虑，先满足业务需求，然后尽力使用最低的成本，这样做的架构是符合标准规范的架构吗？这算是一个悖论，市场选择。存在既是合理。
基础架构设计原则
- 合适原则
真正优秀的架构都是企业在当前人力、条件、业务等各方面约束条件下设计出来的，能够合理地将资源整合一起并发挥出最大功效，并且能迅速落地。这也是很多BAT出来的架构师到了小公司或者创业团队反而做不出成绩的原因，因为没有大公司的平台、资源、积累，只是生搬硬套大公司的做法，失败的效率非常高。不管是什么样的需求，市场对应的现有资源是肯定能找到对应的，但是资源并不一定是你所掌握的，所以很多公司的第一考虑是先实现目的，这也是我们看到了很多的简单的，有些缺陷的架构应用在快速的出现。
- 简单原则
无论是结构的复杂性还是逻辑的复杂性，都会存在各种问题，这个原则跟合适原则是有很多融合性的。每一个公司的开发人员能力差异较大，合适的原则下尽可能的简单化，这样有助于大大的减少开发成本，对人员的要求相对来说就低了，即使人员流动也不会造成没有人能够接手的尴尬局面。
- 演化原则
系统架构一步到位明显是不合理的，一般来说只要具备一定的架构能力，就能完成一些基础的架构建设。整体来说，在一段时间内如果不是致命的架构漏洞，应该是不会有大变动或者重构的。所以我们不需要去一步到位，特别是对于互联网公司来说，项目方向需要能够快速掉头，这就需要我们对架构不断的进行改进。即使没有很多业务上的大变更，系统架构也应该是一步一步完善，补充我们的当前架构不足的地方。
框架第一原则：高内聚低耦合原则
软件设计中通常用耦合度和内聚度作为衡量模块独立程度的标准。划分摸块的一个准则就是高内聚低耦合。那么什么是高内聚低耦合？耦合度是指模块之间联系的紧密程度。当我们设计架构的时候，我们会发现，我们会对系统进行分模块。但是怎么分模块？功能？数据库？业务模型？都算是划分依据，但是模块之间的依赖度也是我们重要的衡量标准。举个简单的例子，我们创建一个订单模块，同时创建一个商品模块，如果我们每一次访问订单的时候都要去访问商品模块，那是不是相对来说这样分模块反倒还整加了系统交互时间？
开闭原则、依赖倒置原则等是不是架构设计原则？
很多网上的第一架构原则就是开闭原则、依赖倒置，并且有很多的文章大肆的在写这类原则规范架构设计。其实这些设计原则都是架构设计之一，架构设计原则很多很多，我们上面描述的基础架构设计原则是比较广泛的思维，而开闭原则、依赖倒置原则等是更具体的原则规范。在架构设计前期，我们并不需要太多的去关注那么多的设计原则，合适、简单就好，这也是为什么本文一上来就讲基础架构设计原则。
架构设计公认度很高的几大原则
- 开闭原则
- 依赖倒置原则
- 单一职责原则
- 接口隔离原则
- 迪米特法则（最小知道原则）
- 里氏替换原则
- 合成/聚合复用原则
开闭原则
开闭原则就是说对扩展开放，对修改关闭。在多数公司里面，项目基本不是只进行一次开发，而是不断迭代。如果我们公司里面有个项目，假若项目主打文章发布，突然业务转型希望做视频，那是不是意味着我们就直接把文章改成视频？肯定不是的，而是不仅支持文章发布，同事新增视频功能。
依赖倒置原则
依赖倒置原则的本质就是通过抽象(接口或抽象类)使各个类或模块的实现彼此独立，不互相影响，实现模块间的松耦合。
单一职责原则
对象不应承担太多功能。一个对象到底是用于数据库交互还是用于返回前端的应该分开使用
接口隔离原则
其实通俗来理解就是，不要在一个接口里面放很多的方法，这样会显得这个类很臃肿
迪米特法则
也叫最少知识原则，当前对象本身、当前对象的成员对象、当前对象所创建的对象、当前对象的方法参数等，这些对象存在关联、聚合或组合关系，可以直接访问这些对象的方法
里氏替换原则
里氏替换原则是针对继承而言的，如果继承是为了实现代码重用，也就是为了共享方法，那么共享的父类方法就应该保持不变，不能被子类重新定义。子类只能通过新添加方法来扩展功能，父类和子类都可以实例化，而子类继承的方法和父类是一样的，父类调用方法的地方，子类也可以调用同一个继承得来的，逻辑和父类一致的方法，这时用子类对象将父类对象替换掉时，当然逻辑一致，相安无事。
合成/聚合复用原则
尽量使用对象组合，而不是继承来达到复用的目的