最近一两个月，我一直在研究各种模式：设计模式，架构模式，容器模式，以及其他一些特定领域的模式（例如并行计算模式）等。买书、看论文、看代码后，发现自己之前对模式的理解还不够深入。因此，本文用来记录一些缺少的东西，比如模式语言、模式模式等。PS：为了阅读方便，本文标题均为缩写，全名在相关资料处结尾。重温模式为了避免Datum是最好的语言之类的问题，在此之前，我必须先解释一下我对模式的看法：图案，但他不知道那是一种什么样的图案。这是一个用于快速交流的概念词列表。模式是一种解决方案，是锤子法则，只有在遇到特定问题时才需要它。模式适用于特定场景。大多数模式对当前系统来说是无用的，往往只有少数几种模式适合。模式是知识体系的展示。你掌握了多少模式就代表你见多识广，并不一定代表真正的代码水平和能力。模式需要刻意练习，学习模式是一个漫长的过程，所以如果在理解或使用中遇到错误也不要着急。图案有很多种，计算机界普遍认为图案的起源是亚历山大的《建筑的永恒之道》。在更早的时候，也有相应的总结，但这里是最系统的技术。除了设计模式，我们的行业还有大量其他模式：容器设计模式。针对云原生应用下一系列复杂的碎片化场景，谷歌工程师发表了相关论文对此进行了总结。常见的有Sidecar、Adapter、Ambassador等架构模式。架构模式是通用的、可重用的解决方案，用于解决给定上下文中软件架构中的常见问题。此外，一些常见的架构风格，如微服务、事件驱动架构等，也从类别上归纳为架构模式。...所以，你会发现这些模式只是人们对成语的概括。寻找模式回过头来看，当我们发现自己进入了一个新的领域，并在相关领域进行架构设计时，我们会不断地去寻找各种类型的信息，然后将其拟合到设计中。事实上，我们正在寻找这个领域的模式。有了这些模式，我们就可以按照猫猫狗狗的方式设计系统，不会出现大问题。运气好的话，我们甚至可以比这个领域的大多数人做得更好——因为我们拥有的是解决此类问题的模型。这个时候，我们已经有了一个非常有优势的套路，可以帮助我们更好的进入新的领域。但是，作为一个新领域的新人，往往不知道采用哪种模型，也不清楚模型之间的关系是什么。相关书籍：《设计模式》模式分类：目录、集合、仓库在一个软件系统中，模式很少独立存在，往往多个模式组合起来解决特定问题。组织模式的一种方式是模式集合。然后，根据不同的需求，重新分类。《POSA 5》介绍的几种方式：Immediate(adhoc)organization。按级别划分：按抽象级别、粒度和规模划分。按行业组织：电信、金融、电子商务等。按分区组织：它属于架构的哪个部分。比如layer、tiers、components、packages都是partitioningorganizationaccordingtointent的例子：比如POSA，GoF的23种设计模式，DDD……接下来我们来看几个分类的例子。设计模式的组织《设计模式》一书中，介绍的概念是“设计模式空间”，这里分为三类：创建型模式：单例模式、抽象工厂模式、建造者模式、工厂模式、原型模式。结构模式：Adapter模式、Bridge模式、Decoration模式、Composite模式、Appearance模式、Flyweight模式、Proxy模式。行为模式：模板方法模式、命令模式、迭代器模式、观察者模式、中介模式、备忘录模式、解释器模式、状态模式、策略模式、责任链模式、访问者模式及其两个标准区别分别是：目的准则、什么用于完成；范围标准，指定的模式是针对类还是针对对象。DDD的组织《领域驱动设计》书也是一本模式集，这也是这本书不好读的原因之一。另一个原因是翻译这本书的人不明白什么是统一语言。《领域驱动设计》一书中，模式以各种形式组织起来，依次为四部分（PS：个人临时总结）：使用领域模型——《模型知识抽取模式》模型驱动设计积木——《模型设计模式》通过重构加深理解——“模型优化模式”战略设计——“模型边界划分模式”这个顺序其实就是我们在实施DDD过程中的设计流程，然后是分层组织，比如“战略设计”部分，根据不同的目的分为不同的集合：维护模型的完整性，如限界上下文、上下文映射等。提炼：核心域、通用域等大结构：EvolvingOrder、系统隐喻等。因此，从一个从结构上看，《领域驱动设计》是一本从小到大的书，阅读难度略大，需要一定的经验。模式分类的目的我们把“如何应用设计模式作为一个问题域”，那么模式分类就是这个问题域中的一个解决方案。在计算机的不同复杂领域，如并行程序设计、体系结构设计等，它们本身都包含着大量的模式。并且随着这些模式的进一步分类，将更有利于我们应用模式——至少在处理相同的子问题时，我们可以寻找可能的替代模式。然而，很多时候，我们往往不知道的是：我们遇到的问题是什么？角落里的模式语言如《POSA 5》的定义：模式语言与特定领域高度相关，可以为此类系统提供具体而全面的指导，包括以下几项：Whatarethemainproblemstobe解决了？这些问题应该按什么顺序解决？要解决给定的问题，有哪些替代解决方案可用？如何处理问题之间的依赖关系？在“周边”问题存在的情况下，如何最有效地解决单个问题？简单来说，模式语言是针对特定问题（如并行程序设计）抽象出模式，并包括它们之间的关系等，可以用来系统地解决这类问题。书中还提到了GerardMeszaros的观点“模式语言可以用来指导新手创建系统”。啊哈，这不就是我们想要的吗？作为进入一个新领域的新人，我们需要这样一种模式语言。虽然模式语言可以帮助我们解决这类问题，但它也隐含着自身的需求：足够的覆盖、可持续的进步和紧密的集成。根据这一系列前提，意味着设计模式语言的人应该是该领域的专家，模式本身应该是不断演进的。所以当我们把如何实现和使用模式看成是我们的问题时，模式语言就是针对这种问题来解决模式的。分布式计算的模式语言《POSA》系列大概是我们在中文世界能找到的最好的资料了。所以，这里我们又以《POSA 4》为例，《POSA 4》的全称是《面向模式的软件架构：分布式计算的模式语言》。先看图（图中的圆圈代表问题域，连续的表示是它们之间的关系，每个问题域都包含相关的模式）：POSAPatternLanguage，例如《FromMudtoStructure》开头的》（Fromchaostostructure）是一个大的问题域，对应这个问题域包含了一系列的模式，比如：MVC、layered、PAC、microkernel等。同时，对于这个问题，如果我们还需要数据库访问，那么我们就可以从数据库访问中获取相应的模式来改进我们的设计。然后，在我们进入具体的模式/问题域之后，它还详细说明了如何实现相应的模式。比如分层：在POSALayer这一系列的配合下，我们可以完善整个系统的设计。微服务的模式语言接下来，让我们看一下《微服务架构设计模式》微服务架构模式的概述：微服务模式语言从上图我们可以看到ChrisRichardson组织的微服务模式语言，为语言的多个层次分类并指出它们之间的关系。遗憾的是，这种模式语言只包括关系，缺少对某些相关关系的描述。尽管如此，总的来说，它还是可以在一定程度上帮助我们设计微服务。相关书籍：《POSA 4》、《POSA 5》、《微服务架构设计模式》模式模式从模式到模式分类，再到模式语言，我们已经有了一套完整的解决方案。最后，留给我们一些有趣的问题，比如如何发现新的模式？如何抽象现有模式。理解“模式的模式”有助于我们更好地理解设计模式。了解了设计模式后，只需要了解其背后的模式即可，不需要死记硬背每一个设计模式。那么，我们就来到了元素模式，它也是取材于一本书《元素模式》。元素模式：设计模式的模式模式来源于成语的总结，而元素模式是设计模式的提炼，即模式中的模式。ElementalDesignPatterns的核心本质是一套面向对象的基本概念。更细化地分解OO中的设计模式，我们可以得到它背后的模式。核心元素模式是：创建对象、检索、继承和抽象接口。因此，正如书中所说，结合这四个EDP，我们可以创建对，实现特定的保证，在运行时从它们建立关联，并从一种类型创建其他类型，以及创建声明，以及对未来未确定类型的保证.当我们实现方法调用时，也抽象出四个EDP：递归、委托、重定向和聚合，它们构成了设计的构建块。架构模式的模式最终回到我要抽象的问题，那么架构模式背后的模式是什么？我尝试了一个简单的反汇编：合同。输入输出、API等切分。隔离变更、明确职责等约束。功能和非功能需求、性能等封装。接口封装。合作。协作风格等等……当然，我也需要将它们重新命名，以在架构模式领域建立统一的语言。其他人虽然有点复杂，但仍然很有趣。相关资讯《元素模式》《设计模式》->《设计模式：可复用面向对象软件的基础》《POSA 4》->《面向模式的软件架构，卷 4：分布式计算的模式语言》《POSA 5》->《面向模式的软件架构，卷 5：模式与模式语言》《领域驱动设计》->《领域驱动设计：软件核心复杂性应对之道》转载请联系phodal公众号。
