领域驱动设计实践团队级别实现

Posted 2023-03-27 饭小胖

前言

本文基于报销单模型进行团队级别是ddd设计

报销单需求、背景

草稿状态

提交状态

退回场景

会议一：统一建模语言

统一语言：

• 头脑风暴，获取知识，画概念图，画用例图，找深层模型；
• 我们可能需要一种模型，专家和我们都能看懂的，而且讨论问题就以模型为沟通语言的核心。我们需要保持2点：
• 绑定这个核心模型和实现；
• 维持这个模型的发展和用作软件开发的沟通
• 简单形式的通用语言可以是一些术语和用例场景

我经常遇到下面这些问题：
1、很多时候急着上线，可能要屈服一下，先以最快速度干上去；
2、应对一些不合理的要求，上下游不愿意做，抛给我们的；
3、应对一些过度性需求，我们做这件事只是为了用一段时间，等其他域统一了，我们就不需要了；

 为什么是团队的语言？

• 因为影响设计的，不是单个人，是很多因素的决定；
• 因为团队需要沟通一致、团结的基础；
• 语言的更改，意味着模型的更改；

避免：对领域的关键理解，稍纵即逝

把通用语言反映在代码中

如何把通用语言反映在代码中呢？我们对用例和领域服务的设计要特别的考虑。

• 提交是领域服务：我们的大聚合是怎样的，什么事情都调用聚合去做，看起来是封装，实则是无法读懂，隐藏了不该隐藏的东西，所以报销单就不能包含异常和提交这些动作，而是把提交做成一个领域服务
• 通用语言保持在文档中是非常困难的，所以是要保持在代码中，而一些用例场景的通用语言，就应该在领域服务中

会议二：如何设计聚合

如何设计聚合

1、聚合的边界是最重要的

衡量聚合边界的是稳定性：到底要不要把异常纳入报销单呢？

注意边界的稳定性，边界应该不容易被破坏

边界内应该具有稳定的一致性约束

注意实体和现实的结合，报销单实体，是一张单据，电子是报销过程，是否和单据相关？

 讨论

我有点想法，上次说的报销单，规则这一块我感觉还是比较怪的，不过得你们写代码认真思考的时候才能发现哪里怪，我有几个方向：
1、我们有认知错误，例如：异常是不是属于报销单的状态？
2、我们是不是没消化好知识点？内容不足以让我们消化？例如会不会存在一个：报销单校验视图 这样一个隐藏概念？
3、需求本来比较不合理，例如配置变来变去，不合理的时候，是不是应该更多把逻辑放到领域层去，而不需要沉淀模型那么快。

我觉得应该有几个原则，你可以参考一下：
1、想不出的时候先在最外层怼上去，不需要想太多；
2、保持代码的独立性，耦合不要太大，方便重构为第一原则；
3、日后的需求来了，结合以前的需求一起思考；

会议三：深入讨论

前言：不要在一个上下文对一个聚合做两次建模

聚合是什么？边界是否稳定

• 聚合是建模一致性边界，而不是对象树
• 在一致性边界之内，建模真正的不变条件
• 聚合包含了一致性边界和事务，所以异常要存储在报销单中
• 申请单是否存在？
• 报销单是否包含异常？

如何把通用语言体现在代码中？

• 提交是否有步骤？
• 提交是不是报销单的行为？
• 我们经验要重刷异常和费用，表明这个领域有一个惰性的加载机制，因此我们需要隔离惰性机制
• 惰性机制，其实就是在边界之外实用最终一致性
• 把领域服务接口或者实现放在和实体同一个模块中

 

-------------------------------- 优秀、是一种习惯 、、、、、、、、、、、、、、、