对于DDD来说，什么是有界的上下文？

Question

在阅读沃恩·弗农( Vaughn Vernon )的“实现领域驱动设计”()一书时，我一直无法很好地理解什么是有限度的上下文。

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

然而，同一本书的第三章提到了有界上下文之间的集成技术。然而，这似乎意味着有限的上下文实际上是某种类型的软件系统或人工制品。

Martin简要地讨论了有界上下文(http://martinfowler.com/bliki/BoundedContext.html)的概念，但并没有真正澄清这个问题。

说到底，什么是有限度的上下文？它是一个子域组吗？子域的模型和语言？子域的实现？如果没有这些答案，就很难理解如何将现实问题空间分解为有界的上下文。

Answer 1

有界上下文和子域存在于不同的层次上。

子域是问题空间的一部分，它是系统的自然分区，通常反映组织的结构。因此，物流和运营可能与发票和账单分开。Eric根据给定场景中的业务相关性来区分核心、支持和通用子域。

上下文是解决方案空间的一部分。他们是模特。拥有它们、反映域--子域划分...but生活并不总是那么容易，这将是件好事。而且，您可能已经膨胀了包含所有内容的遗留域，或者同一子域中的更多上下文(即旧的遗留应用程序--某个人正在开发的替代应用程序)。

要有有界的上下文，您需要有一个模型，并在它周围有一个显式的边界。在许多使用数据库共享数据的数据驱动应用程序中，到底缺少了什么。

另一种-正交-方式，可以看到它可能是以下。普适语言是指每一个术语都有一个明确的定义的特殊情况，它不具有扩展性。你越放大它，模糊感就越多。如果您想要实现精确、明确的模型，您需要明确它们的边界，并使用许多小的无处不在的语言，每一种语言都在一个有界的上下文中，并且有一个明确的目的。

Answer 2

领域驱动设计技术被用来帮助我们建立我们所生活的世界的模型。这些模型作为想法存在于参与项目的人的头脑中。

因为心灵感应还处于起步阶段，所以这些想法在人们之间用单词和短语进行交流。

单词和短语在最好的时候可能是模棱两可的。为了帮助我们减少歧义，我们使用“语境”来澄清它们的含义。

当人们深深地沉浸在一个跨越数年的软件项目中时，他们似乎忘记了上下文，从上下文中产生的想法变成了转化为代码中的变量名称的单词。

新手来到这个项目，开始使用和使用它的语言。也许他们是用户，也许他们是开发人员。如果没有提供给他们的背景，他们就会从自己的生活经历中得出自己的背景(因此，也就是意义)。

这个新应用的上下文将指导新开发人员如何重构或开发代码。如果他们应用了错误的上下文，他们就会重构和开发代码，也许会稍微有点错误。错误的方向，无论多么微小，都会引起更大的问题。

在我看来，“有限上下文”仅仅是一个“清晰的上下文”，传递给项目新手，这样他们就不会应用他们自己的任意上下文来玷污我们的完美模型。

团队明确承认，this phrase在this part of the project中的确切含义是this thing (而不是您可能认为的that thing)。

就像把你的花园和邻居的花园划清界限是个好主意一样。当他们开始在你修剪整齐的草坪上挖花坛时，你可以明确地指定边界，这样你就不会生气。

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

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

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

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

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

此外，事物与其他事物相互作用，有限的上下文也需要相互作用。因此，有不同的模式来描述这些交互是如何发生的。请参阅Eric Evan的书“域驱动设计”第14章，了解这些不同的模式:共享内核、客户供应商、Conformist、反分裂层、分离方式、开放主机服务、发布的语言。

Answer 3

基本上，有界上下文定义了某些子域的适用性的有形边界.这是一个抽象的领域，一个特定的子域有意义，而其他的则没有意义。所以，这可以是一个谈话，一个演示，一个由工件定义的物理边界的代码项目。

在不同的情况下，我使用了三个不同的视角，或者是有界上下文概念的隐喻。

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

从领域专家的角度来看，有界上下文是一个实现特定业务流程、应用某种普适语言的领域，某些术语具有明确的意义，而其他术语则不然。因此，它可以是在一张纸或白板上绘制的矩形。

对于软件开发人员来说，即从静态代码的角度来看，有界上下文代表了我围绕相应子域设计模型的一种方式；也就是说，它是您的代码库。更具体地说，它是IDE中的一个项目(或多个项目)。这就是为什么说有界上下文属于解决方案空间的原因。

我非常喜欢有界上下文概念的这示例。

另一个重要的问题(如果不是最重要的问题)是如何识别有界上下文。如果您不正确地这样做，您将以聊天性、不可维护性和紧密耦合的服务 (也称为分布式单石 )结束。