1)ddd：
软件复杂性的应对之道。
但是不是说：redis这种不会使用。
开发过程中，一直面临的一种复杂性。
是一种架构思想: 领域之间的组合。 让开发软件具有搭积木的感觉。
领域的核心是边界。
以领域划分为基础。
以通用语言为建设核心:
如: 在一个项目中每个模块具有相同的包结构。
2)mvc的做法：
UserController: 负责用户的注册等。
OrderController: 创建订单也需要用户信息。
导致：这2个Controller都引入了UserService。
3)业务优先: 一个一个模块，一个模块一个文件夹。 // 不看细节，也能看懂大概是干什么的。
4)技术优先: 根本看不懂实体是干什么的。
5)三大设计原则：
1.单一职责：一个类只负责单一的职责，也就是只有一个引起变化的原因。
2.开放封闭：对扩展开放，对修改关闭。
3，依赖反转：值依赖抽象接口，而不依赖于具体实现。
6)DDD模型妙招：
1.使用充血模型的实体对象，描述核心业务能力。--》对数据库下手。
系统能做什么事情，一目了然。
2.使用仓库与工厂，封装实体持久化操作，拜托数据库限制。
7)Martin Flowler:
贫血模型: pojo ==> 问题: 贫血失忆症，本来定义实体是为了承载业务，我们只能在Service中翻，我们现在不知道用于做什么业务了。
充血模型: 解决之道：属性 + 引起属性变化的方法写在一起。
8)DDD改造mvc后: // 其实就是: 在3个设计原则下。
只有业务逻辑，没有任何实现细节。
因为面向接口编程了，所有的参数其实都是Entity实体，你也看不出来到底是: mysql还是mongo。
更加容易做单元测试。 如: 针对AccountReponsitory即可，从Dao换成mapper。 对其他业务没有任何影响。
领域层不需要任何的依赖。
9)DDD缺点: 带来了类爆炸。
10)聚合：
将确保这些领域对象在实现共同的业务逻辑时，能保证数据的一致性。
一个不存在了，其它也不存在了。
通过聚合根。
11)通过接口去做各种类似的东西。
如: 微服务、feign、dubbo。
不是从本地找实现，而是从nacos之类的，从本地查找实现转化为从rpc找实现。
12)MVC: 技术边界清晰，但是业务逻辑边界模糊，很难拆分为: 微服务。
DDD: 优先设计业务实体，形成业务领域。 通过防腐层和限界上下文实现逻辑边界。 从而很容易调整，如：从本地接口发现改为从rpc发现，
那么就很容易改为支持微服务的架构。
13)一个注解，从单体架构变为微服务架构。
14)MVC做好后的问题(看起来简单,但是...):
1.功能扩展性带来负载的重构: 从普通的认证改为 OAuth2鉴权需要重构。
2.负载问题: GenSIController非常繁忙，SysManageController却很空闲。
微服务的缺点: 需要部署很多周边服务，非常昂贵，很可能项目上线后不就就撤掉了。
因此，我们开始希望是单体。 然后根据发展拆分为微服务。
15)重构对于甲方是没有任何业务价值的。
16)软件核心复杂性的问题: // 也就是DDD出现的原因
项目迭代过程中，发展出了超出设计之外的问题，这些问题重构又很困难。
比如: 淘宝开始是php做的，它根本不知道以后还要支持"双11" "秒杀"。
17)DDD的核心:
1.技术主动理解业务: 我当前的业务需要哪些对象来参与，这些对象构成什么样的业务流程。
2.打破自己的包结构，向业务调整。
3."刚刚好"解决问题: DDD强调的是每一步的实现支持当前的业务就行了。
18)Demo架构：
Client // 向Server发起Http请求。
Interface // 是Dubbo接口定义
Resource
Server // 向Resource之间是Dubbo协议交互。 Server做流量的管理。
Nacos // Server向Nacos注册消费者接口，Resource向Nacos注册生产者接口。
19)初步领域划分:
HisRequest // 负责交易日志管理服务
GsService // 负责核心的请求转发业务
SysManage // 负责客户端管理业务
20)1个注解从单体到微服务
SPI: ServiceLoader 去加载本地服务的实现。
否则使用Nacos去从远程加载实现。
21)单体架构到微服务: 让资源的投入更加的精准。
22)DDD中领域暴露出来的，其实还是接口。
23)单体架构快速验证，微服务部署。
24)DDD: 只是一种思想，没有一个类似的框架。
