DDD核心概念谈（一）领域模型

(笔者wo在川知乐 简称老乐）

DDD（领域驱动设计）是目前主流的软件设计思路和方法，特别是微服务大行其道以来，DDD更是作为微服务的拆分手段被推广开来。和其他设计思路比，其具备整个系统的全局视角，从需求出发，梳理出典型用户场景，实现业务逻辑、系统逻辑和部署逻辑的分析设计，打通问题域和解决方案域的壁垒，提供一揽子解决方案，使得领域模型成为系统演进的核心，从而消除设计和实现之间的mapping，进而获得易于理解、分层清晰、易于维护的软件系统。了解任何一项新技术，对概念的了解都十分重要，它们贯彻整个体系；本文就DDD中的重要概念做一些思考和阐述。

DDD核心概念谈（一）领域模型

领域模型，其实是由领域+模型两个词组成。

领域，就是我们要解决的问题域，包括领域问题+领域环境，无论有没有软件，领域问题都是客观存着的，而且随着科学技术水平的发展，会不断的以不同的面貌呈现出来；而解决手段则是随着科学技术的进步不断演进螺旋式前进的。

领域环境，解决问题本质还是需要依赖环境，环境中最重要的部分就是科技水平，比如对于购物这个问题，比如去集市或者从货郎那购买；

近代人们通过邮购的方式也可以实现远程购物；现代汽车和冰箱普及以后，人们又通过超市商场进行大规模购物；互联网出现后，特别是有线带宽和移动通信带宽大幅提升后，电子商务又成为主流的零售手段。

所以领域对应领域问题和领域环境是个互相影响、互相促进的过程。

模型，主要为解决手段服务的，不同的领域环境一般来说对应不同的模型。

就软件这种解决手段来说，需要用软件的代码元素来描述要解决的问题域和解决问题的业务流程，代码元素和领域问题里面的概念、流程间就存在一个映射，为了防止代码元素直接映射问题域的概念和流程，出现语义层次严重不匹配的情况，因为通用编程语言语义层次较低、特定问题域语义层次较高。

为什么这么说呢？大家看一个例子，比如，图形处理这个问题域，领域的几个个概念：平移/翻转/旋转等。这几个概念就把图形平移的内涵和外延表达的清清楚楚，我们说它语义层次很高；

反观用通用语言，表达时如果没有领域模型，比如平移，很可能就是一个for循环，把该图形内的每个点都平移一个位移，整个过程中充满了细节，需要n条语句才能表达清楚平移这个问题域的概念，走进去到处看到的都是树木，看不见森林，这就是语义层次很低。因此，领域模型就显得格外重要。

警报，下有烧脑内容，读者可酌情阅读，不必强求，或直接看因素三内容。

模型的建立考虑三方面因素：

一、对问题域进行离散化

问题域本身处于现实世界中，业务流程是连续的以及和周边系统是耦合的。需要把我们关注的问题剥离出来，抽取成一个个点，形成我们要解决问题的骨架，比如电商，从买家视角看，线下的时候，整个购买过程是一个分段连续的过程。对之建模的过程就要离散化，变成了一个个的点：检索、详情、下单、付款、收货、评价等，这样便于下一步的符号化处理。

二、对问题域进行符号化

对离散后的点进行抽象和组织，包括：

1、把离散后的点梳理成概念、关系（包括静态关联和动态协作）

2、概念、关系间的规律（相同部分），比如电商中的买家、买家就可以抽象成用户这个概念。

3、概念、关系间的本质（差异部分），比如用户和租户的不同。

4、概念、关系之间的相互关联，比如：

依赖关系：一对一、一对多、多对多等，根据生命周期的不同，决定关系的长久程度。

逻辑关系：and 、or、sequence、optional。

状态：激励-状态跃迁表

等等。

三、显式表达

用自然语言、图形、编程语言、三方工具等把这些概念、关系以及相互的关联显式的描述出来。

这样描述出来的这个东东就是领域模型。

领域模型把领域进行了离散、抽样、解耦、抽象和组织，从而得到一个比较符合业务特征和变化方向的干净的，简化的，语义足够高的领域元语。（土鳖扛铁牛）（to be）