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

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: 只是一种思想，没有一个类似的框架。