DDD学习笔记

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" "秒杀"。