DDD领域驱动设计实战
DDD1-课程介绍
互联网大厂的蔚来架构之道
DDD领域驱动设计 实战
阿里ddd: cola
DDD天生就适合微服务的这种方式
阿里中台的概念
很多企业发现在践行中台的战略中遇到很多问题
提升软件质量
起步
DDD是一个庞大的理论体系,如何落地是一个问题,而不像微服务体系或者MVC架构有这么多框架
很多大厂是用这种小型的项目用DDD来进行推广
DDD要求于具体的技术无关的
目录
技术学起来很快,想要与众不同,就需要你的软实力,这种软实力的提升就是比较虚的
DDD适合贯穿于你的整个体系
- P22.
DDD2-什么是DDD
17:40
啥时DDD
NoSql: redis mongodb hbase
nosql概念是这个作者提出来的
软件设计的复杂性,要复杂才能适合ddd
不如在进行权限控制的时候,我们就会简历RBAC
,通过角色来简历权限控制,就是一种ddd
实现领域驱动设计
DDD3-系统老化谁的锅
11:28
什么是系统老化
迭代时间很长的项目
比如一个项目迭代了10多年
系统老化
人员变更,
新的人员如何去理解业务需求
文档一般还是跟不上的
重构否??? 重构了没有实质性的提升,成本却很高
微服务架构能防止系统变老么
随着微服务的发展
还是会出现没有这种实质性的该变
局部业务出现膨胀 还是需要重构, 还是需要拆分
微服务架构会一定程度上的解决,但是还是不会根本解决,只会让你的老化速度变慢一点儿
DDD理论体系
DDD4-转账功能改造上
21:03
写出一个小demo
于浩代码的差距到底在哪
这样的代码实际上是面相过程的方式
也被称之为事务脚本
先不考虑他的执行效果
写高质量的代码: 高内聚 低耦合
需要可行的标准:
单一职责原则:(一个模块只做一个业务)
开放封闭原则:对扩展开放,对修改封闭
依赖翻转原则: 面相接口依赖,而不是依赖具体的实现类
抽象数据存储层
把业务方法写到 实体里面
DDD里面提到的充血模型
与之对应的 称为 贫血模型>>> POJO Martin Fowler 提出来的(就是只有属性和get set 方法的实体类)
我们这个实体本来是为了承载业务来设计的,但是
最后变成从这个实体根本看不出有哪些业务了,这种称为贫血失忆症
如和解决: 充血模型
可以在定义一个实体,来实现,比如修改密码,修改xxx的业务,这个实体只做他的事情: 转入转出操作
定义的时候就比较别扭了
到底什么方法要加入实体类中
DDD中对这个Business是有说道的
业务是对于实体改变的
而这种转账是不会改变实体的
Order -> OrderItem -> Address
整体于部分的关系,
把仓库定义成巨大无比的对象池
理想: 所有对象都在内存对象池里
如果有大对象,就需要工厂来 帮助改造
DDD5-转账功能改造下
24:52
抽象第三方服务
你的第三方服务怎么实现的和我的业务没有关系
DDD中的防腐层ACL: 隔离第三方的依赖
抽象第三方组件
DDD4层架构
DDD的一大特点,当你的业务绝对简单的时候,
在小型的业务下,往往体现不出优势
DDD6-DDD项目改造
16:53
DDD7-DDD项目改造
25:22
“DDD”Vs DDD项目改造
DDD8-DDD项目改造下
11:02
“DDD”,data driven design
DDD9-DDD视角下的单体架构与微服务架构
13:46
微服务时代,单体架构淘汰了吗
DDD视角下单体架构与微服务架构的统一
DDD10-DDD发展展望
17:46
中台,DDD的另一片战场
战略工具,DDD提供 的方法 形成一个统一的语言
平台+资源调度>->- 中台
from
https://www.bilibili.com/video/BV1Y341167Xp?from=search&seid=8938952084618205028
2小时掌握宇宙最强DDD（Data Display Debugger）DDD领域驱动设计实战
