DDD 微服务落地实战
date: 2023-09-06
随着软件需求对同一个功能的修改越来越复杂，程序员总是辞藻堆砌一般，加入 if/else;
我们应该使用开闭原则，对扩展开放，对修改关闭；
实践方式：两顶帽子
在不添加新功能的前提下，重构代码，调整原有程序结构，以适应新功能；
实现新的功能。
DDD领域模型是为了保证程序设计与现实更加贴近，现实领域中有那些对象，哪些行为，程序中便有哪些服务，哪些操作。 一致性提高了软件的稳定性。
单一原则应用：DDD中，需要思考两个对象是否相互影响，如果不是的话，应该分为两个单独的对象来管理，如果是的话就需要放在一起。
软件的质量评判：增加功能时，需要改动的范围以及测试的工作量， 越少质量越高
DDD在数据库中的实践就是，结合实际使用情况 + 领域对象设计 => DB 表结构
充血模型和贫血模型的优劣： 前者在实体内部就定义了相应的方法，后者在实体对应的service里面创建方法。 （优劣需要基于实践来看）
DDD 聚合: 一个领域的所有对象，没有订单就没有订单明细； 工厂：查询多个DAO获取一个聚合对象返回； 仓库：比普通DAO多一个缓存层，可以从缓存中取，没有再从工厂拿。
DDD限界上下文来设计微服务：为每个微服务(领域)设置它的职责范围，清晰职责后再去设计行为，每个微服务维护自己的数据库，其他服务需要数据则通过调用微服务API来获取。
DDD 事件风暴： 为了让领域专家和开发人员有共识，避免由于理解误差而导致的开发失误；在二者讨论需求时，需要划分事件，领域实体，从而让开发理解领域知识，领域专家理解开发模型。
DDD实践：事件风暴[领域模型] -> 限界领域实体上下文[实体行为] -> 事件场景设置[实体交互：RESTful/mq/rpc/callback]: 领域事件消息
整洁架构： 常见的就是业务和框架耦合，导致需要更新或者更换框架时，需要做出重大改动。
可以考虑使用一个适配器模式去优化，适配器提供基础能力，实现类耦合框架能力，更新框架只需要更新实现类。
快速交付： DDD+中台架构，将所有共性提取倒中台服务，将个性拆分，实现快交付。
DDD中台架构设计： 单controller+单service+单DAO => 通过http url反射 获取entity，service，method，执行统一的查询操作。 [优点：适配框架不明确情况，对于新的接口，只需要添加对应的dao层模型就好]
http://localhost/entity/method?params=xxx => controller 反射获取 entityService， entityService.method(Map<> params) => DAO mapper定制，获得输出转成JSON返回前端
对于一个对象的聚合，可能需要查询多个表、服务才能组成，则可以在对 dao 层的映射中做改动，自定义mapper结构中新增标签来适配这种模式。
贴近事实的软件开发才是低风险的软件开发，而不是一味根据需求改动 技术服务于业务，所以要想着有什么新技术可以更好服务业务，而不是一直用已知技术炒冷饭。 DDD虽然在系统设计时候有作用，但是在代码结构上仍然有问题，比如为每个实体都要写controller，service、repository，从而有大量的类，作者简化了这一点，使用了反射的方法消除了这种重复。
Last updated