访问官网
Github上下文映射
上下文映射描述了限界上下文和团队之间的联系,通过一系列模式来表示。共有九种上下文映射模式和三种不同的团队关系。上下文映射模式从多个角度描述了各种关系,如服务提供、模型传播或治理方面。这种多样化的视角使您能够全面了解团队和限界上下文之间的关系。
上下文映射可用于分析现有系统或应用程序环境,也适用于前期设计考虑。然而,我们发现许多人难以根据现有DDD书籍中的定义开始使用上下文映射模式。本GitHub仓库旨在通过提供备忘单和Miro入门套件,帮助您使用上下文映射。
上下文映射团队关系和模式概述
团队关系
互相依赖
当两个团队或限界上下文的软件成果或系统需要一起交付才能成功运作时,它们就是互相依赖的。这些团队之间的数据、功能和能力通常有着密切的相互联系。这些团队还需要大量沟通来协调彼此的工作(参见合作伙伴模式)。
上游下游
上游团队的行动会影响下游团队,但下游团队的行动对上游团队没有显著影响。"上游团队可以独立于下游团队的命运而成功"(引自Eric Evans的DDD参考文献)。
自由
如果其他限界上下文的变化不会影响某个限界上下文或其中工作的团队的成功或失败,那么该限界上下文或团队就是自由的。因此,这些团队之间没有任何组织或技术上的联系。
上下文映射模式
目前领域驱动设计社区中的大多数出版物描述了九种上下文映射模式。
开放主机服务
"一种协议,允许将您的子系统作为一组服务进行访问。开放协议,让所有需要与您集成的人都可以使用它。增强和扩展协议以处理新的集成需求,除非单个团队有特殊需求。在这种特殊情况下,使用一次性转换器来增强协议,以便共享协议可以保持简单和连贯。"(来源:Eric Evans的DDD参考文献)
提供开放主机服务的团队通常处于上游位置,而使用它的客户端是下游团队。下游的团队可以自由选择成为循规蹈矩者或构建防腐层。
循规蹈矩
"通过完全遵循上游团队的模型,消除限界上下文之间转换的复杂性。虽然这会限制下游设计师的风格,可能不会产生应用程序的理想模型,但选择遵从enormously简化了集成。此外,您将与上游团队共享一种通用语言。上游处于主导地位,所以让他们更容易沟通是有好处的。利他主义可能足以让他们与您分享信息。"(来源:Eric Evans的DDD参考文献)
防腐层
"作为下游客户端,创建一个隔离层,以您自己的领域模型的术语为您的系统提供上游系统的功能。该层通过现有接口与其他系统通信,几乎不需要或根本不需要修改其他系统。在内部,该层根据需要在两个模型之间进行一个或两个方向的转换。"(来源:Eric Evans的DDD参考文献)
共享内核
"用明确的边界指定团队同意共享的领域模型的某个子集。保持这个内核很小。在这个边界内,除了模型的这个子集之外,还包括与模型那部分相关的代码子集或数据库设计子集。这些明确共享的内容具有特殊地位,未经与其他团队协商不应更改。"(来源:Eric Evans的DDD参考文献)
合作伙伴
"当两个上下文中任何一个的开发失败都会导致两者的交付失败时,在负责这两个上下文的团队之间建立合作伙伴关系。建立一个协调开发计划和联合管理集成的流程。 两个团队必须在接口的演变上进行合作,以适应两个系统的开发需求。相互依赖的功能应该安排在同一版本中完成。"(来源:Eric Evans的DDD参考文献)
客户/供应商开发
"当两个团队处于上游-下游关系时,上游团队可能独立于下游团队的命运而成功,下游的需求会以各种方式得到解决,并产生广泛的后果。[...] 在两个团队之间建立明确的客户/供应商关系,这意味着下游的优先事项会影响上游的计划。协商和预算下游需求的任务,以便每个人都了解承诺和时间表。"(来源:Eric Evans的DDD参考文献)
已发布语言
"两个限界上下文模型之间的转换需要一种通用语言。[...] 使用一种文档完善的共享语言,能够表达必要的领域信息作为通用交流媒介,根据需要进行翻译。"(来源:Eric Evans的DDD参考文献)
广为人知的已发布语言示例包括iCalendar或vCard。已发布语言通常与开放主机服务结合使用。
各自为政
当两个限界上下文之间没有重要关系时,它们可以被分开。 "宣布一个限界上下文与其他上下文完全没有联系,允许开发人员在这个小范围内找到简单、专门的解决方案"(来源:Eric Evans的DDD参考文献)
大泥球
系统(的一部分)因混合模型和不一致的边界而变得一团糟。不要让这个糟糕的模型传播到其他限界上下文中。大泥球标志着模型或系统质量不佳。您要确保这种混乱不会传播到其他限界上下文中。
上下文映射最佳实践
没有必要将所有模式和团队关系都放入一个大型上下文映射中。这样的上下文映射会随着时间的推移而增长,并变得难以理解。您将被迫向大量不同的利益相关者解释如此复杂的上下文映射,这些利益相关者由于他们的角色或工作性质而具有不同的视角。因此,建议注意以下提示:
- 优先选择针对具体问题的小型上下文映射
- 记录并解释您将要使用的模式
- 使用不同的视角和多个上下文映射来表示这些视角
针对具体问题的小型上下文映射
上下文映射能够回答各种各样的问题,例如:
- 给定系统的模型如何在应用程序环境中传播?
- 某个团队对其他团队有什么影响?
- 谁对给定团队有影响?
- 如何进行政治博弈?
正如您所看到的:这些问题非常具体,我们可以基于一个大型上下文映射来回答它们,但这样的上下文映射迟早会变成信息过载。
因此:
使用针对特定问题的较小上下文映射。只在这些较小的上下文映射中包含有助于回答这些问题的模式。
记录并解释您将要使用的模式
上下文映射是一种强大的技术,可以可视化系统和团队之间的关系。然而,对于不熟悉领域驱动设计或上下文映射模式的人来说,它们可能难以理解。即使某些模式名称对某些利益相关者群体来说也不是不言自明的,某些定义也是如此。
因此:
在开始绘制上下文映射之前,您应该决定要使用哪些模式,并为自己和上下文映射的利益相关者提供这些模式的解释。确保所有使用您的上下文映射的人都理解这些模式。对于这样的解释,举例总是一个好主意。
上下文映射备忘单
这里有一个备忘单,包含上下文映射模式的简要描述:
Miro远程上下文映射入门套件
如果您使用Miro进行上下文映射,有一个面板备份可以帮助您开始使用所有模式、团队关系和边界的对象。此外,Miro面板还包含一些示例,帮助您入门:
您还可以查看(并评论)Miro上的入门套件只读版本
使用Context Mapper进行上下文映射
如果您想在代码仓库中维护上下文映射,Context Mapper允许您在文本文件中描述上下文并从中生成图表。Context Mapper可通过在线(通过Gitpod在浏览器中)或通过Visual Studio Code和Eclipse的IDE插件使用。
进一步阅读
- 动态重组团队
- 先驱者、定居者和城镇规划者
- 团队拓扑
- [使用上下文映射可视化社会技术架构](https://speakerdeck.com/mploed/visualizing-sociot
