DDD领域驱动设计

视频路径https://www.bilibili.com/video/BV18q4y1P7AE?p=2&spm_id_from=pageDriver

问题：
1）沟通难
2）开发难
3）测试难
4）创新难

三次软件危机

问题：防止项目老化？（大泥球模型）
技术和业务的脱节

以前是将业务分成一个个微服务。
ddd将一个个业务分成domain。

如何分割领域？

举例子：

代码老化核心问题是控制代码膨胀

方法：
1）在service和mapper中间加入Repositoty层（仓库）
2）在业务实体中加入业务方法（转账实体中加入转入方法和转出方法）
充血模型和贫血模型
贫血模型导致贫血失忆症
实体和值对象-例子订单表和物品表-订单id和物品id冗余。
问题：什么是业务
ddd业务指造成实体状态变化

最后的设计模型

对比以前的架构和ddd架构的设计过程

项目结构

设计过程：

业务与软件的关系？（大泥球）
业务向软件靠近 微软erp（不仅买了软件管理架构也更规范了）
软件向业务靠拢 ddd模式

ddd与技术无关与架构无关

与现在架构妥协后解决方案