demo小王子

注册中心迁移双注册双订阅中心注册中心迁移Eureka到Nacos1. 初始阶段：Eureka单注册中心环境2.双注册中心阶段3.最终状态 双注册双订阅中心 注册中心迁移 Eureka到Nacos 场景：业务升级，需要将注册中心从eureka转到Nacos。nacos功能更强大，响应更快！ 要求：需要在不影响业务的情况下完成注册中心的转换。即不影响代码调用的情况下完成注册中心的替换！！！！ 是不是听着都很高大上！！！ 先用文字描述一下整个过程然后开始实操！！ 初始阶段。eureka作为注册中心，

领域驱动设计的代码落地实现 MVC层中判空转到BUS层，DAO层的sql语句不放在class文件中，放在配置文件中像MyBatis那样，就可以将技术架构和业务进行解耦 整洁结构设计思想 《架构整洁之道》 写过《代码整洁之道》 核心为适配器层来完成业务和技术的解耦 两个团队可以互不影响进行工作。 ...

领域模型的设计实现过程 领域建模后会落实到数据库设计以及代码的落实，这两者就是落实为代码的两种模型。 贫血模型VS充血模型 贫血模型 充血模型 通过单独查询的订单信息中用户、订单明细的id二次查询对数据进行补填setXXX，即实体类对象中添加对应的属性关系。（一对一、一对多） 这样进行设计返回到前端的信息会让交互减少。 聚合 两个对象之间存在部分和整体的关系，在操作时候通过整体操作部分。如查询订单时需要查询多个订单明细。 通过工厂/仓库来实现。 工厂/仓库 解决聚合关系的操作。 完成数据的装配。 缓存

DDD领域驱动设计 传统运维实质上是补补丁，会使系统越来越复杂，性能下降，耦合高。 DDD则是从整体结构上解决业务变更带来的问题。详见对象划分原则 待解决问题 Day1.DDD的作用和意义 使用要求： 系统变得越复杂时适合使用 当程序简单时反而不适合。 作用域：作用和意义 最初的项目：为了日后维护变更时的方便 不断维护的项目：方便完成业务升级 未来的项目：业务越来越复杂、技术更新速度快、系统变得庞大、市场激烈竞争。 架构演变。 此时业务和框架耦合在了一起。采用整洁架构，有一个中间接口层进行两者解耦。使其