我在软件体系结构（“域模型”，“域驱动设计”等）的上下文中经常看到这个术语。我已经用谷歌搜索了，但是有很多不同的定义。那到底是什么呢？

埃里克·埃文斯（Eric Evans）撰写的《领域驱动设计》一书中的“领域”一词具有特定含义。这就是软件的意义所在。

埃文斯走得更远。在他看来，即使使用相同的软件，也存在子域。这是本书中涉及“战略设计”的部分。

有三个“域”：核心域，支持域和通用域。有时，他会将这些称为子域。

Evans还非常关心软件背后的实际业务，这本书不仅针对开发人员，而且还面向架构师和经理，他们需要了解软件与业务如何协同工作，而这正是他在讨论战略设计时所关注的和这些子域。

因此，核心领域是软件的一部分，既代表竞争优势，又代表软件的“存在理由”。这就是软件的一部分，这就是为什么客户购买该软件而不是购买其他软件的原因。通常，Evans将其视为包含最小百分比代码的域。您可以将其视为最重要的20％。这是您不能真正购买的部分，它可能只是整个软件的单个模块或组件。

支持领域仍然很重要，并且对于组织而言可能是唯一的，但并不像核心领域那么重要。没有它，该软件将不那么有价值，其核心依赖于它。您可能自己编写了软件中的多个模块，这些模块对核心执行了重要但支持的功能。

通用域是最不习惯定制的，在某种意义上是软件的最不重要的部分。您可能是在内部编写的，但直接购买或使用知名的开源软件可能会更有效率。系统的这一部分可能并非特定于您的整个域，因此，例如，无论您有运送包裹的运输系统还是管理患者的健康记录系统，通用域都是这​​些系统的一部分，这是普遍且公正的只需要在那里工作就可以了。这可能构成了整个系统的大部分，但不一定如此。

从业务角度来看，确定您的核心域并集中您的开发资源非常重要。Evans提供了许多视频，尤其是在InfoQ网站上，他在那里详细解释了这些概念。

因此，尽管我们经常谈论软件中的“领域”，但就DDD而言，它并不像看起来那样简单。

我应该指出，DDD的概念不一定存在于更广泛的软件社区中。其他开发人员，作者和产品人员可能有不同的想法和定义，有些更微妙，有些更少。甚至其他写过DDD的作者也可能会在Evans的书中掩盖这些概念，但是我觉得这些概念在编写和计划软件项目时仍然有用。

该域名是在你试图解决使用软件的问题真实世界场景。每个领域都具有该领域的专业知识，词汇和工具。

领域的具体示例可以是“使用高速旋转刀具自动加工复杂零件”。完成此任务的软件和硬件系统称为CNC 铣床。

域的另一个示例是公司的会计部门。

进一步阅读
Martin Fowler的有限上下文

这仅表示您正在处理的问题空间。例如，如果您正在构建一个电子商务网站，则您的域将是“电子商务”，并且将涉及与客户/公司的销售实践相关的流程。因此，领域模型将代表产品，发票或运输记录。

一个领域是知识领域。它可能是一项活动，其中存在由软件解决的问题。（Wiki，DDD社区）

埃里克·埃文斯（Eric Evans）在书中使用货运来解释什么是DDD。在他的示例中，domain就是关于shipping的一切。货物如何运输，管理，运输和跟踪等。它带有自己的特定规则，语言和流程。这些将创建域模型，对象，服务等。

创建应用程序时，您将获得某种授权，就像现实世界中的运输一样，并不是每个人都可以访问仓库。如何授权用户以及如何授予权限 可能不在域内，因为该信息可能与货物运输无关。

简而言之：域名就是您开展业务的地方。如果您的业务是运送货物-运送货物将属于您的领域。如果您的业务是在对人员进行身份验证和授权，那么这将是您的领域。

来自域驱动设计：解决软件核心问题的复杂性，Eric Evans：

每个软件程序都与其用户的某些活动或兴趣有关。用户将程序应用到的主题领域是软件的领域。

航空公司预订计划的领域涉及真正的人乘坐真正的飞机。

会计程序的领域是金钱和财务。

源代码控制系统的领域是软件开发本身。

领域模型就是领域专家头脑中的知识的“严格组织和选择性抽象”。

巴勒莫在描述洋葱结构时提供了此摘要

在最中央，我们看到了域模型，它表示为组织的真实性建模的状态和行为组合。

福勒反过来提供

包含行为和数据的领域的对象模型。

如果您正在查看较新的定义，则很可能会遇到域模型和数据模型不同的引用。我不认为意义的改变与重点的改变一样多-与将行为写下来的不同方式相比，对行为建模（数据响应模型外部信息的方式变化）具有更丰富的复杂性和变化性。

由于您可能已经知道什么是域，因此我想下一步将尝试定义子域，域模型，更重要的是定义有界上下文。

我首先从阐述领域的观点开始。

域

域是我们居住的现实：域的实体，行为，服从的法律。它以一种或另一种形式存在于我们之前，并将存在于我们之后。它的存在并不取决于我们的意识。营销人员提出了新功能并进行了市场分析，大客户经理与客户进行了交流，软件开发人员使业务流程自动化。这就是为什么将域称为问题空间的原因。

子域

DDD意味着将域分解为子域，以简化其建模和理解。您经营一家企业的事实就意味着至少有一个主要的商业价值。与您一起赚钱的那一个。我们开始做生意的那个。因此，即使您不知道“核心域”之类的词，它也仍然存在。子域也是如此：您可能需要簿记，人力资源和技术支持，但这是次要的。

领域模型

无需对提取的子域进行整体建模。我们感兴趣的每个子域中都有一组特定的规则。某个子域中要获得一定的业务结果所必需的规则集称为模型。

有界的背景

最重要的是，有界上下文是逻辑边界。

当定义了子域和核心域时，就该实现代码了。有界上下文定义了某些子域的适用性的明显边界。在该区域中，某个子域有意义，而其他子域则没有意义。它可以是演讲，演示文稿，具有由工件定义的物理边界的代码项目。

下一步是什么？

如果您对有界上下文概念与子域概念如何关联，如何定义子域和有界上下文，如何表示彼此之间的通信以及如何在考虑这些概念的情况下组织团队感兴趣，那么您可能对此感兴趣进一步阅读。