欢迎光临汤雪华的博客

一个人一辈子能坚持做好一件事情就够了!坚持是一种刻意的练习,不断寻找缺点突破缺点的过程,而不是重复做某件事情。
随笔 - 138, 文章 - 0, 评论 - 2130, 阅读 - 151万
  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

DDD领域驱动设计 - 设计文档模板

Posted on   netfocus  阅读(9414)  评论(2编辑  收藏  举报

设计文档模板:

  1. 系统背景和定位
  2. 业务需求描述
  3. 领域语言整理,主要是整理领域中的各种术语的定义,名词解释
  4. 领域划分(分析出子域、核心域、支撑域)
  5. 系统用例图
  6. 每个子域的领域模型设计(实体、值对象、聚合、领域事件,需要注意的是:领域模型是需要抽象的,要分析业务本质,而不是简单的直接对需求进行建模)
  7. 领域模型详细说明(如为什么这样设计的原因、模型内对象的关系、各种业务规则、数据一致性规则等)
  8. 领域服务、仓储、工厂设计
  9. Saga业务流程设计
  10. 关键聚合根的状态流转图
  11. 场景走查(讲述如何通过领域模型、领域服务、仓储、Saga流程等完成系统用例以及关键业务流程的)
  12. 架构设计(如传统三层架构、经典四层架构、CQRS/ES架构)

一些其他的思考:

  • 去除一切花俏的建模技巧,我觉得最重要的方向就是去努力分析问题和事物的本质,针对这个本质进行领域建模。这个领域建模,最主要的还是锻炼的人的事物抽象能力。10个人,建出来的领域模型都不同。本质原因就是大家对同一个问题的理解不同,对事物的本质的理解不同。虽然最终都能解决当前的问题,但是对适应未来需求变化的能力却是不同。
  • 所以,我们要把时间花在多理解业务上,让自己成为领域专家,只有这样,才能充分理解业务。多理解一点业务,你才能更好的抽象出业务本质背后的领域模型。很少有人能做到很快理解业务,并很快针对业务设计出正确的领域模型,至少我是不行。
  • 领域建模需要时间,是一个迭代的过程,人无完人。而时间很多时候也不会很充足,所以,不太可能一步到位把领域设计做的很完美。我们在整体项目规划的时候可能会有个大的架构设计、业务大图(边界思维),但是不可能达到领域设计的粒度,只能是一期一期的完善,到最后可能才会有完整的上面的目录内容。每一期都需要考虑支持的场景约束、上下文、系统边界、持续集成的相关设计。设计product, not project。
编辑推荐:
· AI与.NET技术实操系列(二):开始使用ML.NET
· 记一次.NET内存居高不下排查解决与启示
· 探究高空视频全景AR技术的实现原理
· 理解Rust引用及其生命周期标识(上)
· 浏览器原生「磁吸」效果!Anchor Positioning 锚点定位神器解析
阅读排行:
· 全程不用写代码,我用AI程序员写了一个飞机大战
· DeepSeek 开源周回顾「GitHub 热点速览」
· 记一次.NET内存居高不下排查解决与启示
· MongoDB 8.0这个新功能碉堡了,比商业数据库还牛
· .NET10 - 预览版1新功能体验(一)
点击右上角即可分享
微信分享提示