基于领域分析设计的架构规范读写隔离.docxVIP

基于领域分析设计的架构规范-读写隔离 读取操作必需是无害的，临时不考虑大并发把服务器压垮这种极端场景，就一般而言，我们可以说，一个合格的查询接口所达到的效果应当是：?无论你执行多少次查询，系统的数据都是不会发生变化的 所以，对于一个生疏的系统，假如对方给了你【增删改查】四个接口，那么再没有深化了解业务的情况下，你首先进行测试的接口，肯定是查询接口 为了达到一个合格的查询接口，对于系统的开发者的来说，必需保证全部的查询业务接口里，不能有任何对业务实体的修改操作，换句话说，全部的查询操作，只是对系统瞬时的一个快照，不对数据产生修改，自然对整个系统的业务运转也不产生任何变动。 实现策略 我们常说的读写分别，那是在应对功能问题时的一种处理方案。而我们这里特意换成了读写隔离，就是为了区分开两者。而这个隔离，是从更高层面来设计整个架构规范，是在项目设计刚开头的时候就考虑进去的。而且，实现难度小。 即便是基于现有的代码做重构，也只需挪代码块就行了，也没有什么业务风险，这个我们之后会再提到。 那么，很自然的，通过@Transactional(readOnly = true)的把握，可以格外好的达到这个目的，这样，即便有开发人员不当心在其中做了修改操作，也会执行报错，赐予很好的平安提示，这时，我们就需要重新端详这个需求，能否需要将修改操作分别出来。 import org.springframework.stereotype.Service; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.transaction.annotation.Transactional; /** * 以订单为主体的查询业务处理类 */ @Service @Transactional(readOnly = true) public class OrderFinder { @Autowired OrderRepository orderRepository; @Autowired UserRepository userRepository; /** 批量查询订单 */ List queryOrderByIds(List orderIds) /** 运营把握台订单分页查询 */ List pagingOrdersOnConsole(int pageSize,int pageNumber) /** APP端用户订单分页查询 */ List pagingOrdersOnApp(Long userId,int pageSize,int pageNumber) // more methods and fields .. } 有一些问题直得探讨： Finder就等同于将Repository里的查询方法挪过来吗？ 并不是，首先，Finder是一个查询业务的处理类。一个查询业务，意味着从调用端发起恳求到结果前往，本次过程是进行一次完整的查询操作，更直观的来说，像是下面这样 //..在一个入口层中，比如SpringMVC中的@Controller @Autowired private OrderFinder orderFinder; @GetMapping(/paging/) public CustomPagingResponse pagingOrders(int pageSize,int pageNumber){ return orderFinder.paging(pageSize,pageNumber); } 而并非另外一种为了删改某一个实体而通过主键或其他特定查询SQL来做出的查询操作，这种操作，将会在一个命令业务中直接通过Repository去做，比如 //..假定是在订单删除业务OrderDeleteService中的一部分 public void deleteOrder(Long orderId){ //依据条件定位到需要进行操作的Entity，这个过程，是命令操作的一部分，所以，它不是一个完整的查询业务，这个时候，不会用到Finder Order order = orderRepository.getById(orderId); //...接下来对order进行操作，省略 } 而且，往往在一个较为简单的查询业务中