luoyuan的博客

好，这节课的主要内容就讲完了，我们来总结一下。DDD 主张要根据领域模型来进行数据库设计，保证数据库和领域模型的一致，从而保证数据库和业务需求以及代码的一致性。在进行数据库设计时，我们可以用物理数据模型图，也可以直接用建表语句，两者基本是等价的。为了直观，我们采用了图示的方法。对数据表、字段等等的命名，应该依据词汇表，以便保证统一语言。一般来说，领域模型中的实体映射为数据库中的表；领域模型中的属性，映射成表中的字段。同时还要根据需求补充更多的字段。

在讨论什么是领域模型之前，咱们先说说什么是模型。先来看几个例子。比如说你去买房，售楼处都会有一个沙盘模型，这样你就可以看到楼的外观、朝向、周边环境等等。但是如果要盖这个楼盘，靠沙盘模型就不行了，需要有一套详细的建筑图纸，图纸也是模型。为了对大楼进行设计，还要进行各种计算，计算用的公式也是模型，称为数学模型。另外，小孩玩的玩具车、玩具枪什么的，也是模型。事实上，现代生产和生活中，充满着各种各样的模型。从这些例子里，咱们可以发现模型的几个共同特点。首先，模型是以解决特定问题为目的的。

好，这节课的主要内容就讲完了，下面来总结一下。今天我们在上节课的基础上，继续对项目管理和工时管理进行领域建模。在这个过程中进一步深化了对“多对多”关联的理解：我们可以通过引入一个表示关联的实体，将一个多对多关联拆成两个一对多关联。我们还通过取员工上级的逻辑，学习了为实体添加操作。当模型变得比较复杂时，可以把模型划分成多个模块，使模型更容易理解。在建立完领域模型之后，我们还进行了两项实践：完善业务规则和建立词汇表。

比如说，张三是员工，李四也是员工，我们可以说，员工指一类事物。这时我们可以用 UML 中的术语说，员工是领域对象的一个类，张三和李四是这个类的实例。但在我们的需求里，租户关注的是客户和提供云应用的供应商之间的协议，背后隐含的需求可能是云平台要为这个客户分配多少硬件资源、怎样收费、提供哪个级别的备份等需求。第二个问题是，一个员工其实可以不属于开发组，而只属于开发中心，比如开发中心的主管就是这样。这时你问我：“一个组织是开发中心，另一个是开发组，那么在业务术语上可以说，这两个组织具有不同的‘什么’呢？

现在，我们对这两节关于事件风暴的课程做一个总结。事件风暴是一种通过协作的方式捕获行为需求的方法，在这个过程里，业务人员和技术人员一起消化领域知识、形成统一语言、并为领域建模奠定基础。事件风暴分为识别领域事件、识别命令、识别领域名词三个步骤。这一节课讲的是后面两个步骤。“命令”是引发领域事件的操作，可以从领域事件“反推”出来。此外，还可以识别命令的两个附加信息，一个是发出命令的“执行者”，另一个是为了完成命令要查询出的数据。“领域名词”是隐含在命令和领域事件中的名词性概念。

下面我们来总结一下。这节课，我们首先解释了用事件风暴之类的方法梳理需求的必要性，包括从头脑中挖掘需求、补充遗漏的需求、使业务人员和技术人员理解一致，以及辅助识别领域对象四点。事件风暴是从识别领域事件开始的。“领域事件”是在业务过程中，业务人员关注的那些已经发生的事情。技术事件和查询功能都不算领域事件。领域事件意味着业务流程中每个步骤的结果。这种结果导向的思维方式更容易理清业务。事件风暴中的“事件”两个字就来源于领域事件。识别领域事件的过程可以分成了两大步：第一步是参加的人，各自写出领域事件；

好，今天就讲到这里，我们来总结一下。这节课，我们概述了迭代一的目的和需求，并且介绍了 DDD 的基本开发过程。咱们要开发的是一个基于 SaaS 的企业管理系统，它的需求主要包括租户管理、人员与组织管理、项目管理、人员分配和工时登记这几部分。在介绍需求的同时，我们也穿插着介绍了领域和领域专家的概念。领域就是软件要解决的业务问题。领域专家则是十分了解业务知识本质的人。DDD 开发的基本流程是以领域模型为核心的。整个流程可以分为模型的建立和模型的实现两部分。

你好！ 这是你第一次使用 Markdown编辑器 所展示的欢迎页。如果你想学习如何使用Markdown编辑器, 可以仔细阅读这篇文章，了解一下Markdown的基本语法知识。我们对Markdown编辑器进行了一些功能拓展与语法支持，除了标准的Markdown编辑器功能，我们增加了如下几点新功能，帮助你用它写博客：撤销：Ctrl/Command + Z重做：Ctrl/Command + Y加粗：Ctrl/Command + B斜体：Ctrl/Command + I标题：Ctrl/Command + S