Readside on multiple aggregates

[Alexandros Antoniadis]

Let's assume that I have 2 Aggregates (Author, Book) and for some reason, they cannot be merged in one and the Author has a list of the BookIds.

We want to query about the authors and get all the information within the Author entity plus some information from their related books.

To keep it simple let's assume that we want to get the names of the books that are written by the author. So we need a (denormalized) Cassandra table that has information about the authors + the book names for each author

In read-side, we will have a ReadSideProcessor that handles events about aggregate.

When an event about an author is retrieved (either AuthorCreated or BookAddedToAuthor) the event will contain information related to the Author aggregate, so it will contain BookIds instead of the name about the book.

So we need somehow to retrieve the extra information needed.

What would be the best way to handle this scenario?

I was thinking about querying a view about the books in the Author ReadSideProcessor when an event is retrieved, but I am not sure if this is the right way.  This doesn't really have to be a different readSideProcessor but another table in the same readside.

Other solutions would be event enrichment but it seems like cheating to me since the events would carry information that is not needed by the aggregates and is also redundant.

[Tim Pigden]

I have a similar problem. My options I thought of:

have the author readside processor subscribe to the relevant book events as well. If they're in the same service this is trivial. Otherwise you need to use message broker or something similar.

Then in your processor you create a second table bookid - bookname and keep it up to date.

How you divide entities between services is up to you but re-reading Vernon Vaughn's latest book he somewhere suggests services should mirror bounded context, so it's quite reasonable to have author and book in the same service.

This is fine if you assume that all books are likely to have at least one author, but will work out costly if most "books" have no "author".

Alternatively if the book never changes its name after creation, you could go and get the book name when a new book id comes your way - but if the book names change you'll get out of step.

Finally you could consider cassandra tables to be a more global construct and have your readside process query a book directory table managed by a book readside processor. This seems to me a bit less robust as you've got to worry about what other objects are doing internally - I'd only consider it if it looked like an important performance optimisation - millions of books and a need to avoid data duplication.

[Alexandros Antoniadis]

Thank you very much Tim.

As you correctly guessed Book and Author will be in the same bounded context. However, I believe that having the author readside processor subscribing to the book events has the problem that book and author events should have some common superclass of events since each readside processor processes events of a specific type. I believe that it is less awkward to manage the bookid - bookname table in the book readside processor, although it feels a bit like cheating since this table is needed by another processor. What do you think?

Another question that occurred to me about the read side processors is how well they fit in case we might want to separate read/write sides into different services. Having the readside processor in the write service seems unnatural since the read side shouldn't care about the reads, but readside processor is not going to work on the read service since there will not be persistent entities. The only way for this to work is to write the events from the write side to a message broker and have the read service processing these events and store them locally and then have a readside processor one these new type of events, which obviously is much more complex or even not use the readside processor at all as in the online-auction example (but offset tracking has to be done manually). What would be the approach in that case?

[James Roper]

On 11 March 2017 at 23:08, Alexandros Antoniadis <antoniadis.a...@gmail.com> wrote:

Thank you very much Tim.

As you correctly guessed Book and Author will be in the same bounded context. However, I believe that having the author readside processor subscribing to the book events has the problem that book and author events should have some common superclass of events since each readside processor processes events of a specific type. I believe that it is less awkward to manage the bookid - bookname table in the book readside processor, although it feels a bit like cheating since this table is needed by another processor. What do you think?

Another question that occurred to me about the read side processors is how well they fit in case we might want to separate read/write sides into different services. Having the readside processor in the write service seems unnatural since the read side shouldn't care about the reads, but readside processor is not going to work on the read service since there will not be persistent entities. The only way for this to work is to write the events from the write side to a message broker and have the read service processing these events and store them locally and then have a readside processor one these new type of events, which obviously is much more complex or even not use the readside processor at all as in the online-auction example (but offset tracking has to be done manually). What would be the approach in that case?

There's no need to duplicate the persistence of the events in the remote service - just update your read side directly in the code that subscribes to the message broker.  This is conceptually a read side processor, but it does not use Lagom's read side processor support, since that's specifically for reading directly out of the event log.

If you're using Kafka, it has its own internal offsets, so as long as you use the atLeastOnce subscriber, you don't need to worry about offsets in the remote read side.

On Friday, March 10, 2017 at 3:39:19 PM UTC+2, Tim Pigden wrote:

I have a similar problem. My options I thought of:

have the author readside processor subscribe to the relevant book events as well. If they're in the same service this is trivial. Otherwise you need to use message broker or something similar.

Then in your processor you create a second table bookid - bookname and keep it up to date.

How you divide entities between services is up to you but re-reading Vernon Vaughn's latest book he somewhere suggests services should mirror bounded context, so it's quite reasonable to have author and book in the same service.

This is fine if you assume that all books are likely to have at least one author, but will work out costly if most "books" have no "author".

Alternatively if the book never changes its name after creation, you could go and get the book name when a new book id comes your way - but if the book names change you'll get out of step.

Finally you could consider cassandra tables to be a more global construct and have your readside process query a book directory table managed by a book readside processor. This seems to me a bit less robust as you've got to worry about what other objects are doing internally - I'd only consider it if it looked like an important performance optimisation - millions of books and a need to avoid data duplication.

On Friday, March 10, 2017 at 12:11:17 PM UTC, Alexandros Antoniadis wrote:

Let's assume that I have 2 Aggregates (Author, Book) and for some reason, they cannot be merged in one and the Author has a list of the BookIds.

We want to query about the authors and get all the information within the Author entity plus some information from their related books.

To keep it simple let's assume that we want to get the names of the books that are written by the author. So we need a (denormalized) Cassandra table that has information about the authors + the book names for each author

In read-side, we will have a ReadSideProcessor that handles events about aggregate.

When an event about an author is retrieved (either AuthorCreated or BookAddedToAuthor) the event will contain information related to the Author aggregate, so it will contain BookIds instead of the name about the book.

So we need somehow to retrieve the extra information needed.

What would be the best way to handle this scenario?

I was thinking about querying a view about the books in the Author ReadSideProcessor when an event is retrieved, but I am not sure if this is the right way.  This doesn't really have to be a different readSideProcessor but another table in the same readside.

Other solutions would be event enrichment but it seems like cheating to me since the events would carry information that is not needed by the aggregates and is also redundant.

--
You received this message because you are subscribed to the Google Groups "Lagom Framework Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lagom-framework+unsubscribe@googlegroups.com.
To post to this group, send email to lagom-framework@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lagom-framework/a38e3427-70e1-4c4d-bc78-d407d185d8be%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

James Roper
Software Engineer

Lightbend – Build reactive apps!
Twitter: @jroper