模式分类(什么是营销模式)

最近一两个月，我一直在研究各种模式:设计模式、架构模式、容器模式，以及特定领域的其他模式(比如并行计算模式)。

买书，看论文，看代码，发现自己之前对模式的理解还不够深入。所以这篇文章是用来记录一些缺失的东西，比如模式语言，模式模式等等。

PS:为方便阅读，本文标题略，全称在最后相关资料中。

模式的再探讨

为了避免数据是最好的语言的问题，在此之前，我必须解释一下我对该模式的看法:

模式是通常方式的总结，不限于编程。相当一部分人习惯使用各种设计模式，却不知道这是一种什么样的模式。这是一个概念词汇，用于快速交流。

是满足锤子定律的模式解。只有在遇到特定问题时，您才会用到它。

模式适用于特定场景，大部分对当前系统无用，只有少部分适用。

它是模式知识体系的展示。掌握了多少模式，解释的再多也是见多识广，不一定代表真正的代码水平和能力。

模式需要刻意的练习，学习模式是一个漫长的过程，所以你总会遇到理解错误、解决错误、使用错误的情况。别担心。

模式有很多种，计算机行业普遍认同模式的起源是亚历山大的《建筑的永恒之道》。在更早的时候，有相应的总结，但这里是最系统的技术。

除了设计模式，在我们的行业中还有很多其他模式:

容器设计模式。对于云原生应用下一系列复杂的分数场景，Google工程师发表了相关论文进行总结，如Sidecar、Adapter、Ambassador等。

架构模式。模式是一种通用的、可重用的解决方案，用于解决给定环境下软件架构中的常见问题。此外，一些常见的架构风格，如微服务、事件驱动架构等，也被归纳为架构模式。

……

所以，你会发现这些模式只是人们习惯用语的总结。

寻找模式

回过头来看，当我们发现自己正在进入一个新的领域，进行相关领域的架构设计时，我们会不断地寻找各种材料，然后将它们融入到设计中。其实我们是在找这个领域的模式。有了这些模式，我们就可以像猫画虎一样设计一个系统，不会有什么大问题。

幸运的话，我们甚至可以在这个领域比大多数人做得更好——因为我们拥有的是解决这类问题的模式。

这个时候我们已经有了一个非常有优势的套路，帮助我们更好的进入新的领域。但是，作为一个新领域的新人，我往往不知道应该采用哪种模式，也不确定模式之间存在什么样的关系。

相关书籍:设计模式

模式分类:目录、集合、仓库

在一个软件系统中，模式很少是独立存在的，但往往是多个模式组合起来解决特定的问题。组织模式之一是模式集合。然后，根据不同的需求，我们进行分类。如POSA 5中所述，有几种方法:

特设组织。

按层次:按抽象、粒度、尺度的层次。

按领域组织:电信、金融、电子商务等。

根据分区组织:架构属于哪个部分。例如层、层、组件和包都是分区的例子。

按意图组织:如POSA，GoF的23种设计模式，DDD

……

接下来，我们来看几个分类的例子。

设计模式的组织

在《设计模式》一书中，介绍的概念是“设计模式空房间”，在这里分为三类:

创建模式:单例模式、抽象工厂、构建器模式、工厂模式和原型模式。

结构模式:适配器模式、桥接模式、装饰模式、组合模式、外观模式、共享模式和代理模式。

行为模式:模板方法模式、命令模式、迭代器模式、观察者模式、中介器模式、备忘录模式、解释器模式、状态模式、策略模式、责任链模式和访问者模式。

其划分的两个标准是:目的标准，完成什么；范围标准，指定的模式是用于类还是对象。

DDD组织

领域驱动设计也是模式的集合，这也是这本书不好读的原因之一。另一个原因是这本书的译者没有理解什么是统一语言。

在《领域驱动设计》一书中，模式以各种形式组织起来。四个部分依次是(PS:个人临时总结):

领域模型的应用——“模型知识抽取模式”

模型驱动设计的基石——“模型设计模式”

通过重构加深理解——“模型优化模式”

策略——“模型边界划分模型”

而这个序列实际上是我们在实现DDD的过程中的设计过程，然后分层组织，比如“战略设计”就是根据不同的意图分成不同的集合:

维护模型的完整性，如边界上下文、上下文图等。

细化:核心域、一般域等。

大结构:进化顺序、系统隐喻等。

所以从结构上来说，《领域驱动设计》是一本从小到大的书，阅读难度略大，需要一定的经验。

分类的意图

我们把“如何应用设计模式作为一个问题域”，那么模式分类就是这个问题域中的一个解决方案。

在计算机的不同复杂领域，如并行编程、架构设计等。，它们本身包含了大量的模式。随着这些模式的进一步分类，对我们应用模式会更有帮助——至少在处理同样的次要问题时，我们可以寻找可能的替代模式。

然而，很多时候，我们往往不知道的是:我们遇到的问题是什么？

角落里的模式语言

根据POSA 5中的定义，模式语言与特定领域高度相关，可以为这类系统提供具体而全面的指导，包括以下内容:

要解决的主要问题是什么？

这些问题应该按什么顺序解决？

对于给定的问题，有哪些可供选择的解决方案？

如何处理问题之间的依赖关系？

当存在“外围”问题时，如何最有效地解决单个问题？

简单来说，模式语言是针对一个具体问题(比如并行编程)的抽象模式，包含了它们之间的关系，可以用来系统地解决这类问题。

这本书还提到了杰拉德·梅萨罗什的观点，即“模式语言可以用来指导初学者创建系统”。啊哈，这不就是我们想要的吗？作为一个新领域的新人，我们需要这样的模式语言。虽然模式语言可以帮助我们解决这类问题，但也意味着它自身的需求:全覆盖、可持续进展、紧密集成。根据这一系列前提，意味着这种模式语言的设计者应该是行业内的专家，模式本身也应该是不断进化的。

所以，当我们把如何实现和使用模式当成我们的问题时，那么模式语言就是解决这类问题的模型。

分布式计算的模式语言

POSA系列大概是我们在华人世界能找到的最好的资料了。所以，再以POSA 4为例。POSA 4的全称是面向模式的软件架构:分布式计算的模式语言。

我们先看图(图中圆圈表示问题域，连续表示它们之间的关系，每个问题域包含相关的模式):

POSA模式语言

比如“娴从Mud到Structure”(从混沌到结构)的开头是一个大的问题域，对应的问题域包含了一系列的模式，比如MVC、分层、PAC、微内核等。同时，针对这个问题，如果我们需要数据库访问，那么我们可以从数据库访问中得到相应的模式来改进我们的设计。

然后，在我们进入具体的模式/问题域之后，它还详细介绍了如何实现相应的模式。如分层:

POSA层

在这一系列的配合下，我们可以完善整个系统的设计。

微服务模式语言

然后，我们来看看微服务架构设计模式中微服务的架构模式概述:

微服务模式语言

从上图我们可以看到Chris Richardson编写的微服务模式语言，它将语言进行了多层分类，并指出了它们之间的关系。遗憾的是，这种模式语言只包含关系，而缺少一些相关关系的描述。

即便如此，总体来说，还是能在一定程度上帮助我们设计微服务。

相关书籍:POSA 4，POSA 5，微服务架构的设计模式

模式的模式

从模式到模式分类，再到模式语言，我们已经有了一套完整的方案。最后，我们还剩下一些有趣的问题，比如如何发现新的模式。如何抽象一些已有的模式？

对“模式的模式”的理解将有助于我们更好地理解设计模式。理解了设计模式之后，你只需要理解它们背后的模式，就不需要去死记硬背每一个设计模式了。

所以，我们来到了元素模型，它是基于一本叫做元素模型的书。

元素:设计模式的模式。

模式来源于习惯用法的总结，而元素模式是设计模式的提炼，即模式中的模式。元素(基本设计模式)是一组面向对象的基本概念。

通过更仔细地拆分OO中的设计模式，我们可以得到它背后的模式。核心元素模式是:创建对象、检索、继承和抽象接口。因此，正如书中所说，通过组合这四个edp，我们可以创建对，实现特定的保证，在运行时建立此后的关联，从一种类型开始，建立其他类型，并创建带有关于未来和未确定类型的保证的语句。

当我们实现方法调用时，我们还抽象了四个edp:递归、委托、重定向和聚合，它们构成了设计块。

架构的架构。

最后回到我要抽象的问题，那么架构模式背后的模式是什么？我尝试了一个简单的拆卸:

合同。输入输出、API等。

分裂。隔离变更，明确责任等。

制约因素。功能和非功能需求、性能等。

封装。接口封装。

协作。协作风格等。

……

当然，我需要他们重新命名它，以建立一个架构模式领域的统一语言。

其他的

虽然有些复杂，但还是很有意思的。

相关资料

元素模式

设计模式->设计模式:可重用面向对象软件的基础

Posa4->面向模式的软件体系结构，第4卷:分布式计算的模式语言

POSA 5》>《面向模式的软件体系结构，第5卷:模式和模式语言》

领域驱动设计->领域驱动设计:处理软件核心复杂性的方法