软件设计、DDD概念及落地时的一些零碎思考和记录
程序员文章站
2022-03-10 16:37:19
DDD理解 DDD体现的是对现实的充分尊重。 1.尊重业务现实,领域专家、领域语言等概念 2.尊重团队现实 3.尊重变化 Application 对某一业务线的整体掌控,流程组装,进度管理,存储时机掌控。 依赖外部模块的业务环节实现; 尽量满足UI需求; 落地:uow提交; Domain 业务线视作 ......
ddd理解
ddd体现的是对现实的充分尊重。
1.尊重业务现实,领域专家、领域语言等概念
2.尊重团队现实
3.尊重变化
application
- 对某一业务线的整体掌控,流程组装,进度管理,存储时机掌控。
- 依赖外部模块的业务环节实现;
- 尽量满足ui需求;
- 落地:uow提交;
domain
- 业务线视作水平线的话,此处应在垂直方向上切分各业务线,重新整合抽象,处理具体的业务环节、业务步骤。
- 划分范围、确定职责,需要多维度多视角的考虑抽象;
- 粒度尽量小。
- 本质上是对业务逻辑处理过程的纯化,能用的技术手段实质上是受限的;
- 不要考虑业务逻辑跨项目跨产品的通用性,这是以后的事;
- 缓存和仓储需要注意,有必要的话分开;
- 落地:尽量少的执行 存储,最好没有;
在内存中处理逻辑;
尽量使用private set
;
尽量避免锁与线程操作;
注意时间、时刻及引用的问题;
存储、查询
- 存储的重要性仅次于domain。
- 存储的隔离有两种,一种仅隔离不同的数据库,一种连orm也隔离开;
- 大多数情况下不需要隔离orm,技术选型确定后,使用时不必有过多顾虑;
- 如果使用efcore这种orm,dbset和dbcontext可以进入domain;
- 查询与存储关联非常紧密同时距离用户很近(两个地狱),技术手段可以放宽,存储过程、db函数,lua脚本之类都可以考虑;
- domain可以对查询进行一些适配,或优化(后期);
- 快照时机,快照性能;
- 实时、非实时查询;
- 复杂报表需要自行适配业务数据;
命令、事件、消息。。。
- 总线队列比较容易被接受;
- 事件可以分阶段落地;
- 就算是日志也要养成记录快照的习惯;
标识
- 避免自增id;
- 分布式id,大部分时候可以使用combineguid(唯一、基本有序、随机、提前生成);
- 进行事件快照时可以使用同一id,不同事件类型进行处理。
- 通常会发生变化的对象需要一个标识。
实体与值对象
- 实体属性会产生变化用于描述记录业务生命期内的各种事件,实体本身及引用的实体都会变化,实体间的关系通常使用引用来表达;
- 值对象本身是偏概念的东西,用过函数语言的会比较容易理解,在c#中与之类似的有元组、匿名类和提案里的record;
- 这里最重要的是思想的引入而非手段。
- 值对象本身表达的是部分属性的快照副本,类似于实体拥有的所有属性上的一段切片,是某个时刻下的一小段副本,所以不需要标识也只能是只读的;
- 属于使用者/调用者关注的东西,如果没有人关注它,通常没有必要单纯为表达某个概念而增加,容易造成概念混乱;
- 实体的变化会使逻辑处理产生隐患,尤其是涉及到引用类型时,这时引入值对象的快照副本概念就会很自然,比如使用一些变量取出属性值,或者一个匿名类用于方法内部,或者在方法的参数上仅提供值类型的参数,总之“逻辑算法仅能处理当前时刻的对象状态” 这一层概念必须明确表达。
- 实体的逻辑处理通常会导致实体自身属性的变化,业务上对实体属性的变化通常很敏感,有时不能仅提供一个结果给需求方,这时我们就需要增加一些属性记录下结果产生的原因。
- 值对象不在于我们定义的类型结构,而是要帮助技术人员建立起值的概念,快照副本及当前时刻是关键点,这种概念的建立非常有助于理解业务事件;
------------------------------------------------------------------上面是值对象值的部分,下面是对象部分(结构,属性包); - 有时候我们的逻辑中会有“我不关心是什么类型的实体,我只关心是否符合某种结构(属性包,形状)”,也就是实体在不同视角下的形状,关注点产生了变化。
- 一般在一些横切式的模块或者分析类的模块中有应用。
- 字典、配置类使用实体,更新原状态,插入新记录。
后台
系统后台:监控,分布式管理。。。;
- 管理后台不可直接引用domain自行组装业务流(使用接口);
- 管理后台的需求必须与业务线需求一同交给domain处理;
-
手工操作功能没有小事;
安全权限
贯穿始终;
团队
- 沟通、信任 “敬汝代码而惕之”,