软件架构模式-GitHub.PDF

软件架构模式Mark Richards 著 版权归 © 2015 O’Reilly Media, Inc. 所有. 原书发布链接为Software Architecture Patterns. 译员信息 本书的译员均来⾃开发技术前线 。 译者 个⼈简介 Mr.Simple 乐于分享，热爱开源的⼯程师，个⼈博客 chaossss 追⻛筝的吃货，汪〜。个⼈博客 Allenlsy 计算机科学爱好者，Rails程序员。个⼈博客 BillonWang 做好玩的事情，交好玩的朋友。个⼈博客 dupengwei 乐于分享的移动互联⺴开发⼯程师 Charli Hu 喜欢英语，不放弃编程的菇凉。 ⺫录 简介 第⼀章分层架构 第⼆章事件驱动架构 第三章微内核架构 第四章微服务架构 第五章基于空间的架构 附录A 关于作者 简介 对程序员来说很常⻅⼀种情况是在没有合理的程序架构时就开始编程，没有⼀个清晰的和定义好的架构的时 候，⼤多数开发者和架构师通常会使⽤标准式的传统分层架构模式（也被称为多层架构）——通过将源码模 块分割为⼏个不同的层到不同的包中。不幸的是，这种编码⽅式会导致⼀系列没有组织性的代码模块，这些 模块缺乏明确的规则、职责和同其他模块之间的关联。这通常被称为架构⼤泥球。 应⽤程序缺乏合理的架构⼀般会导致程序过度耦合、容易被破坏、难以应对变化，同时很难有⼀个清晰的版 本或者⽅向性。这样的结果是，如果你没有充分理解程序系统⾥每个组件和模块，就很难定义这个程序的结 构特征。有关于程序的部署和维护的基本问题都难以回答，⽐如：程序架构是什么规模?应⽤程序有什么性能 特点?应⽤程序有多容易应对变化?应⽤程序的部署特点是什么?架构是如何反应的? 架构模式帮助你定义应⽤程序的基本特征和⾏为。例如，⼀些架构模式会让程序⾃⼰⾃然⽽然地朝着具有良 好伸缩性的⽅向发展，⽽其他架构模式会让程序朝着⾼度灵活的⽅向发展。知道了这些特点，了解架构模式 的优点和缺点是⾮常必要的，它帮助我们选择⼀个适合⾃⼰特定的业务需求和⺫标的的程序。 作为⼀个架构师,你必须证明你的架构模式的决策是正确的,特别是当需要选择⼀个特定的体系结构模式或⽅法 的时候。这本迷你书的⺫的就是给你⾜够的信息让你去做出正确的架构决策。 第⼀章分层架构 分层架构是⼀种很常⻅的架构模式，它也叫N层架构。这种架构是⼤多数Jave EE应⽤的实际标准，因此很多 的架构师，设计师，还有程序员都知道它。许多传统IT公司的组织架构和分层模式⼗分的相似。所以它很⾃ 然的成为⼤多数应⽤的架构模式。 模式分析 分层架构模式⾥的组件被分成⼏个平⾏的层次，每⼀层都代表了应⽤的⼀个功能(展⽰逻辑或者业务逻辑)。 尽管分层架构没有规定⾃⾝要分成⼏层⼏种，⼤多数的结构都分成四个层次:展⽰层，业务层，持久层，和数 据库层。如表1-1 ，有时候，业务层和持久层会合并成单独的⼀个业务层，尤其是持久层的逻辑绑定在业务层 的组件当中。因此，有⼀些⼩的应⽤可能只有3层，⼀些有着更复杂的业务的⼤应⽤可能有5层或者更多的分 层。 分层架构中的每⼀层都着特定的⾓⾊和职能。举个例⼦，展⽰层负责处理所有的界⾯展⽰以及交互逻辑，业 务层负责处理请求对应的业务。架构⾥的层次是具体⼯作的⾼度抽象，它们都是为了实现某种特定的业务请 求。⽐如说展⽰层并不需要关⼼怎样得到⽤户数据，它只需在屏幕上以特定的格式展⽰信息。业务层并不关 ⼼要展⽰在屏幕上的⽤户数据格式，也不关⼼这些⽤户数据从哪⾥来。它只需要从持久层得到数据，执⾏与 数据有关的相应业务逻辑，然后把这些信息传递给展⽰层。 分层架构的⼀个突出特性是组件间关注点分离 (separation of concerns) 。⼀个层中的组件只会处理本层的逻 辑。⽐如说，展⽰层的组件只会处理展⽰逻辑，业务层中的组件只会去处理业务逻辑。多亏了组件分离，让 我们更容易构造有效的⾓⾊和强⼒的模型。这样应⽤变的更好开发，测试，管理和维护。 关键概念 注意表1-2中每⼀层都是封闭的。这是分层架构中⾮常重要的特点。这意味request必须⼀层⼀层的传递。举 个例⼦，从展⽰层传递来的请求⾸先会传递到业务层，然后传递到持久层，最后才传递到数据层。 那么为什么不允许展⽰层直接访问数据层呢。如果只是获得以及读取数据，展⽰层直接访问数据层，⽐穿过 ⼀层⼀层来得到数据来的快多了。这涉及到⼀个概念:层隔离。 层隔离就是说架构中的某⼀层的改变不会影响到其他层:这些变化的影响范围限于当前层次