针对微服务的建模语言

模式是针对特定上下文中发生的问题的可重用解决方案，这一概念来源于建筑行业。模式语言是为了解决特定领域内问题的相关模式的集合。软件模式是通过定义一组互相协作的软件元素来解决软件架构或这几问题。

常用的模式结构包括三个重要部分：

需求（forces）：需求部分描述了必须解决的问题和围绕这个问题的特定上下文环境。需求有时是相互冲突的，所有要确定好优先级，根据排序级别对其取舍。
结果上线文（resulting context）：即采用模式后可能带来的后果。结果上下文提供了更加完整、从不偏不倚的视角来描述的解决方案，这有助于更好的决策。可以从以下三个纬度指标决策：

好处：这个模式的好处和它解决了什么需求
弊端：这个模式的弊端和它没有解决哪些需求

问题：使用这个模式所引入的新问题

相关模式（related patterns）：这部分描述了这个模式和其他模式之间的关系。通常模式之间存在5种关系：

前导（predecessor）：前导模式是催生这个模式的需求模式，例如，微服务架构模式是除单体架构模式以外整个模式语言中所有模式的前导模式。【概念很绕，简单理解就是将当前所采用的模式作为整个架构决策的出发点，即事件原由也就对标前面的需求部分】
后续（successor）：后续模式是指用来解决当前模式引入的新问题的模式，例如，如果你采纳了微服务架构模式，你需要一系列的后续模式来解决诸如服务发现、断路器等微服务带来的新问题。【实际上就是结果上下文中的弊端】
代替（alternative）：当前模式的替代模式，提供了另外的解决方案，例如，单体机构和微服务架构就是互为替代的模式，他们都是应用架构风格。【也就是解决同样问题要有对标方案，不能只有一种。通常我们在做架构设计的时候，也会针对不同场景给出多种方案，列出其特点根据需求和结果价值权衡取舍。】
泛化（generalization）：针对一个问题的一般性解决方案。
特化（specialization）：针对特定模式的具体解决方案。

通过这些关系相关的模式集合形成所谓的模式语言。模式语言中的模式共同解决特定领域中的问题。微服务架构中的模式语言是一组模式，可以帮助架构师使用微服务架构构建应用程序。

上图来源于https://microservices.io/patterns/cn/index.html，图中Chris通过单体应用到微服务架构转变过程案例说明模型语言的概念。

微服务的建模语言可以为是一种业务的抽象，而业务抽象又会让我们想到中台这个概念。想到中台又会想到中台建设过程中总被提起的领域模型。搞清楚 DDD、微服务和中台之间的关系至关重要。中台本质是业务模型，微服务是业务模型的系统落地，DDD 是一种设计思想，它可以同时指导中台业务建模和微服务设计，它们之间就是这样的一个铁三角关系。