├── DDD领域建模流程模板.ppt └── README.md /DDD领域建模流程模板.ppt: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dddtalk/ddd/08c37652a253fb428b38f32f97b49f4b360cd64f/DDD领域建模流程模板.ppt -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | ##### 图书馆借书还书领域建模 2 | 3 | ###### 案例简述 4 | 现要设计一个系统,支持学校图书馆的图书管理。支持学校学生进图书馆进行借书、还书,以及相关查询的场景,具体业务场景描述如下。 5 | 6 | ###### 业务场景描述 7 | 1. 管理员入库新的图书 8 | - 如果是全新的图书,则需要先登记图书,通过扫码图书条形码识别图书编号。 9 | - 如果是已经存在的图书,则只需要更新图书的库存 10 | 2. 学生借书 11 | - 学生持卡进图书馆 12 | - 图书管理员扫码图书卡条形码,识别图书卡号。 13 | - 图书管理员扫码图书条形码,识别图书编号。 14 | - 图书管理员更新每本书的数量(如果同一本书借多本的话)。 15 | - 提交借书信息 16 | 3. 学生还书 17 | - 学生持卡进图书馆 18 | - 图书管理员扫码图书卡条形码,识别图书卡号。 19 | - 图书管理员扫码图书条形码,识别图书编号。 20 | - 图书管理员更新每本书的数量(如果同一本书还多本的话)。 21 | - 提交还书信息 22 | - 图书归还的时候如果超期就要交罚款 23 | - 不需要跟踪一件书的新旧折损 24 | 4. 查询相关场景 25 | - 查询图书馆某本书当前还有多少库存。 26 | - 查询某个图书卡当前已借的书。 27 | - 查询图书卡的借书记录。 28 | - 查询图书卡的还书记录。 29 | - 查询某本书的被借记录。 30 | - 查询某本书的被还记录 31 | 32 | ###### 业务讨论 33 | - 全新的书:是指图书馆之前没有这本书。识别方法是扫描图书条形码的时候系统自动查询该图书是否存在。 34 | - 查询某本书得记录:学生是不关心,但是管理员有可能关心,比如遇到纠纷时,要查询某本书到底被哪些人借过了。 35 | - 在图书馆里需要追踪一本图书的状态,是在馆、借出、遗失、不可借等等,此时,我们说图书就是具体那一本,但是,我们也会说,这本书还有得借吗?这时可能可能说的是一本书的所有副本是不是还有剩余,所以它的数量可能是大于等于0的数。 36 | - 图书:案例中的图书都不是指副本,是指一本书,它可能在图书馆有10个副本。 37 | - 馆藏号 38 | - 同样的图书应该是用同一个编码,只是每本图书还有一个批次编码表示唯一,这样统计当前图书量时你才能知道这本书还有多少存货 39 | - 我通常习惯从两头去分析,一方面是业务场景,一方面是对象(物)。定义好这两头,再去理其中的关系和域 40 | - 我觉得借还是两种状态,刚好它牵涉到两个行为,至于库存不是一码事。而后面很多的报表又要重新定义出新实体了 41 | - 一本书:表示一本书,更多的强调一个“商品”,我们可以跟踪书的库存 42 | 一件书:表示一本书的某一件,一件书表示可以拿在手上的实实在在的“一本物理书” 43 | - 跟踪一件书的新旧折损,我没有在业务场景中提到,可以理解为需求不需要 44 | - 图书馆不跟踪每一个副本,也就是图书实例,而只跟踪书 45 | - 不过,我觉得可以再增加一个需求,就是图书归还的时候如果超期就要交罚款 46 | - 具体怎么判断超期以及罚款的规则,大家可以定一下 47 | - 更正一下,馆藏号和条码号是一样的,应该加上索书号,isbn 就是书的身份行 是唯一的,而索书号是图书馆给每一本书编的号码 用来查询书所在的馆藏位置 条码号是图书馆给自己馆藏的书加的一个私有的”身份证号” 48 | - 我觉得可以按照这个思路去分析: 49 | - 第一步,找出有哪些业务实体; 50 | - 第二步,理清业务实体之间的关系; 51 | - 第三步 业务实体有哪些基本属性; 52 | - 第四步,业务实体有哪些操作(或者可对实体进行的操作) 53 | - 实体有图书(编号,图书状态,书名etc),图书卡(图书卡号,学生编号),图书库存(编号,库存量),借还流水。 54 | 入库是跟库存在一个上下文,借书和还书跟图书,借还流水在一个上下文。 55 | - 不是太明白,为什么有副本的概念,书每一本都是唯一的,那也有唯一的编码,那不能就副本,我是这样理解的,同一本内容的是,可能就是相对有一个库存而已。 56 | - 不用图书副本(或者其他名词)的概念,只用库存的概念来管理应该不行的,我们需要追踪每一本书的状态,是什么时候入馆的,目前的状态,所有借还书的记录等等。 57 | 58 | ###### 理论讨论 59 | - BC通常和子域对应的,所以可以先划分子域,然后默认每个子域一个BC,每个BC中的领域概念没有歧义有明确含义 60 | - 甚至没有BC这个概念也可以,最重要的是要以业务为重,划分业务边界,这个过程就是在划分子域。业务边界明确了,那每个业务边界内进行领域建模即可 61 | - 很多时候根本子域都不用划分,因为领域问题不复杂,业务范围不大,比如我上面的图书馆案例,此时就可以直接建模了 62 | - 如果要做一个淘宝天猫这样的电商平台,那战略思想能力才是关键了,也就是从高到低的业务梳理划分以及架构设计 63 | - 一个聚合至少有一个聚合根,至多也有一个聚合根来保证一致性 64 | - 聚合保证原子性是原则,事务是手段,不能反过来依据事务来找聚合啊。 65 | - 传统ddd是一个bc的业务用例处于同一个事务中,而这个业务用例本身可能跨聚合。 66 | - 聚合是依据业务不变性划分的 67 | - 如果依据面相过程的旧项目中的事务来找聚合,也不过是另一种方式的面向过程而已。 68 | - 聚合是依据业务不变性划分的,能结合图书馆的例子说明一下吗?我觉得说的对,可是不知道怎么下手。 69 | - 方法: 70 | - 1、找出你关心的所有领域概念; 71 | - 2、先假设所有概念都是实体,且都是聚合根; 72 | - 3、利用排除法,分析哪些概念没有独立的生命周期,则排除; 73 | - 4、把排除的概念放入其他的聚合根下形成聚合 74 | - 你可能会问如果不会分析生命周期咋办?那就这样思考,是否有场景会直接创建或修改该概念,而不是先导航到其他概念再去修改这个概念,如果有,那就是独立聚合根。 75 | - 有些概念没有出现在需求或用户故事里,而是需要自己去提炼抽象的,其实这个才是难点 76 | - 图书管理员更新每本书的数量(如果同一本书借多本的话)。这个,借书时更新图书数量应该是管理员的职责。 77 | - 学生还书,把图书卡与书给管理员,刷卡,扫条码,确认归还图书+数量,这时候图书还在管理员手里,不需要上架流程,对于还书的人来说还完书就可以走了,然后管理员把书放进篮子里,后面慢慢批量放入书架 78 | - 我有一个疑问。借还记录,它能不能算一个聚合根。 79 | - 我在思考的时候脑子闪着,图书是个聚合根,图书卡也是个聚合根,那介于它俩之间产生的记录。借还记录 80 | - 不能,借书和还书都会产生借还记录,业务的不变性条件 81 | 82 | ###### 业务概念 83 | 84 | - 一本书:表示一本书,更多的强调一个“商品”,我们可以跟踪书的库存 85 | - 一件书:表示一本书的某一件,一件书表示可以拿在手上的实实在在的“一本物理书” 86 | 87 | ###### 精华 88 | 89 | - 聚合是依据业务不变性划分的。 90 | - 找聚合的方法: 91 | - 1、找出你关心的所有领域概念; 92 | - 2、先假设所有概念都是实体,且都是聚合根; 93 | - 3、利用排除法,分析哪些概念没有独立的生命周期,则排除; 94 | - 4、把排除的概念放入其他的聚合根下形成聚合 95 | - 分析生命周期方法: 96 | - 是否有场景会直接创建或修改该概念,而不是先导航到其他概念再去修改这个概念,如果有,那就是独立聚合根。 --------------------------------------------------------------------------------