.net中ddd设计模式之domainServices与redis构建redisServices的讨论

今天下午和部门马爷讨论了一下.net中ddd设计模式之domainServices与redis构建redisServices，起因是我们在构建OrderCode订单编码的唯一性，由于模仿微信支付中的随机数构建在高并发是会出现重复的现象，所以引入redis的计数器系统（参见小Z的redis自增序列）。其中我和马爷讨论的问题是在ddd的domainservices中并不能完全完成订单创建的功能，ordercode在项目的基础设施中的redisServices中完成。那么问题来了，redisServices中就必须通过继承重写domainServices的方法去完成订单创建的功能。如此，基础设施必须引用domainServices，马爷的想法是domainServices不该引用基础设施，领域服务该独立。这点小Z是赞同的，只是这样我们就要比较别扭的在基础设施中引用领域服务，虽然觉得有些变扭，因为基础设施本来就是单给webAPI引用的，小Z的想法是能不能移入领域服务。马爷的想法是理论上可以，实际操作上也有问题，即redisServices其实没有业务功能，并且会产生大量的schema定义，而且在细节上不怎么好抽象成接口，所以目前的做法还是维持现状。

当然最后我们的观点是redis已经是我们架构中不可获取的一部分，至少目前是这样的，以后是不是换成其他的nosql或者组件是另说，因为redis毕竟解决了一部分sqlserver或者说是关系型数据库的性能瓶颈，和一些不必要的数据不进行持久化的设计。

不知道各位在实际应用中遇没遇到相似的问题？我们可以探讨探讨。