1. 引言

领域一词，主要有以下两个意思：

一国主权所达之地。
学术思想或社会活动的范围。

不管是指国家的主权范围也好还是学术活动范围，都是在讲一个范围，一个界限。
比如我们常说的，学术领域、思想领域、技术领域、语言领域、物理领域、医学领域、游戏领域、JAVA领域、.NET领域等等，它们中不管是泛指还是特指某个领域，都是限定在某个范围之内的。
由此可见领域一词重在范围的界限。

下面我们就回归正传，DDD，Domain Drive Design，全称，领域驱动设计。那这个领域具体指什么呢，在DDD中有什么特殊含义呢？

2. DDD中的领域

我们要先弄明白DDD是干什么的。
DDD是一种综合软件系统分析和设计的面向对象建模方法，旨在帮我们设计高质量的软件模型，是一种解决复杂中大型软件的一套行之有效的方式。

那既然是用来解决软件问题，那自然要弄清楚软件系统的业务需求。

那就以我们之前的办公设备微信公众号开发的案例为例，来分析一下。
虽然是微信公众号开发，但其实涉及到的主要是商品、用户、订单、报价、支付、物流、报修相关业务，其本质还是电子商务系统开发。
反过来看，任何电子商务网站也都涉及到商品、用户、订单、支付、物流这些核心业务，而这也正是所有电商领域都会涉及到的业务。

其实不管是普通的电子商务网站，还是像京东、淘宝、亚马逊这样的电商平台，其本质都是电商领域，只不过是系统的复杂性不同而已。

所以我们的案例也就可以理解为一个基于微信公众号平台的电商领域普通电子商务网站的开发。

通过以上的举例说明，只是想说明，DDD中的领域也并没有什么特别之处，它只是被界限在指定的业务需求之中，有了更清楚的范围边界。

其实也可以参照原著《领域驱动设计:软件核心复杂性应对之道》的总结：

一个领域本质上可以理解为就是一个问题域，只要是同一个领域，那问题域就相同。所以，只要我们确定了系统所属的领域，那这个系统的核心业务，即要解决的关键问题、问题的范围边界就基本确定了。

弄清了业务领域，接下来就是领域的拆分。下面我们就来细化我们案例中的业务场景，来介绍引入的核心域和子域的概念。

3. 子域

回到我们的案例，基于微信公众号的电子商务网站的开发。
我们先抛开DDD，按照我们传统的开发设计思路，以数据优先的方式，上来就建表写代码，而且按照我们一贯的作风，肯定会先设计Product表，因为电商的哪一个环节都跟商品息息相关，在这里Product对象就是一个核心对象。
那既然Product对象是核心对象，那Product对象所处的领域--商品列表领域，是不是就是我们这一节讲的核心域？
答案是否定的。
DDD跟我们传统的软件开发设计过程不同，它注重领域建模。
在了解了业务领域的业务规则之后，我们为了完成对一个复杂领域的分析，往往我们要先简化之，即领域拆分。可以理解为把领域中的复杂大问题，拆分成小问题，各个击破。也就是将一个领域拆分成多个子域，再针对每个子域进行分析。而子域又可以分为核心域、通用子域、支撑子域。
那什么是核心域、通用子域、支撑子域呢？
下面我们就对我们的案例进行拆分来梳理这些概念。

对于我们的案例涉及到的业务，商品、用户、订单、报价、支付、物流、报修相关业务，我们可以大致拆分成以下几个子域：

商品子域
用户子域
销售子域
订单子域
支付子域
物流子域
维修子域

3.1 核心域

如果从几个子域中确定核心域，这也许难以决定，没关系。我们先来回答一个问题。
什么是电商网站？在线商品买卖平台。
电商领域的核心就是为了商品买卖，
我们知道开发这个电商网站的目的是为了寻求推广和销售利润的最大化。
所以自然而然核心域就是销售子域了。

为什么要先确定核心域？
因为作为一个业务的核心存在，它最能体现系统的核心价值，也是核心竞争力。如果要最大化系统的价值，我们必然要在核心域的设计上更胜一筹。
确定核心域后，我们在进行开发设计的时候就有了主次之分。

3.2 通用子域

通用子域，顾名思义，也就是服务于整个业务领域。比如我们要为该网站提供一个日志系统，用来记录一些日志。我们可以设计一个日志子域来供其他子域使用。

3.3 支撑子域

支撑子域的作用于业务系统的某些重要业务而非核心业务，它关注于业务的某一方面，来支撑完善业务系统。
我们划分的子域中除了销售子域，其他都可以说是支撑子域。
比如物流子域，就是专注于物流相关业务，支撑着订单发货以及物流跟踪的重要流程。

4. 总结

本节主要结合案例，简要梳理了DDD中领域、核心域、通用子域、支撑子域的定义。

领域是有范围界限的，也可以说是有边界的。
核心域是业务系统的核心价值所在，承载着一个系统的重中之重。
通用子域可以理解为业务系统所有子域的消费者，提供着通用服务。
支撑子域专注于业务系统的某一重要的业务，来支撑和完善业务系统。

这一节遗留了一个问题，那就是文章开头就说领域是有范围界限的，但这个范围界限在DDD中如何表述呢？这就是下一篇文章要讲的——限界上下文。

DDD理论学习系列（1）-- 通用语言
DDD领域驱动之干货（一）
从事件和DDD入手来构建微服务
WeText项目：一个基于.NET实现的DDD、CQRS与微服务架构的演示案例
【DDD/CQRS/微服务架构案例】在Ubuntu 14.04.4 LTS中运行WeText项目的服务端

原文地址：http://www.cnblogs.com/sheng-jie/p/6865784.html

.NET社区新闻，深度好文，微信中搜索dotNET跨平台或扫描二维码关注

DDD理论学习系列（2）-- 领域相关推荐

DDD理论学习系列（9）-- 领域事件
1. 引言 A domain event is a full-fledged part of the domain model, a representation of something that ...
DDD理论学习系列（8）-- 应用服务amp;amp;领域服务
1. 引言单从字面理解,不管是领域服务还是应用服务,都是服务.而什么是服务?从SOA到微服务,它们所描述的服务都是一个宽泛的概念,我们可以理解为服务是行为的抽象.从前缀来看,根据DDD的经典分层架构 ...
DDD理论学习系列（8）-- 应用服务领域服务
DDD理论学习系列--案例及目录 1. 引言单从字面理解,不管是领域服务还是应用服务,都是服务.而什么是服务?从SOA到微服务,它们所描述的服务都是一个宽泛的概念,我们可以理解为服务是行为的抽象.从 ...
DDD理论学习系列（6）-- 实体
DDD理论学习系列--案例及目录 1.引言实体对应的英语单词为Entity.提到实体,你可能立马就想到了代码中定义的实体类.在使用一些ORM框架时,比如Entity Framework,实体作为直接 ...
DDD理论学习系列（13）-- 模块
1. 引言 Module,即模块,是指提供特定功能的相对独立的单元.提到模块,你肯定就会想到模块化设计思想,也就是功能的分解和组合.对于简单问题,可以直接构建单一模块的程序.而对于复杂问题,则可以先创 ...
DDD理论学习系列（12）-- 仓储
1. 引言 DDD中Repository这个单词,主要有两种翻译:资源库和仓储,本文取仓储之译. 说到仓储,我们肯定就想到了仓库,仓库一般用来存放货物,而仓库一般由仓库管理员来管理.当工厂生产了一批货 ...
DDD理论学习系列（11）-- 工厂
1.引言在针对大型的复杂领域进行建模时,聚合.实体和值对象之间的依赖关系可能会变得十分复杂.在某个对象中为了确保其依赖对象的有效实例被创建,需要深入了解对象实例化逻辑,我们可能需要加载其他相关对象, ...
DDD理论学习系列（5）-- 统一建模语言
1.引言上一节讲解了领域模型,领域模型主要是将业务中涉及到的概念以面向对象的思想进行抽象,抽象出实体对象,确定实体所对应的方法和属性,以及实体之间的关系.然后将这些实体和实体之间的关系以某种形式(比 ...
DDD理论学习系列（4）-- 领域模型
1.引言我们还是先来拆词理解,领域模型可以拆为"领域"和"模型"二词. 领域:按照我们之前的文章的理解,DDD中的领域是指软件系统要解决的问题,如我们的办公设 ...

DDD理论学习系列（2）-- 领域