Is there a ddd approach for sending events about embedded aggregate views

Question

I'm investigating how we can notify UI/async clients (websocket) about an update which happened in an embedded view.

Let me elaborate...

We currently have a newsfeed where NewsItem is an aggregate root which acts as a wrapper for news about other aggregates. News is extracted asynchronously from domain events of several aggregates. For example BlogPost. The NewsItem contains a type to identify where the news is about (for example NewPost), a timestamp and also the target user ID. There is a newsfeed view-service which combines the items with the real contents of the wrapped aggregate in order to serve the items as a JSON feed in a paginatable fashion. NewsItemViews about a BlogPost also contain the number of comments.

Now what should I do when another comments is posted to the BlogPost? Or the contents of a BlogPost is edited?

We already have a websocket-based callback system to update the UI of a registered target user.

How should I design the event when the contents of the view within a news item is changing?

Answer 1

I am facing a similar situation and want to share my thoughts and approaches on that. I see two approaches to this problem which I am going to explain one by one. Both share the (my?) understanding of the newsFeed aggregate.

NewsFeedAggregate

The NewsFeedAggregate models one news feed for exactly one person/user – since every user experiences its own perspective on news. So 1 User : 1 NewsFeedAggregate each consisting of n NewsItems.

Commands of the NewsFeedAggregate are

• Add News To Feeds Of Users
• Update/Change News in Feeds of Users
• Delete News in Feeds of Users
• Delete News in Feed of one user

Queries of the NewsFeedAggregate:

• Get NewsFeed of User

Approaches

Saga Pattern

„A saga is a long-running business process. It’s long running not necessarily in terms of time, as sagas can run from seconds to years, but rather in terms of transactions: a business process that spans multiple transactions. The transactions can be handled not only by aggregates but by any component emitting domain events and responding to commands.“

(Learning Domain-Driven Design, Vlad Khononov)

Using your example one could speak of 1 + n separate aggregates: NewsFeedAggregate and n of your separate Aggregates that originally produce the events. We want those aggregates to be losely coupled.

Therefor we create a BlogPostNewsSaga. This Saga conforms to BlogPostAggregate and the NewsFeedAggregate. It listens to the following domain events:

BlogPost Events

• BlogPostCreated
• BlogPostUpdated
• BlogPostDeleted
• ... there could be more like deactived, hidden, whatever

NewsFeed Events

• NewsItemSaved

So whenever a BlogPost has been created the saga notifies the NewsFeedAggregates that can now add a NewsItem to the NewsFeeds of the users. When the NewsFeeds have been updated the NewsItemSaved event is being emitted so the BlogPostAggregate can save the references to the corresponding news items. This is useful to emit Updated Events later and update the news items in the different news feeds as well.

This approach seems useful to me when you the NewsFeed is a dedicated value stream in your domain and you want the newsFeed team do autonomously evolve the newsfeed product. If this is not the case and the newsfeed is "just" a platform for other value streams to publish relevant events than have a look at the platform approach.

Platform Pattern

The Newsfeed could as well serve as a platform for all your value streams and offer services to them. Therefor the NewsFeedPlatform exposes the commands of our news feed aggregate using command handlers to other bounded contexts or at least software modules. Now the BlogPost module knows and conforms what the newsFeed platform provides. You could call that NewsFeed as a service if you want. This couples your blogpost to the news feed platform. But in exchange the BlogPost module is now in charge of the information design of its BlogPost-NewsFeedItems.

When to use which

I think the most important question here is: Who is in charge of the different NewsFeedItems data design? If it is the NewsFeed-Team/Component/Subdomain/Bounded-Context: than go with the saga pattern and decouple the newsfeed from other parts of your subdomain. If it is the source of the event and thus news feed is just and ambassador for your value streams than design newsfeed as a platform.