Pagination/Sorting/Searching on a view with data from multiple services

1,031 views
Skip to first unread message

dharmjit singh

unread,
Jan 15, 2020, 12:20:58 AM1/15/20
to DDD/CQRS
Hi All,

I am still exploring DDD and associated patterns ES/CQRS. Please ignore if I ask something very silly. I have few questions around micro services

1) Best approach to show aggregated data from multiple services in one of the UI view. CQRS/aggregation service etc.
2) Pagination/Searching and Sorting in that view based on different fields of different microservices.

Currently I am on only DDD stage and not thinking of CQRS/ES.

Thanks in advance,
Dharmjit Singh

Lee Hambley

unread,
Jan 15, 2020, 4:33:52 AM1/15/20
to ddd...@googlegroups.com
I am still exploring DDD and associated patterns ES/CQRS. Please ignore if I ask something very silly. I have few questions around micro services

1) Best approach to show aggregated data from multiple services in one of the UI view. CQRS/aggregation service etc.


I really liked this guy's approach. Sorry that I only have a guide/reference in video form, but it's definitely worth the time investment.
 
2) Pagination/Searching and Sorting in that view based on different fields of different microservices.

I don't have any good advice except that it will probably be painful and difficult to do reliable pagination and sorting across multiple APIs with sane results. If you did CQRS you'd build a "projection" that had all the view data you needed, already packed into documents, then you just build a simple pagination/sorting API over that "super document" list.

Mauro Servienti

unread,
Jan 16, 2020, 11:57:55 AM1/16/20
to DDD/CQRS
I am still exploring DDD and associated patterns ES/CQRS. Please ignore if I ask something very silly. I have few questions around micro services

1) Best approach to show aggregated data from multiple services in one of the UI view. CQRS/aggregation service etc.


I really liked this guy's approach. Sorry that I only have a guide/reference in video form, but it's definitely worth the time investment.

Thanks. If anyone is interested, I wrote a blog post series about the topic. It's available on my blog at https://milestone.topics.it/categories/view-model-composition.
Back to the topic of the conversation, I still have in my to-do list one last article about pagination and sorting. Hopefully, I'll get it done soon.
I'll try to summarize here what could be done briefly. I'll use some specific terminology discussed in the series above. Please read it before proceeding.

I'll use the shopping cart sample and only two boundaries (Sales and Marketing), to keep it simple. Adding more "boundaries" should not be a problem at all.

- The sales boundary owns the list of  product IDs in the shopping cart and prices
- The marketing boundary owns product names and descriptions.

When the shopping cart is requested, sales intercept the request and loads the list of product IDs in the cart, then raises an event that is handled by marketing, and based on the list of IDs, names and descriptions are loaded and appended to the "composed" ViewModel.

Now, if a request like "GET /shopping-cart?page=0&pagesize=10" comes in, then Sales can apply pagination to the list of IDs in the cart. No other data are needed. When Sales raises the event, Marketing will add names and descriptions to an already paginated set of IDs. Marketing doesn't need to know anything about pagination. We could say that when composing lists only the "master" boundary (in this case Sales) is responsible for pagination.

If the request looks like the following "GET /shopping-cart?sortby=description" then Sales doesn't care at all. The composition process will behave exactly in the same way, when Marketing handles the event published by Sales it'll compose data in the ViewModel and once done sorts the list based on the description. The order of items in the shopping cart won't affect other boundaries.

This makes the sorting process simple if lists are sorted by one single property/attribute. A slightly more complex process needs to be applied in case the incoming request is something like "GET /shopping-cart?sortby=description,price". The result should be sorted by description and then by price, but description and price are in two different boundaries which bring on to the table te very annoying issue of boundaries dependencies. I'll discuss those in the blog post.

Thoughts?
.m

Lee Hambley

unread,
Jan 17, 2020, 12:11:01 PM1/17/20
to ddd...@googlegroups.com
That makes a lot of sense to me. Thanks for jumping in the list with some more content. I've gotten really a lot from your talk/video!

Ahoy,



--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dddcqrs/CAKhTcw0%3DA08ydgj5Ex6h1w_fbJwu6gUtBBr91mrwQ_r_pm2ifQ%40mail.gmail.com.

Mauro Servienti

unread,
Jan 25, 2020, 5:25:38 AM1/25/20
to DDD/CQRS

Thanks again,
.m

--
Mauro Servienti
Reply all
Reply to author
Forward
0 new messages