├── 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 | - 是否有场景会直接创建或修改该概念，而不是先导航到其他概念再去修改这个概念，如果有，那就是独立聚合根。 --------------------------------------------------------------------------------