什么是架构模式和架构风格?

本文探讨如下几个问题:

  • 架构模式和架构风格有区别吗?
  • 什么是架构模式?
  • 什么是架构风格?
  • 架构模式和架构风格的区别是什么?
  • 有哪些架构模式?
  • 有哪些架构风格?

架构模式=架构风格?

  • 如果你搜索「架构模式和架构风格的区别」,你会发现答案千差万别:
  • 有的观点认为架构模式和架构风格是一个东西,只是叫法不同
  • 有的观点认为架构风格是架构模式的外在表现
  • 有的观点认为架构模式和架构风格是不同的两个概念(具体有什么不同,又有不同的观点)
    • 有的观点认为架构模式解决问题,架构风格不解决问题(例如:建房子有建房子的模式,而无论是建成哥特风还是现代风,都还是房子)
    • 有的观点认为架构风格是高层级的架构模式

我个人的观点是:架构模式是特定问题域下,架构风格的具体应用!

我们来一个个的说!

什么是架构模式?

在说架构模式之前,我们先来看看我们常挂在嘴边的设计模式是怎么定义的!

GOF在《Design Patterns》这本书的「What is a Design Pattern?」小节,对设计模式下了一个明确的定义:

The design patterns in this book are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context.
设计模式描述了一组类和对象的关系,用以解决特定上下文内的某个常见的设计问题!

那我们可以这么定义架构模式:架构模式描述了一组组件之间的关系,用以解决特定上下文内的某个常见的架构问题!

Wiki上也给架构模式做了类似的定义:

An architectural pattern is a general, reusable solution to a commonly occurring problem in software architecture within a given context 架构模式是一个通用的、可重用的解决方案,用以解决特定上下文内的某个常见的架构问题!

什么是架构风格?

Roy Thomas Fielding博士,在他的REST论文中,对架构风格做出了定义:

An architectural style is a coordinated set of architectural constraints that restricts the roles/features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style. 一种架构风格是一组协作的架构约束,这些约束限制了架构元素的角色和功能,以及在任何一个遵循该风格的架构中允许存在的元素之间的关系。

Martin Flower在微服务文章中的说明,也间接支持了此定义。文中首先明确「微服务」是一种架构风格,然后给出了微服务所具有的特征(就是约束),具有这些约束的系统就可以说是使用了微服务架构风格!

微软的Azure文档也给出了类似的定义:架构风格即约束!

架构模式和架构风格的区别

上面我们分别给「架构模式」和「架构风格」下了定义!那么「架构模式」和「架构风格」到底有什么区别呢?

我们来看架构模式的定义,可以抽出几个关键词:

  • 模式:描述的是一种关系(类与类的关系、组件与组件的关系)!并且这种关系是可复用的!
  • 特定上下文:说明这种关系的适用场景是有限制的,只能在特定场景下才能适用!
  • 常见问题:说明这种关系是解决某个问题或某类问题的解决方案,是有针对性的!

我们再看架构风格的定义,它仅仅就是约束!约束了组件之间的关系!

所以「架构模式」和「架构风格」的区别就在这里:

  • 架构模式是针对某个特定上下文的某类问题的解决方案
  • 架构风格是一个解决方案

举个例子

如果你仔细看看Wiki中列出的架构风格和架构模式,你就能看出点端倪了!

架构模式架构风格
Three-Tier
Multilayered architecture
Model-View-Controller(MVC)
Domain Driven Design
Micro-Kernel
Blackboard Pattern
Sensor-Controller-Actuator
Presentation–Abstraction–Control
CQRS
Component-based
Monolithic application
Layered (or multilayered architecture)
Pipes and Filters
Database-Centric
Blackboard
Rule-based
Event-driven aka implicit invocation
Publish-subscribe
Asynchronous Messaging
Plug-Ins
Microkernel
Reflection
Domain Specific Languages(DSL)
Client-Server (2-tier, 3-tier, n-tier exhibit this style)
Shared Nothing Architecture
Space-based Architecture
Object Request Broker
Peer-to-Peer
Representational State Transfer (REST)
Service-Oriented
Cloud Computing Patterns
MicroServices

更具有说服力的是CS架构风格,可以看到此架构风格后面有个阐述「2-tier, 3-tier, n-tier exhibit this style」,意思是两层架构、三层架构、n层架构都是CS架构风格的一种表现形式。而可以看到,三层架构是一个架构模式!

你有没有一个疑问?两层架构、三层架构、N层架构为什么不是分层架构风格的表现形式?而是CS架构风格的一种表现形式?
这个问题在后面的CS架构和分层架构中会具体阐述。

再具体一点,我们看看CS架构的约束:

  • Server组件提供了一组服务,并监听对这些服务的请求。
  • Client组件通过一个连接器将请求发送到Server,希望执行一个服务。
  • Server可以拒绝这个请求,也可以执行这个请求并将响应发送回Client

可以看到,这里只是约束了系统分为Client和Server,以及Server和Client之间的行为。

再来看三层架构模式,三层架构一般分为:

  • Presentation tier 展现层
  • Logic tier 业务逻辑层
  • Data access tier 数据访问层

可以看到,三层架构模式比CS架构风格更具体,描述了每一层的作用。

当系统有如下需求时,就可以考虑三层架构:

  • 需要提供用户界面(不论是本地应用这样的富客户端、还是浏览器,亦或手机APP)
  • 需要访问持久层数据
  • 解耦(视图,业务、数据可独立进化)

总结

用Renan Johannsen de Paula Venilton FalvoJr在《Architectural Patterns and Styles》中对架构模式和架构风格的区别来总结一下:

  • Architecture Pattern: { problem, context } → architecture approach;
  • Architecture Style: architecture approach.

实际工作中,我们一般会说「架构」,而没有具体到是「架构风格」还是「架构模式」。这么做其实有几点好处:

  • 理解的偏差,不影响讨论和使用:虽然可能每个人对「架构风格」和「架构模式」的理解是有偏差的,但是并不会影响系统的讨论。反而,如果具体到风格还是模式,那可能就变成对「风格」还是「模式」的讨论,而不是对业务的讨论
  • 有些情况下,风格和模式的差异并不大:「架构风格」和「架构模式」的主要区别就是是否是针对某个「问题域」和「上下文」的!当一个「架构风格」应用到了某个「问题域」和「上下文」,且这个「问题域」和「上下文」也比较常见,那么这个「架构风格」在这个「问题域」和「上下文」的应用就是「架构模式」!
  • 可以少说两个字

转:https://blog.csdn.net/ivan_pig/article/details/82916191

更多文章

其他免费资料
zhou jg

拆分用户故事

在我指导的Scrum团队中,一个常见的问题是用户故事太大。 当用户故事太大时,很难理解,估计和实施。 那么,对于用户故事而言,合适的大小是多少? 我的指导是,应调整产品待办事项顶部的用户故事的大小,以便Scrum团队可以轻松地每周完成四到六个故事。

团队如何在产品待办事项列表中记录重要故事并将其分解为较小的故事? 今天给大家分享4种用于拆分用户故事的技术,基本上可以应对您工作中面临的大部分故事了。

阅读更多»

TOGAF认证考试60道情景题

免费

11月12-15日BangEA实践公开课线下补充班,广州