领域驱动设计学习记录1

领域、子域、限界上下文

Posted by boydfd on 2018-07-22 17:00:00 +0800

Recently by the same author:


大语言模型中一个调皮的EOS token

You may find interesting:


领域驱动设计学习记录2

Entity

领域驱动设计学习记录目录

第一篇

领域(Domain)

理解领域

领域的概念很好理解,就是一个组织所做的事情以及其中所包含的一切(如果这个组织设计多业务系统,这里只是指其中的一个业务系统)。

主要包含两个概念:

  1. 业务范围内的一切事物。(也就是能找到的名词)
  2. 在业务范围内进行的活动。(也就是能找到的动词)

领域的歧义

因为领域既可以表示整个业务系统,也可以表示其中的某一个核心域或者支撑子域,所以在涉及业务系统的某一方面的时候,最好直接用核心域以及核心子域来表示。

领域模型

领域模型并不是为整个领域进行构建的模型,而是为某一个子域构建的模型。

子域

子域是什么

一个例子:在一个零售商系统中,需要展示不同类别的产品,允许买家下单和付款,还需要安排物流。 则这个零售商系统中,可以分出4个主要的子域:

  1. 产品目录
  2. 订单
  3. 发票
  4. 物流

子域的特点

  1. 子域是领域的拆分,一个领域会被拆分成多个子域,有核心域、支撑子域、通用子域。
  2. 子域并不一定要做得很大,并且包含很多功能。(例如,只包含一套算法的子域,这个子域可以以模块的方式从核心域中分离出来)。

核心域

核心域是业务领域的一部分,是业务成功的主要促成因素。也就是说,是否是核心域取决于这个子域的业务价值。

支撑子域

支撑子域对应系统的某些重要方面,但是不属于核心。

通用子域

通用子域被用于整个业务系统,提供一些支持。

限界上下文

概要

限界上下文可以看成是一个范围,在这个范围中,所有用到的领域术语、词组或句子都有明确的含义。

通常我们会希望将子域和限界上下文进行一一对应。这样能将领域模型分离到不同的业务板块中去。当然要实现这一点,会很困难。

为什么要有限界上下文

每一个模型,包括它的属性和操作,在限界上下文的边界之内都是具有特殊含义的。

用一个例子来说明限界上下文的作用,一个图书出版机构需要处理图书生命周期的不同阶段,每个阶段对应不同的上下文:

  1. 概念设计,计划出书
  2. 联系作者,签订合同
  3. 管理图书的编辑过程
  4. 设计图书布局,包括插图
  5. 将图书翻译成其他语言
  6. 出版纸质版或电子版图书
  7. 市场营销
  8. 将图书卖给销售商或直接卖给读者
  9. 将图书发送给销售商或读者

在每个阶段中,虽然同样叫做”图书”,但是却在每个上下文中都需要建立不同模型。

  1. 一本书只有在和作者签订了合同后才拥有书名,书名可能在编辑过程中进行修改。
  2. 在编辑过程中,图书包含一系列的稿件,其中包括注释和校正,以及最终稿件。
  3. 页面布局由专门的图形设计师完成。
  4. 市场营销人员只需要知道图书的简介。
  5. 对于图书的销售及物流,需要的是图书的标识码、物流目的地、数量、重量等。

由于行为和需要的属性都完全不同,我们需要在每一个限界上下文中都进行book的建模。而这些不同的book对象共享一个标识。

限界上下文包含什么

  1. 模型,模型是限界上下文的一等公民
  2. 数据库Schema(前提是模型驱动着数据库的Schema设计,也就是建模人员会进行设计、开发和维护)
  3. 用户界面(如果该用户界面会驱动着模型的设计)
  4. 应用服务

限界上下文的大小

只要足够包含核心领域内的概念即可。

也就是说不应该遗漏一些概念,也不应该包含外部概念。

从技术上看限界上下文

  1. 在IDEA中,一个project就是一个限界上下文。
  2. 对于Java package来说,一个顶层模块就是一个限界上下文(com.mycompany.optimalpurchasing)

一个例子

domain-example

collaboration_context

identity_context

agile_context