初识DDD-核心思想和解决哪些痛点问题

引言

领域驱动设计的概念是 2004 年 Evic Evans 提出的 Domain-Driven Design，简称 DDD。随着软件技术发展，微服务技术架构的兴起，大家逐渐意识到领域驱动设计的重要性。我也在网上搜索查看过很多文章以及视频，看完后都是一知半解。更别说用DDD去设计一个新项目或者新模块需求了。因此我想自己去尝试一下如何去使用DDD去落地一个具体的项目设计，在这个过程中， 只要对DDD有更深次的理解，那我的目的就达到了。那么首先，我们需要先去了解一下DDD的核心思想以及解决了哪些痛点问题。

基础概念

我不会像网上大部分文章中那样直接流水式的描述定义，那样即使对每个核心概念都了解了，但是组合在一起，我相信不仅仅是我，大家也会定义模糊。

领域

首先我们抛开DDD不谈，咱们先来理解一下领域。

• 领域
  • 一种边界的划分，比如 我们买一套房子，那么售楼处的小姐姐、肯定是分为 客厅，卧室，厨房，卫生间，书房等各个居住功能不同的区域来给你去介绍。这就是在房屋领域中的各司其职的子领域。
  • 一种规则或逻辑的划分，比如 我们上学，一个学期分成多门学科，其实每一种学科就是一个领域，不同的领域有着各自的规则以及属性。

模型与建模

• 模型
  • 是对领域的抽象和模拟。
• 建模
  • 针对特定问题建立领域的合理模型

看上去比较晦涩难懂，举个例子吧，抛开 DDD以及软件开发思想，在我们装修的时候，请到的设计公司来出设计图纸，其实就是一种模型设计。而自住商品房和公建的装修设计，装修公司给出的设计方案肯定有所不同，这个针对不同领域提供不同的模型，就叫做建模。

案例 -- 商品售卖领域(电商和超市进销存)

超市进销存.png

电商.png

可以看到在不同的领域（超市和电商）中，对应的建模是不同的。

在超市进销存系统建模中，我们可以看到 当顾客选购完商品只需要 收银员扫描商品条形码 结算支付后，方可离开，而整个超市的 商品库存维护，都是依赖商品条形码来进行的。而订单 相当于超市结算小票，只提供支付单据的作用。

在电商中，用户需要查看商品信息以及图片挑选商品，因此 商品的模型中 图片，属性等内容就比较重要，同时用户购买商品是以订单为枢纽的，包括 支付，配送，售后等，因此订单在电商中起着至关重要的作用。

因此我们看一看出,同样是购买商品，在电商领域和 超市进销存领域中，他们的建模是不一样的，因此 建模一定要针对领域问题去建模。

整合概念-领域模型

《领域驱动设计》中关于领域的定义：

领域即是一个组织所做的事情以及其中所包含的一切。商业机构通常会确定一个市场，然后再这个市场中销售产品和服务。每个组织都有它自己的业务范围和做事方式。这个业务范围以及其中所进行的活动便是领域。

通俗点讲就是针对某一特定领域结合领域知识以及业务需求进行建模。

领域模型.png

核心思想

模型分解 -- 解决业务复杂性

• 领域划分:面向问题空间
  • 将一个大的领域划分成若干个子领域。
• 限界上下文:面向解决方案空间
  • 在一个领域/子域中，我们会创建一个概念上的领域边界，在这个边界中，任何领域对象都只表示特定于该边界内部的确切含义。这样边界便称为限界上下文。限界上下文和领域具有一对一的关系。识别出边界的上下文叫做限界上下文（Bounded Context）。限界上下文是一个非常有用的工具，限界上下文可以帮助我们识别出业务的边界，并做适当的拆分。

以上面所举的电商模型为例，具体DDD模型分解如下:

DDD模型分解.png

模型驱动设计-- 解决技术实现引入的复杂性

通过分层架构隔离领域层、仔细选择模型和设计方案等措施保持实现与模型一致。

这只是一种理念，我觉得与其看网上各种的解释文章不如尝试用自己的方式去理解。比如上面的举例 商品域和交易域之间，如果需要新增一个搜索功能，即面向C端用户，又面向B端用户。根据模型驱动的设计理念，应新增一个搜索域来通过一定的数据转换去实现该功能。

模型驱动设计.png

总结

本文主要围绕 DDD 领域驱动设计涉及到的一些基本概念和思想以及相应的问题进行了简单的说明，接下来我自己深入 DDD 具体落地实践。希望能有所收获。