系统分层泛谈

系统分层泛谈

今天同事提出了一个关于系统分层原因的问题。

做为后端研发工程师，我们基本都听过MVC模式/框架，但是目前我们系统拆分的情况，会遇到完全是服务端的系统，同时一个系统维护的研发人员并不多的情况下，那么是否依然需要遵循类似MVC模式/框架的思想，对系统进行分层呢？

如果需要是为什么呢？如果不需要又是为什么呢？

基于上面的问题，系统分层的意义究竟又是什么呢

对于这种设计类的问题，在工作中有一些零散的想法，正好借此机会结构一下。

这个问题初看起来就如问题本身来说的一样"显而易见"， 分层当然会更容易管理，更容易实现。

从根本上来讲，分层追求的是降低系统的开发维护成本。这是因为对人类而言，一切复杂问题的处理思想都是分而治之。可以将人类看作只有一个"CPU线程"和"寄存器"，但只要有处理能力的上限都会从分治的思想受益。正如<<超体>>中所说，分类只是为了简化。

我们只知道一加一等于二，可是一加一根本不等于二，世界本没有数字也没有字母，我们把我们的存在塞入人类的框架体系当中，使之便于理解，我们创造了一个体系，以便忘却原本难以理解的体系。

假如我们认可了分而治之的思想，那么将这种思想运用到所谓的软件中会产生什么样的反应和结果呢呢?

观其形

首先，我们有了MVC，MVVW, MVP等等设计模式。这种设计模式是一种功能框架，将一个完整的功能拆分到不同的组件。试想经历MVC等设计模式从无到有的开发者，一定会感觉有了这些很幸福。这些固定的模式就像青霉素一样，能不关心细菌的种类进行使用，并且很大情况下不会出现问题。

从分层方式可以知道，上面的组件解耦方式属于功能水平解耦，那么也肯定也会存在垂直解耦。例如现在的微服务就是最好的例子。与水平解耦模式不同的是，垂直解耦有了一些业务的味道在里面。

那么对于这两种组件解耦方式，是否可以找出共同的部分? 而且这些分层模式是否与现在火热的DDD有关系?

辩其象，识其形，悟其道。

经过不断探索，大师们总结组件设计原则SOLID和组件组合的原则REP, CCP, CRP等。这些原则理解起来比较绕，所以我们总结一下重点:

• 设计一个组件最重要的是单一职责和实现替换。
• 符合了单一职责的组件组装应该以稳定性顺序进行组合。

明白了这两点，那么DDD为什么会大火就有了一个合理的解释，也是为了更好地完成"单一职责"。

回答开题

不管分层还是不分层，我们最终目的都是为了减少成本。

为了达到这个目的，首先我们需要对系统职责有清晰的认知，其次需要对系统演进有一定的把握。

在此基础上，再对当前已存在的特定分层模式(MVC, Cola)是进行简化，来最大化分层模式的收益。