关于DDD，什么是有界上下文？

在阅读沃恩·弗农（Vaughn Vernon）的《实施域驱动的设计》（Implementing Domain Driven Design）一书时，我无法很好地理解什么是真正的有限上下文。

本书将有界上下文定义为“适用领域模型的概念边界。它提供了由团队说出并以其精心设计的软件模型表达的无处不在的语言”（“本书指南”的开头部分）。此定义听起来似乎是有界上下文是子域的模型和语言，在该子域中，该子域可能恰好是核心域（似乎应该将其称为“核心子域”，但这是另一个讨论...）。对于有限的上下文提供了什么仍然有些含糊。它是一个或多个子域的分组吗？如果只有一个子域对应一个有界上下文，那么有界上下文实际上告诉我们什么？

但是，同一本书的第3章涉及有界上下文之间的集成技术。但是，这似乎暗示着有限的上下文实际上是软件系统或某种人工制品。

马丁·福勒（Martin Fowler）简要讨论了有界上下文的概念（http://martinfowler.com/bliki/BoundedContext.html），但并未真正阐明问题。

归根结底，什么是有限的上下文？它是一组子域吗？子域的模型和语言？执行一个子域？没有这些答案，似乎很难理解如何将现实问题空间分解为有限的上下文。

有界上下文和子域存在于不同级别。

甲子域是问题空间的一部分，它是一个自然分割的系统，往往反映了组织的结构。因此，物流和运营可能与开票和开票分开。Eric 根据给定方案中的业务相关性将核心子域，支持子域和通用子域区分开。

上下文是解决方案空间的一部分。他们是模特。拥有它们，反映域-子域的分区是一件好事……但是生活并不总是那么容易。您可能已经膨胀了旧的域，将所有内容都包含在内，或者在同一个子域中包含了更多上下文（例如，旧的旧版应用是某人正在构建的替代应用）。

要拥有边界上下文，您需要有一个模型，以及周围的明确边界。正是在许多使用数据库共享数据的数据驱动的应用程序中缺少的东西。

下面是另一种正交的查看方式。无处不在的语言（每个词都有一个明确定义的特殊条件）不会扩展。放大得越多，模糊性就越大。如果要实现精确，明确的模型，则需要明确其边界，并讲很多小的通用语言，每种语言都在一个有限的上下文中，并且定义明确。

域驱动设计技术用于帮助我们创建生活环境的模型。这些模型作为想法存在于参与项目的人员的心中。

由于心灵感应仍处于起步阶段，因此人们之间会使用单词和短语来传达这些想法。

最好的时候，单词和短语可能会模棱两可。为了帮助我们减少歧义，我们使用“上下文”来阐明其含义。

当人们沉迷于一个跨越多年的软件项目中时，他们似乎忘记了上下文，而这些想法却变成了单词，这些单词又变成了代码中的变量名。

新手进入该项目并开始使用和使用其语言。也许他们是用户，也许他们是开发人员。如果没有提供给他们的上下文，他们将根据自己的生活经历提出自己的上下文（并因此具有意义）。

这个新应用的上下文将指导新开发人员如何重构或开发代码。如果他们应用了错误的上下文，那么他们将以错误的方向（有时甚至是错误的方向）重构和开发代码。错误的方向，无论多么微小，都会导致更大的问题。

正如我所看到的那样，“有界上下文”仅是用于计划新手的“澄清上下文”，因此他们不会应用自己的任意上下文来污染我们精心修饰的模型。

这是一些明确的确认，由球队，即this phrase，在this part of the project手段准确this thing（而不是像你可能会想，that thing）。

最好在您的花园和邻居花园之间划上界线。您可以明确指定边界，以免当他们开始在修剪整齐的草坪上挖花床时不会生气。

这就对了。这是一个非常简单的想法，这一点是如此重要，以至于已经有很多关于它的文章。

是的 有界上下文实际上是一个边界，称为“栅栏”，可以区分项目中一个子域的上下文和另一个子域的上下文。

子域的模型和语言与其他模型和语言隔离，以避免含义上的歧义。

但是，是的。世界不是那么简单。

您和团队必须严格遵守定义的上下文。懒惰并重新构想上下文在软件构建过程中偷工减料真的很容易。

同样，事物与其他事物相互作用，并且有限的上下文也需要彼此相互作用。因此，有各种模式来描述这些交互作用是如何发生的。有关这些各种模式，请参见Eric Evan的书《域驱动的设计》第14章：共享内核，客户供应商，遵从者，反腐败层，单独的方式，开放式主机服务，发布的语言。

基本上，有界上下文定义了某些子域的适用性的一些明显边界。在某些抽象区域中，某个子域有意义，而其他子域则没有意义。因此，这可以是演讲，演示文稿，具有由工件定义的物理边界的代码项目。

在不同的情况下，我使用了三种不同的观点，即“受限上下文”概念的隐喻。

从运行时的角度来看，它表示逻辑边界，由执行模型的服务合同定义。合同可以表示为该服务的API或它发布和使用的一组事件。因此，从这个角度来看，有限的上下文与物理边界无关。

从领域专家的角度来看，有界上下文是在其中实施某些业务流程，应用某种普遍存在的语言，某些术语很明确而其他术语则没有的领域。因此，它只是在纸或白板上绘制的矩形。

对于软件开发人员而言，即从静态代码的角度来看，有限的上下文代表了我围绕相应子域设计模型的方式。特定子域使用多少个代码库？它们包含哪些概念？哪些概念适用于每个概念？这就是为什么有人说有界上下文属于解决方案空间的原因。

我真的很喜欢Bounded Context概念的这个例子。

另一个重要的问题（如果不是最重要的问题）是如何识别有限的上下文。如果您不正确地执行此操作，您将最终获得健谈，不可维护且紧密耦合的服务，也称为分布式Monolith。