分层架构与公司组织

　　而落实到实际的应用层面，我们却需要对分层架构做出这样那样的妥协和改进：

　　1 层的穿透。在之前我提过，在标准的分层架构中，第N层只能调用第N-1层的服务，可是在一些场景中是不恰当的。分层的主要问题是性能损失，引起性能损失的原因包括层层调用而产生的网络消耗和方法调用成本，以及中间层必须维持抽象而产生的冗余成本。对于一些对性能要求较高的系统而言，例如操作系统，那么需要为了维持性能而做出跨层调用，但是需要做出平衡的是底层方法修改带来的维护成本 和 性能之间的平衡。

　　2 层与层之间的接口究竟抽样到何等程度。我们在实际工作中往往发现我们设计分层的目的之一是为了重用，但是实际重用性并不高;开发人员往往的理由在于现有的接口与目标需求并不匹配，所以需要新开接口。而接口开发人员的理由很简单，返回过多的字段(过多的抽象)会产生不必要的性能和网络消耗，那么如何平衡两者依然是我们需要平衡的艺术。

　　3 层与层之间建立共享数据、方法。我们希望尽可能地减少层与层之间的依赖，希望更好地保持数据同步(例如避免脏读)，我们可以在整个系统层面建立共享数据(例如共享内存)，从而提高效率。例如我们无法逃脱用户权限的逻辑，所以可以将Auth模块放在公共的服务器上供所有模块访问。

　　4 层与层之间的解耦。层与层解耦有很多方式，最简单的方式可以通过API调用的方式进行解耦，当然通过消息队列也是一种现代软件系统的变种方式。

　　5 MVC作为分层架构的退化。在互联网领域，我们已经越来越少听到三层架构了，而大部分从业者也开始逐渐把MVC当作为三层架构，当然这自有基础知识的欠缺，但是也确实容易造成这样的误会。互联网逻辑相对简单，复杂的地方基本都是HTML端相对复杂的逻辑，以及数据访问的优化，所以这时三层架构的业务逻辑层就已经与用户界面层的Controller等同到了一起，数据访问层与Model层混合到一起。当然对于小型项目无可厚非，但是我个人更加倾向于将数据访问层依然独立出来，成为互联网界更加知名的Service层，其实我无法说Service层是属于业务逻辑还是数据访问，原因有二：互联网对性能的极致追求，使得我们不便做过多的抽象，所以业务逻辑往往都被和数据库的SQL访问产生强依赖Service层往往需要自己管理数据的Cache，所以从这一点来说他也相当于混合了业务逻辑层和数据访问层的工作。