DDD之领域间动态分頁联查

好记忆不如烂笔头,能记下点东西,就记下点,有时间拿出来看看,也会发觉不一样的感受。

目录

一、讲点题内话

二、书回正文

       1.情况一

        2.情况二

       2.1 备选方案一

       2.2 备选方案二

       2.3 备选方案三

        2.4 备选方案四

        2.5 综上所述


一、讲点题内话

       众所周知,DDD是一种解决问题的思路。重点是给出理论,按照理论进行需求分析、业务拆解和架构设计。她是一种解决方案的抽象概括。

       现状却是:没有一种完整的,可照本宣科的流程,让人可以根据这套流程去进行业务的分析,拆解,联合,这应该是DDD没有真正火起来的原因。很多人都知道DDD,也都明白是怎么回事,但是就是不能在实际的业务中去践行实施,去真正的按照DDD的思想去服务于业务。

       现在市面上,关于DDD的实践,也出现了好几家之言,其中有:孙玄老师,张逸老师,欧创新老师等等,都是DDD的步道师、、、 、、、

二、书回正文

       如何进行DDD之间的动态、关联,关键字、分页查询?

       如果是在传统的单体应用中,其实很好解决,只需要进行多表联查,就可以很好的解决整个问题,但是一旦到了DDD中(微服务中),那么整个就得分情况而视了。

       1.情况一

        涉及分页联查的表,在某个微服务内部。即:不管是按照功能分,还是职责分后的微服务系统中,涉及关联分页查询的数据,都在该微服务内部,那么顺利成章,采用微服务内部之间的多表联查进行关联分页查询。

        2.情况二

         需要关联的表的数据,不在同一个微服务中,即:需要关联查询的表信息,在其他微服务中,也就是:跨库多表检索分页联查。

鉴于这种情况,那么该如何来进行分页关联查询呐?这里提供几种思路,具体采用哪一种,要根据实际的业务情况来定。所谓:兵无常势,水无常形!

       2.1 备选方案一

        内存计算,即:将需要关联的数据,动态放入内存之中(可以是放入到Redis,使用时再从Redis中去获取),通过内存计算,将结果传入到数据库层面再进行关联查询,得到页面需要的结果。

       方案优点 :代价小,需要的操作也比较少。

       方案缺点 :需要同步数据到内存中 ,并且要保证数据变更之后,要变更信息同步到内存,方便计算的后的值在去SQL层面进行检索。

       2.2 备选方案二

        小表数据(附表数据),即:将需要搜索和关联的表的主要信息,在需要的微服务中库中建立小表信息,用来存储可用于检索和分页相关的关键字。例如:微服务B中的某个列表页面,检索的关键字,在微服务A所在的数据库中,那么要实现在微服务B中进行微服务A中关键字的检索分页,可以采用在微服务B所对应的数据库中,将要检索的微服务A中的表的数据,复制主要检索信息,到微服务B中,进而就可以使用关联查询,实现检索分页列表显示了。

       方案优点 :速度快,便于查看和统计。

       方案缺点 :需要同步数据 ,并且要保证数据变更之后,要变更信息同步到小表中。

       2.3 备选方案三

        建立数据中心,将各个微服务系统的数据都汇总到数据中心上来,所有的增、删、改操作,都需要将数据同步到数据中心,保证数据中心的数据和微服务系统对应的数据是一致的。如此一来,再涉及到跨微服务系统之间的关键字分页检索,就不会存在问题。

       方案优点 :可以随心所欲的进行关联查询。

       方案缺点 :需要同步数据到数据中心 ,并且要保证数据变更之后,要变更信息同步,建立数据中心的成本大,投入多。

              

        2.4 备选方案四

       利用ES,提前按照业务所需,构建索引,并在数据变化之后,将变化的信息同步到ES中去,如此一来,在页面列表中的查询,就走ES,只有在详情不满足的情况下,在走数据查询。

       方案优点 :ES可以满足各种维度的检索和分页查询。

       方案缺点 :需要同步数据到ES ,并且要保证数据变更之后,要变更信息同步,需要搭建ES环境,实现上通过API进行关联查询。

        2.5 综上所述

        总体来说:只有备选方案二、是比较符合实际企业情况,而且实现成本上也相对是合理的。其他的另外三种方案,在资源,实现难度,维护性等方面,均没有第二种合适。

         当然如果已经有了数据中心,或者ES集群了,那么就另当别论了。
         

        不管是DDD还是微服务,只要是服务分库了,那么都可能会遇到跨库查询的问题,那么自然也就会有这样的实现方式去应对跨库查询的操作。

        可能还有其他更好的方式,我所尝试过的,就主要是以上四种,其他的,利用大数据技术,应该也可以很好的解决这个问题,但是我没有去尝试!有更好的,欢迎留意讨论!

更多信息可关注,码出精彩 (codingba)公众号,欢迎探讨成长

你可能感兴趣的:(程序人生,Java,Database)