好记忆不如烂笔头，能记下点东西，就记下点，有时间拿出来看看，也会发觉不一样的感受。
目录
一、讲点题内话
众所周知，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）公众号，欢迎探讨成长
1329
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
