大系统小做，小系统大做

在系统设计上，什么才算是好的系统架构，这其实是一个很大的主题，特别是在不同场景下有不同的选择。但如果从系统的组织形式上来看，我想，「大系统小做，小系统大做」是一个很好的设计思想。

学过面向对象编程的人都知道，实现类的时候，要尽量保证「低耦合，高内聚」，当然，这是一个编程思想，而不是一个具体的执行方案，意味着不管你用什么语言，都可以把这个思想灌输到你的代码实现上。

正所谓万事万物都是有联系的，特别是思想这个东西，是可以复用的。

所以把「低耦合，高内聚」这个编程思想往大了说，把代码的纬度拓展到系统上，那其实就是「大系统小做，小系统大做」的概念。

大系统小做，是把一个系统进行拆分，划分为多个小系统；小系统大做，则是把每个小系统尽可能做的尽善尽美。

这有什么好处呢？

好处自然是和代码的「低耦合，高内聚」相当。

这里假设你要做一个系统，比如最常见的视频网站，包含两个功能，视频上传和视频播放。

有一些开发者会把这两个功能的实现都放在一个系统上，有问题吗？其实也没多大问题，至少在某种场景下是可以采取这样的设计模式的，优点是简单暴力，缺点就是一旦系统需要修改或停止则会让整个视频网站无法访问。

而采取了「大系统小做，小系统大做」的设计思想后，把视频上传和视频播放分成两个小系统来实现，每个小系统做的尽善尽美，那么，即使视频上传系统出问题了，只要视频播放系统稳定，也不会影响其他用户观看视频播放的体验。并且这么设计之后，开发和维护工作变得简单很多，每个小系统交给不同的人负责，每个小系统都可以做到小而美，从而使得整个大系统更加健壮。

当然，任何东西都是有利有弊的，缺点自然就是需要耗费你更多的开发精力和更高的专业素养了。

最后，

大系统小做是格局，小系统大做是情怀。