Modifying write model solely to support a projection

[Richard Rodseth]

Imagine a system to notify users about alarms. I'm using Akka Persistence which supports streaming projections from the event store to the read side.

I'm considering three aggregates, (alarm)Definition, Site and User

Definitions and Users each have a site path which associates them with sites. When a user is opted in we can connect it to accessible sites. When a definition is created or updated, we can connect it to applicable sites.

The definition aggregate may in fact not be needed for notifications, since when an alarm occurs, the occurrence already knows about the site, so navigation could start there and dispatch to the users.

However, the read model may need to support "get users(subscribers) by definition". I could extend the write path so that when a user is opted in it is associated not only with accessible sites, but also with definitions applicable to those sites. But that logic would most likely be there solely to support the read model projection. Is that unusual or a red flag of any sort?

Thoughts?

[Renato Cavalcanti]

Yes, this raises a red flag. If I'm understand you right.

Instead of increasing coupling between your aggregate you should solve that on the read side solely. 

The projection generating your User view can also receive events coming from Definitions and as such you can enrich your User read model with data coming from Definitions Events.

You can have two streams:

1) Definitions Events flowing to Definition Projection

2) Definition Events + User Events flowing to User Projection

Note that your 2nd Projection should not rely on the 1st one. If needed, you can have an alternative "Definition read model" fed by 2nd Projection. That alternative "Definition Read Model" only exist to serve the "User Read Model".

Another solution is to have one single consumer of your stream that update all model. As such event are consumed in order and you can have views dependending on other views. But of course, this will generate a bottleneck on the read side. 

I hope it was helpful. 

Cheers,

Renato

[Richard Rodseth]

Thanks for the reply. That gives me food for thought. 

By "enrich" the User read model, do you mean something like updating a table record in place?

eg. if there's a table user_x_site_x_defn, the user events would fill in

u1 s1 null

u2 s1 null

and the definition events would replace the nulls

u1 s1 d1

u1 s1 d2

u2 s1 d1

?

--
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+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/dddcqrs.
For more options, visit https://groups.google.com/d/optout.

[Renato Cavalcanti]

Yes, that's it. 

By enriching I mean you add more data to it. In this case, data that is not coming from the User aggregate events. 

So the User view is more than a projection of User events, it's a projection of User Events + Definitions Events. 

To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.