其他
最全的【DDD领域建模】小白学习手册（文末附资料）
导读
DDD领域建模被各个大小厂商提起并应用，而每个人都有自己的理解，本文就是针对小白，系统地讲解DDD到底是什么，解决了什么问题，及一些建议和实践。本文主要是思想的一种碰撞和分享，希望能对朋友们有所启发或帮助。
导读
DDD领域建模被各个大小厂商提起并应用，而每个人都有自己的理解，本文就是针对小白，系统地讲解DDD到底是什么，解决了什么问题，及一些建议和实践。本文主要是思想的一种碰撞和分享，希望能对朋友们有所启发或帮助。01 前言
在今年的敏捷团队建设中，我通过Suite执行器实现了一键自动化单元测试。Juint除了Suite执行器还有哪些执行器呢？由此我的Runner探索之旅开始了！
在当时的环境下，单体应用仍然是市场的主体，但是大型复杂软件系统已经出现，给团队的设计和开发工作带来了比较大的挑战。
DDD提供了一种新的设计思路，通过对于业务子域和限界上下文的划分，建立跨越业务和技术的统一语言，为业务建模的同时，拉通业务和技术实现。
DDD理论的提出，对整个软件架构设计领域，尤其是对微服务架构的设计产生了巨大的影响。那如何运用DDD来解决所面临的大型业务系统问题呢？
在这里以中台业务为例，进行实践和应用。
友情提示：看目录，从整体中深入内部去看02
现状
理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。
2.1 软件设计所面临的挑战
软件开发的不确定性贯穿了整个软件工程的生命周期。 软件工程中不可能有任何“银弹”解决软件的复杂度问题。 软件工程核心实质是社会工程，优秀团队的竞争力来源于互相的信任及良好的沟通。
2.2 软件工程的复杂度
2.3 和传统架构设计相比DDD解决的问题
1.业务架构如何合理的设计？
2.4 领域驱动设计的核心思想
1、模型与现实业务的统一
模型和程序设计的核心相互影响。正是模型与实现之间的紧密联系才使模型变得有用， 并确保我们在模型中所进行的分析能够转化为最终程序。 模型与实现之间的这种紧密结合在维护和后续开发期间也会很有用，因为我们可以基于对模型的理解来解释代码。
2、统一（业务和技术）语言
模型是团队所有成员使用的通用语言的中枢。由于模型与实现之间的关联，开发人员可 以用该语言来讨论程序。 他们可以在无需翻译的情况下与领域专家进行沟通。而且由于该语言是基于模型的，因此我们可借助自然语言对模型本身进行精化。
3、团队的持续学习，消化知识，系统持续的发展
4、领域驱动设计三原则
P1: Focus on your core domain.
P2: Iteratively explore models in a creative collaboration of domain practitioners and software practitioners.
P3: Speak a Ubiquitous Language within an explicitly Bounded Context.
2.5 领域驱动的设计步骤
5.1 统一语言
简单理解起来的话，也就是把业务人员和开发人员的语言统一起来，用代码来感受一下大概就是：
userService.love(Jack, Rose) => Jack.love(Rose)companyService.hire(company,employee) => Company.hire(employee)5.2 领域内的事件风暴、命令风暴
5.2.1 什么是领域事件？
要点：
5.2.2 如何进行命令风暴？
5.2.3 寻找聚合
什么是聚合
‣ 聚合边界内保证业务不变性(invariant)
‣ 只能通过聚合根修改边界内的对象
2.6 DDD领域设计的服务划分
6.1 修缮模式（遗留系统重构）
6.2绞杀模式（遗留系统重构）
6.3 服务划分原则
依据业务限界上下文边界划分
在实操过程中，不同组织也在应用以下服务划分原则
2.7 DDD全景图
1、战略设计
2、战术设计
3、全景视图操作流程
2.8 领域模型
1、模型分类及特征
失血模型：模型仅仅包含数据的定义和getter/setter方法，业务逻辑和应用逻辑都放到服务层中。这种类在Java中叫POJO，在.NET中叫POCO。 贫血模型：贫血模型中包含了一些业务逻辑，但不包含依赖持久层的业务逻辑。这部分依赖于持久层的业务逻辑将会放到服务层中。可以看出，贫血模型中的领域对象是不依赖于持久层的。 充血模型：充血模型中包含了所有的业务逻辑，包括依赖于持久层的业务逻辑。所以，使用充血模型的领域层是依赖于持久层，简单表示就是 UI层->服务层->领域层↔持久层。 胀血模型：胀血模型就是把和业务逻辑不想关的其他应用逻辑（如授权、事务等）都放到领域模型中。感觉胀血模型反而是另外一种的失血模型，因为服务层消失了，领域层干了服务层的事，到头来还是什么都没变。
2、对4种模型的理解
在基于贫血模型的传统开发模式中，Service 层包含 Service 类和 BO 类两部分，BO 是贫血模型，只包含数据，不包含具体的业务逻辑。业务逻辑集中在 Service 类中。在基于充血模型的 DDD 开发模式中，Service 层包含 Service 类和 Domain 类两部分。Domain 就相当于贫血模型中的 BO。不过，Domain 与 BO 的区别在于它是基于充血模型开发的，既包含数据，也包含业务逻辑。而 Service 类变得非常单薄。
贫血模型优缺点：
充血模型优缺点：
胀血模型优缺点：
评价：
3、为什么基于贫血模型的传统开发模式如此受欢迎？
4、 DDD 完全的充血或者胀血模型得与失
2.9 领域驱动在中台业务分析中的实践
1、业务中台DDD领域 应用架构规范
2、业务中台使用DDD领域建模的愿景（架构分层）
3、现有系统使用DDD进行领域分析
更不要死板的去套DDD的各种充血贫血模型，找到适合自己的模型，解决建模问题才是最重要的。DDD只是为你提供了一套系统的方法论仅此而已，并没有多高大上。
03
推荐教程与文档
理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。
DDD CQRS和Event Sourcing的案例：足球比赛
集装箱车队系统的DDD案例
04 总结
理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目
参考博客文献：（吃水不忘挖井人）
浅谈 MVC、MVP 和 MVVM 架构模式：https://draveness.me/mvx
上善若水的博客：http://deshui.wang/
CRUD工程师晋级之路：https://zhuanlan.zhihu.com/p/25442175 对象和数据库的天然阻抗：https://www.jdon.com/mda/oo-reltaion2.html Commands & Events instead of CRUD — Part 1: Commands：https://hackernoon.com/commands-events-instead-of-crud-part-1-commands-17f4c7aee33b 汤雪华的博客：https://www.cnblogs.com/netfocus/ There is No U in CRUD：http://jlhood.com/there-is-no-u-in-crud/ Event sourcing vs CRUD：https://community.risingstack.com/event-sourcing-vs-crud/ 阿里盒马领域驱动设计实践：https://www.infoq.cn/article/alibaba-freshhema-ddd-practice DDD战略篇：架构设计的响应力：https://zhuanlan.zhihu.com/p/30878497 使用DDD来构建你的REST API，而不是CRUD：http://blog.didispace.com/use-ddd-design-rest-api/ DDD & co., part 1: What's wrong with CRUD：https://www.thenativeweb.io/blog/2017-10-25-09-46-ddd-and-co-part-1-whats-wrong-with-crud/ DDD的终极大招——By Experience：https://insights.thoughtworks.cn/ddd-by-experience/ 领域驱动设计概览：http://zhangyi.xyz/overview-of-ddd/ Refactoring from anemic model to DDD：https://blog.pragmatists.com/refactoring-from-anemic-model-to-ddd-880d3dd3d45f 为什么DDD是设计微服务的最佳实践：https://www.jianshu.com/p/e1b32a5ee91c 领域驱动设计在互联网业务开发中的实践：https://kb.cnblogs.com/page/586236/ 领域驱动设计(DDD:Domain-Driven Design)：https://www.jdon.com/ddd.html 领域驱动设计之我见：https://www.jdon.com/39844.html 领域驱动设计之实践与反思：https://www.jdon.com/45286.html #DDD案例：https://www.jdon.com/tags/19145 #DDD有界上下文：https://www.jdon.com/tags/15977 #DDD聚合：https://www.jdon.com/tags/8976 #DDD实体：https://www.jdon.com/tags/307 #DDD值对象：https://www.jdon.com/tags/309 #DDD服务：https://www.jdon.com/tags/677 #DDD仓储模式：https://www.jdon.com/tags/238 #DDD Specification规格模式：https://www.jdon.com/tags/766 #领域事件：https://www.jdon.com/event.html #EventStorming：https://www.jdon.com/eventstorming.html #CQRS架构：https://www.jdon.com/cqrs.html
限速神器RateLimiter源码解析
AI降临，前端启用面壁计划
求分享
求点赞
求在看