分层架构与公司组织

最近公司有一位同事在周会上做了有关SOA的分享，在开始时提出了一个问题，在我们开始一个项目时，是按照功能层面进行架构分拆(例如Customer项目，Order项目)，还是按照结构层面进行架构分拆(例如Model层，View层)。恰巧在前几天的一个后台项目重构过程中，一个同事也问了我类似的问题，所以想在这里简单记录下。

　　分层架构

　　1 我们先看传统的分层架构(Layer Pattern)，它是以结构层面对软件项目进行分层划分，将应用程序划分为多个子任务，让每个任务处于一个单独的架构层，完成独立的工作，常见的例子包括我们在项目中常常涉及的软件三层架构以及我们一直接触到的OSI五层/七层模型。分层架构听上去非常简单，但是我在这里要提一些理论上需要注意的地方：

2 第N层只能调用第N-1层的服务。这是分层架构最重要的一点，所以很多人把MVC与三层架构相混淆时请思考这一点，MVC模式中MVC之间互相耦合，Model在Controller和View之间传递，Controller处理View的逻辑，他们并不是一个分层的关系。而三层架构将用户界面层，业务逻辑层，数据访问层通过具体的接口方式彼此隔离，不存在跨层的依赖关系。

　　3 在第N-1层缓存第N层需要调用的数据。分层最大的诟病其实就在于层层调用而产生的性能消耗，所以对于分层模式来说，缓存是非常重要的一环。但是请一定注意一点，缓存是处于被调用方而非调用方，这一点有两个原因:调用方无需知道这一数据的来源，是数据库读取还是直接缓存提供调用方维持数据缓存会遇到复杂的数据同步问题。

　　4 为每一层起名。这一点看上去会很奇怪，感觉像是流入了形式主义。其实这一点的更大的作用是，名字可以让设计者、使用者更加明确这一层的作用，避免出现层次的不清晰划分。

　　5 制定好每层的错误处理策略。在大学学习Java的异常处理时一直没有想清楚，异常处理部门throw的作用，当时觉得其实出错的时候打印出错误日志或者让程序异常终止不就可以了么，为什么需要抛出呢?后来结合到分层的架构才想清楚，在分层逻辑中，每一层都有自己的错误处理步骤，例如在数据访问层遇到数据访问异常可能需要尝试重连，如果依然有问题就向上抛出，那么落实到业务逻辑层可能需要的是访问脏数据或者第三方数据，如果依然有问题就向上抛出，真正需要捕获异常而Break程序或者提示用户的只有用户界面层而已。那么落实到更抽象的层面，我们需要考虑层与层之间的调用方式，从而决定了是以异常方式丢给用户，还是状态码，或者是具体的错误信息。