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.
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:
„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:
- ... there could be more like deactived, hidden, whatever
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.
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.