架构师这本书个人感觉还是不错的。理论层面居多，很实用。
作者 Firat 译者 韩陆
分层架构是最常见的架构,也被称为n层架构。 多年以来,许多企业和公司都在他们的项目中 使用这种架构,它已经几乎成为事实标准,因 此被大多数架构师、开发者和软件设计者所熟 知。
分层架构中的层次和组件是水平方向的分层, 每层扮演应用程序中特定的角色。根据需求和 软件复杂度,我们可以设计N层,但大多数应 用程序使用3-4层。有太多层的设计会很糟糕,
将导致复杂度的上升,因为我们必须维护每一 层。在传统的分层架构中,分层包括表现层、 业务或者服务层,以及数据访问层。 表现层 负责应用程序的用户交互和用户体验(外观和 视觉)。通常我们会使用数据传输对象(Data Transfer Object)将数据带到这一层,然后 使用视图模型(View Model)渲染到客户端。 业务层接收请求并执行业务规则。数据访问层 负责操作各种类型的数据库,每个访问数据库 的请求都要经过这一层。
分层无需知道其他层如何去做,比如业务层无 需知道数据访问层是如何查询数据库的,相反, 业务层在调用数据层的特定方法时,只需关注 需要部分数据还是全部数据。这就是我们所说 的关注点分离。这是非常强大的功能,每层负责其所负的责任。
分层架构中的核心概念是管理依赖。如果我 们使用依赖倒置原则和测试驱动开发(Test Driven Development),我们的架构会有更好 的健壮性。因为,我们要保证所有可能的用例 都有测试用例。
我们需要这样的冗余,即使业务层没有处理业 务规则,也要通过业务层来调用数据层,这叫 分层隔离。对于某些功能,如果我们从表现层 直接访问数据层,那么数据层后续的任何变动 都将影响到业务层和表现层。
分层架构中的一个重要的概念就是分层的开闭 原则。如果某层是关闭的,那么每个请求都要 经过着一层。相反,如果该层是开放的,那么 请求可以绕过这一层,直接到下一层。
分层隔离有利于降低整个应用程序的复杂度。 某些功能并不需要经过每一层,这时我们需要根据开闭原则来简化实现。
分层架构是SOLID原则的通用架构,当我们不 确定哪种架构更合适的时候,分层架构将是一 个很好的起点。我们需要注意防止架构陷入污 水池反模式。这种反模式描述了请求经过分层, 但没做任何事或者只处理了很少的事。如果我 们的请求经过所有分层而没有做任何事,这就 是污水池反模式的征兆。如果20%的请求只是 经过各层,而80%的请求实际做事,这还好, 如果这个比率不是这样的,那么我们已经患上 反模式综合征。
此外,分层架构可以演变为巨石应用 (Monolith),导致代码库难以维护。