你好，我是钟敬。今天咱们开始第一个迭代。
在开篇词中我们说过，为了让你更好地掌握DDD，咱们这门课设置了一个贯穿始终的案例。我们会模仿真实的敏捷开发过程，把案例分成三个迭代，每个迭代的需求规模逐渐扩大，复杂性也逐渐增加。为了满足变化的需求，就会出现新的问题，为了解决这些问题，咱们就会引入新的DDD模式和实践，或者深化之前学过的知识。
今天开始，咱们通过迭代一，实现一个“麻雀虽小、五脏俱全”的项目。打通从需求分析，到领域建模，再到架构设计，最后到数据库和代码实现的完整闭环。
学完迭代一，你就可以理解DDD实践中那些最基本的套路了，甚至还可以在自己实际工作的项目里，选择一个小的“切片”，开始尝试落地DDD。
当然了，在实践过程中，你可能也会遇到这样那样的问题，别急，这些问题的答案，很可能就在迭代二和迭代三的内容里。当然，你也可以把问题写在评论区，咱们一起讨论。
现在我们就来看一下这个迭代的具体需求。
这次迭代的需求
假设咱们俩要一起创业，经过了一轮市场调研，我们发现很多中小企业，都有诸如考勤管理、工时管理、项目管理、请假管理等通用的需求。我们姑且把这些应用统称为“企业管理系统”。
现在咱们顺便回顾一下领域驱动设计里“领域”这个词的含义。领域指的是软件要解决的那些业务问题，所以也可以叫业务领域，英文叫Business Domain。在这个例子里，“企业管理”就是咱们要处理的领域。
过去，这些企业只能自建或购买软件系统，安装到公司内部的服务器上，甚至还要有自己的机房，软硬件以及运维成本都比较高。如果咱们能够把这些应用放在云上，那么企业就只需要有选择地购买我们提供的服务，按需付费就好了，不再需要自建机房，也不需要自己运维，可以有效降低企业的成本。
咱们这种系统，其实是基于SaaS的应用。所谓SaaS，英文全称是Software-as-a-Service，中文译作“软件即服务”。也就是说，软件不再像传统上那样交付并安装在客户本地，而是安装到云上，成为客户可以直接使用的服务。
SaaS应用往往有个特点，用户五花八门，需求也是复杂多变。有些应用，如果只针对一个企业开发，本来挺简单，一旦放到云上，需求复杂性就会急剧上升。所以这次迭代，我们先做最简单的需求，后面两个迭代中我们再逐渐增加更多的灵活性。
由于云原生是这两年的热点，所以咱们凭这个点子幸运地拉到了投资，成立了一个叫做“卷卷通”的公司，开始着手研发系统的第一个版本。
由于不同行业的需求可能有较大差别，我们决定先聚焦于一个细分市场，之后再扩大范围。这个细分市场是我们比较熟悉的软件服务企业。这些企业会向自己的客户提供软件咨询、软件开发等等服务。
我们发现，这些企业的员工一般都工作在各个项目上。企业为了满足管理诉求，希望员工每周在系统中填报自己在哪些项目上花了多少时间，也就是所谓的报工时。所以我们第一步先来满足这个功能。但是，为了完成报工时的功能，我们还要首先对组织、人员、项目等等进行管理。
这里还要说一下，在领域驱动设计中有一个重要的角色叫做“领域专家”，叫业务专家也可以。领域专家需要对业务有总体性和本质性的把握，同时对业务发展也要有一定前瞻性，也就是说，心里要有一盘棋。
所以领域专家往往不是一线业务操作人员，在很多企业中，是那些干了很多年业务，逐渐成长起来的中级管理干部。还有一些企业，由产品经理担任领域专家。
那么，下面就由我暂时充当一下领域专家，详细说一下需求。
需求一：租户管理
这个系统可以给多家企业使用，每家企业的数据是隔离的。这些作为客户的企业，在云原生应用里，习惯上叫做“租户（tenant）”。咱们的系统就是要对这些租户进行增删改查等管理。这样的系统叫多租户系统。
假设我们做市场调研时，研究了一家叫“零零后科技有限公司”的企业，我们这个迭代，就先来满足这家企业的需求。
需求二：人员与组织管理
除了对租户进行增删改查等管理，我们还必须还有人员和组织管理。
零零后公司有多个开发中心，每个开发中心下有多个开发组。此外，还有公司直属的人事部、财务部等部门，系统要能够管理这些部门。
而且，我们对员工也要进行增删改查，并且把员工分配到部门。每个员工只能属于一个部门，比如王小牛属于开发一组。
下面这个图说明了需求中的人员和组织结构：
需求三：项目管理
接下来的需求是项目管理。
首先，租户要向它的客户提供服务，就要和客户签订合同，然后完成合同下的项目。比如说，租户零零后公司的客户可能包括安安保险公司、开心电信等等。那么，租户零零后公司就得为安安保险公司，安排一堆程序员帮他们开发核心保险系统项目，也得为开心电信，安排几个咨询师帮他们的敏捷转型做咨询。
这里具体的需求是这样的：
- 一个租户企业可以有多个客户，可以在系统里对客户信息进行增删改查，每个客户都有一个客户经理来跟进；
- 租户可以和它的客户签订多份合同，在系统中对合同信息进行增删改查，每个合同都有一个销售人员负责，可以开始和结束合同；
- 一个合同下可以有多个项目，系统可以对项目进行增删改查，每个项目有一个项目经理；
- 可以在系统中开始和结束项目，需要记录开始和结束时间等信息。项目结束以后，很多事情就不能随便做了。
下图说明了客户、合同、项目等概念的关系：
需求四：人员分配
有了项目，我们就可以把员工分配到项目上，也可以让一个人退出项目。而且，一个项目可以有多个人参与，一个人又可以同时参与多个项目。
除了这些，我们在把人分配到项目上的时候，还要记录每个人预计的投入百分比。比如说，王小牛在A项目上准备投入自己30%的时间，同时在B项目准备投入40%的时间等等。
之所以要记录预计的投入时间，是为了让企业能够在总体上调配人力资源。比如说管理人员看到王小牛还有30%的空余时间，就可以把它同时再安排到另一个项目上，以便实现“内卷最大化”。
下图说明了人员和项目投入的关系：
需求五：工时登记
把人员分配到项目上以后，我们就可以登记工时了。
我们这里规定只有当一个员工分配到一个项目上以后，才能通过这个项目报工时。这样的规定，一来是为了符合公司的管理要求，一个员工不能随意参加一个项目；二来也可以防止员工不小心把工时填到错误的项目上。
而且每个员工每周都需要在系统中填报工时，登记自己哪一天在哪个项目上投入了多少时间。当然，员工可对工时进行查询和修改，还可以为每天的投入的时间填写备注。你可以看一看工时登记的界面原型，进一步理解需求。
另外，尽管咱们尽量采用接近真实的案例，但也无法面面俱到。为了突出重点，我们这个课程还是省略了一些需求，比如说人员登录和权限控制等等。
现在，第一个迭代的需求基本上就说完了。这些需求看起来简单，其实关键点还是挺多的。而且更重要的是，在实际项目里，这些需求未必会这么清清楚楚、白纸黑字地列出来给你，更多是隐藏在领域专家的脑子里，需要我们去挖掘。
还有一些需求，我故意没有说得很详细，而是要在后续的开发过程中逐步揭示。这也是为了模拟实际项目的场景。
DDD的基本开发过程
那么，我们怎么用一套系统化的方法，抽丝剥茧、一步一步地把需求落实到代码呢？咱们看看下面这张图，它表示了领域驱动设计中的主要流程。
你可以看到，在整个开发流程中，首先是要捕获行为需求，也就是传统软件工程里的“获取需求”。这一步，我们要识别需求里有哪些流程、哪些功能，每个功能由什么人操作，会产生什么结果。
在传统软件工程中，这一步常用的方式是用例建模，也就是用Use Case来建模。在这套课程里面，我们会用DDD中比较流行的一种方法，叫做“事件风暴”。
接下来，我们就可以进行领域建模了，也就是通过建立领域模型，把需求里的主要业务知识描述清楚。DDD的领域模型，大体上相当于传统软件工程中的分析模型。
基于领域模型，我们就可以做架构设计，包括进程间和进程内的架构。比如说微服务设计、中台设计都属于进程间架构。而DDD分层架构，通常说的是进程内架构。
然后就可以根据领域模型进行数据库设计，最后是代码实现。
这样，就形成了一个基于DDD的开发闭环。其实，在实践中，尤其是对敏捷软件开发来说，这些步骤不是线性的，而是反复迭代、互相穿插的。
DDD是以领域模型为核心的。所以，我们可以把上面说的步骤分成模型的建立和模型的实现两部分。
模型的建立阶段，使用的都是业务术语，归根结底来自业务人员，业务人员不仅能听懂，而且负责评价建模的正确性。而模型的实现，则是业务人员不需要理解也不关注的，会包含技术实现方面的内容。这两者的边界很重要，我们在后面还会反复提到。
总结
好，今天就讲到这里，我们来总结一下。
这节课，我们概述了迭代一的目的和需求，并且介绍了DDD的基本开发过程。
咱们要开发的是一个基于SaaS的企业管理系统，它的需求主要包括租户管理、人员与组织管理、项目管理、人员分配和工时登记这几部分。
在介绍需求的同时，我们也穿插着介绍了领域和领域专家的概念。领域就是软件要解决的业务问题。领域专家则是十分了解业务知识本质的人。
DDD开发的基本流程是以领域模型为核心的。整个流程可以分为模型的建立和模型的实现两部分。其中模型的建立一定要使用业务语言，而模型的实现则增加了技术语言。模型的建立，是通过领域专家和开发人员的协作共同完成的。
最后，今天讲的所有需求我都汇总到了下面这张表里，你可以看一下，方便后面的实战。
思考题
1.如果这是一个真实的项目，你觉得还缺少哪些需求？
2.希望在你自己的项目里，选择一个不太复杂的部分，然后跟着后续的课程，按照DDD的方法尝试实践。
好，今天的课程结束了，有什么问题欢迎在评论区留言，下一节课我们将通过事件风暴的方式，理清系统的行为需求，并为进一步的领域建模打下基础。
精选留言
2022-12-10 23:07:49
1. 如果这是一个真实的项目，你觉得还缺少哪些需求？
回答：至少还缺少数据报表等分析、项目管理中的审批管理、流程监控等。
此外，我还有一个疑问：DDD中的领域模型，与MVC中的M、ORM中的M相比，三者有哪些异同？
2022-12-08 13:16:24
DDD 是以领域模型为核心的。所以，我们可以把上面说的步骤分成“模型的建立”和“模型的实现”两部分。
模型的建立：事件风暴 -> 领域建模。
模型的实现：架构设计 -> 数据库设计 -> 代码实现。
DDD 的基本开发过程：事件风暴 -> 领域建模 -> 架构设计 -> 数据库设计 -> 代码实现。
后面所有的需求，我相信应该都是围绕整个开发过程来讲述的。
期待后面大家轮流来总结，收获满满！
2023-07-10 11:41:03
1. 从全局视角找出「大功能模块」
2. 在「大功能模块」中找出「子功能」
3.「子功能」推荐以一级列表平铺呈现，可以降低复杂度（反例见需求二），更利于分析问题
详见文章末尾「图例说明」https://wyyl1.com/post/23/06/
2022-12-08 09:19:11
2022-12-08 21:54:07
2、多租户的数据隔离和权限管理不知道属于业务需求还是技术需求；
2022-12-30 22:47:26
2022-12-08 13:32:09
开发时没有体会过“模型的实现”-架构设计这一步，而是：直接根据需求设计数据库 -> 代码实现。
以我现在的水平，看到文末的需求列表就可以直接实现功能了：
1. 划分功能模块：多租户、人员与组织管理、项目管理、人员分配、工时登记
2. 根据功能描述设计数据库
3. 编码实现
感觉到的问题：
1. 这是一门 DDD 的课程，我这样的写出的代码会无比僵硬，没有《DDD》书中提到的有些地方是柔软的
2. 因为代码僵硬，就算使用 TDD 进行开发，有利于后期重构，但也会因代码简陋（没有设计）给重构工作带来很大的工作量
3. 请教钟老师，推荐哪种方法实践：
A. 是先按自己的想法实现需求汇总里列出的所有需求，再跟着后续课程迭代功能（我能吃苦，但希望不要走弯路）
B. 选一个功能点实现，但是担心选中的这个功能点后续文章直接省略了，重点讲别的功能点（这就有点尴尬了）
C. 或者您有更好的建议
2022-12-10 12:50:01
2.可以增加的功能 项目工作台，项目仪表盘，项目自动关联，工时缺省填报，工时未填告警等等一系列功能，能做的太多，不罗列了。
3.需要考虑的功能 跨租户业务。 比如商机分销，比如顾问跨租户支援。 这些需要刻画租户模型 租户间协作合同 以及发生跨租户业务后双边的履约刻画以及之间的履约映射 财务结算。
5.少了一个很重要的过程，如何做需求确认。 在未知领域采集业务知识（发散），提炼业务模型/功能点（收敛），评估功能点的必要性（依赖关系）和性价比（按量化价值和成本打分）（发散），制定mvp和演进路线（收敛）。 虽然ddd没写，但这个过程得做，必然可能在开始就凉了。 演进规划一定会有变化，无论是方向还是功能集，可以逐步调整，但不能没有。
2022-12-08 17:12:35
二、从用户+场景+行为动机+目标来拆解需求，目前，有些场景也欠缺，譬如：如何分配管理权限等
2022-12-08 09:41:57
2022-12-08 08:26:04
2022-12-09 10:05:27
1. 需要提供的功能（这里就为后期提供接口功能做铺垫，也算是为功能架构设计做铺垫）
2. 功能下面一些数据之间的关系（这里就为后期做数据库设计做铺垫），比如一个合同下面可以多个项目，这里就是 1：N 的关系
不知道这样理解是否正确
2022-12-09 00:26:28
发现了第一版需求汇总还来得急没分层
2024-11-14 22:03:28
2023-10-13 14:30:38
2023-08-05 23:14:42
2023-08-05 23:00:42
2023-04-25 08:37:23
2023-02-10 10:56:12
1、菜单权限、数据权限控制，
2、审批流程
2023-01-27 22:52:47
1、客户、合同、项目
2、客户经理、销售、项目经理
他们都缺少了说明什么事件让这些过程向下流转，或者说触发了什么事件到达了什么程度就可以到下个环节
缺少了这些说明感觉开发很难做