在SummerSoC 2020上，我介绍了我的Stefan Kapferer和Olaf Zimmermann的关于“域驱动的服务设计”的论文（已接受；即将发布）
您可以在此处下载幻灯片。
本文涵盖以下主题：
- 战略领域驱动设计（DDD）的服务分解
- 上下文映射器 DSL（CML）作为DDD上下文映射的机器可读方法
- 分解标准：如何分解一个领域并识别“边界上下文”？
- 体系结构重构（AR）作为CML的模型转换
- 逐步分解域的增量方法
- 从DDD模型中生成服务合同（使用MDSL语言）
战略性领域驱动的设计和上下文映射器
随着最近的微服务趋势，如何将软件系统分解为模块和/或服务的问题引起了广泛的关注。但是，这个问题并不新鲜。帕纳斯（Parnas）早在1972年就写过一篇论文“ 关于将系统分解为模块的标准”。
如今，一个流行的答案是战略领域驱动设计（DDD）。它强调在领域模型中需要一种独特的词汇（即普遍存在的语言），并建议将领域分解为所谓的“有界上下文”。一个域通常由多个子域组成。
在下面演示示例中：保险领域由几个子域组成：客户，保单，风险等。
当实现SOA模块化或微服务时，您将面临一个问题，即系统应有多少个（微）服务或模块。
DDD建议识别有界上下文，并为每个上下文实现一个子系统（服务或模块）。有界上下文建立了一个边界，领域模型只在该边界内有效。
有界上下文中的概念和领域对象应清晰明确地定义（根据无所不在得统一语言）。如下例所示，绑定上下文可以实现一个或多个子域的一部分：
当我们将领域分解为多个有界上下文时，这些上下文如何相互集成的问题自然而然地引起了。
这就是DDD上下文映射和上下文映射起作用的地方。上下文映射说明了绑定上下文之间的关系以及它们之间的数据如何流动。以下上下文图显示了我们虚拟保险场景的一个示例：
图中“ U”和“ D”表示“上游”和“下游”。«Upstream-Downstream»关系中的数据始终从上游流向下游。
这意味着：上游向下游公开其一部分域模型（例如，通过公共API）。下游上下文可以符合上游模型（CONFORMIST），也可以实施反腐败层（ACL）以保护自己的模型不受上游更改的影响。
上游模式是开放主机服务（OHS）和发布语言（PL）。
如果上游上下文实现了一个公共和开放的API（banq注：RESTful等的API），该API应该由多个下游上下文以统一的方式使用，则将应用OHS模式。
已发布的语言（PL）是域模型的一部分（banq注：JSON或XML格式或二进制）。此模式经常与OHS结合使用。
如果某个关系上标有“客户/供应商”，则这两个团队紧密合作，这意味着上游团队会根据下游（客户）的要求来优先处理其工作。
在对称关系（伙伴关系和共享内核）中，存在相互依赖关系，与上下游关系相比，它们导致更强的耦合。
...
服务分解
将软件系统或域分解为上下文映射（多个有界上下文）是一个迭代和进化的过程。通过提供基于不同分解标准的多个AR，可以使用Context Mapper“逐步”分解域。下图说明了这种想法：
从领域分析开始，并首先将其域建模为一个单独的上下文。通过在战略DDD级别上应用AR（请参见上图），用户可以“逐步”分解域并迭代地开发上下文映射。我们还在战略DDD级别上提供了重构，该重构允许分解和合并Bounded Context中的聚合。
原型化上下文地图后，集成子系统（绑定上下文）的API便成为重要的设计问题。如何设计/实现它们，以及域模型的哪些部分暴露于其他有界上下文？上下文映射器使您可以从CML上下文映射中生成MDSL合同。通过使用MDSL工具，您甚至可以生成特定于技术的合同和代码，以在以后快速创建应用程序原型。
总结
我们的目标是通过提供易于使用的战略性DDD的有用工具，从而来支持领域/服务建模人员、软件架构师和软件工程师。取代人类的工作不是我们的目标！这些工具有望为您提供支持，但是您仍然需要了解您的领域的人员以及建模者和架构师的经验来设计好的领域模型和API。
详细点击标题见原文。