系统设计方案论

一、架构设计

1、架构设计是什么？

        在我看来，架构设计总结成一句话就是“为了解决软件系统的复杂度带来的问题”。具体来说，就是将复杂的业务功能分解成不同的业务模块，将相同功能抽象成一个模块，提高单个模块间的内聚，降低各个业务模块间的耦合度，避免出现修改一个业务功能整个业务系统都需要进行相关调整。

2、为什么要架构设计？

        为什么要进行架构设计呢？不做架构设计有什么坏处呢？人无远虑，必有近忧。如果你在刚开始做系统的时候，都没有想好如何处理一些复杂业务场景，当你实际遇到的时候，就会发现现有的业务代码根本不符合需求的迭代，而且修改难度不亚于重新做一个系统，这个时候就能体现出架构设计的重要性了。

       做了架构设计就一定有好处吗？那也不一定，还需要分情况来说。如果你当前的项目仅仅为了一个理发店做管理系统，业务场景和业务复杂度都达不到要求，而非要为了这个架构设计的高大上的名词，来做架构设计的话，很明显就得不偿失了。

        所以说，总结起来就是，因地制宜，根据具体的项目进行具体分析。

3、如何进行架构设计？

        从我这个初次接触架构设计的角度来说，要完成架构设计首先要完成几个任务，例如用例图、流程图、活动图、类图、系统时序图等。完成这几个图的开发工作后，整个系统也就有了一个大概的模型了，最起码你知道这个系统是做什么的，具体有哪些功能需要实现，需要拆分成几个业务模块等等问题，都会随着这几个图的落地慢慢清晰起来。

二、模块设计原则

1、开闭原则

        我们设计的类和方法应该对扩展开放，修改关闭!

2、接口隔离原则

        用多个职能专一的接口，而不是使用将多种职能的方法都集中在一起的接口!

3、里氏代换原则

        一个软件实体如果使用一个父类，那一定适用其子类，所有引用父类的地方必须能够透明底使用其子类的对象，子类能够替换父类对线下而程序逻辑不变！

4、迪米特法则

        认知最少原则，即当前类对其他的类保持最少的引用，也就降低了系统的耦合度，避免出现一个类修改了，影响到整个系统的功能调用。

5、单一职责原则

        在类层面、方法层面、接口层面的职能都是单一的。在类中，职责一和职责二发生改变都会影响到同一个class类，那么就有可能造成当职责过多的时候，牵一发而动全身，系统耦合度太高而不便于维护!

6、依赖倒置原则

        上层模块不应该依赖下层模块 ，二者都应该依赖其抽象!也就是说我们开发过程中，调用业务模块方法的时候，最好将其抽象成一个接口，统一调用接口方法，避免出现当有多个类需要扩展的时候，我们只要增加接口的实现类即可，不要修改原有的业务逻辑代码。

7、合成复用原则

        尽量使用对象组合，而不是继承来达到复用的目的。