0

In an application that uses event sourcing is it acceptable to have aggregate-wide events?

Consider a contrived example of a blog application that provides the ability to create posts and add and remove simple tags (post would be the aggregate root).

This might result in the following events:

PostCreated: postId, "title", "content"
TagAdded: postId, "Foo"
TagAdded: postId, "Bar"
TagAdded: postId, "Baz"
TagRemoved: postId, "Bar"

Replaying the above event stream would result in a post with a title, content and two tags ("Foo" & "Baz").

Now imagine the user interface only allows you to select existing tags whilst creating a post and doesn't accept free text; only privileged users have the ability to update the master list of tags.

Now when a privileged user creates a new tag, a corresponding event needs to be created so that a) the information is actually stored in the event storage and b) at some point the read model is updated so that users creating blog posts can select the new tag in the UI.

Having an event that looks like TagCreated: postId, "NewTag" doesn't seem right to me as the information does not directly apply to a single post.

Considering that in this case the information does not warrant it's own aggregate root and will only be used in this bounded context I would expect an event along the lines of:

TagCreated("NewTag")

These events would be stored in the event storage using the same aggregate id as the previous set of events for a specific post but without an id for the specific aggregate instance.

So far this sounds like a logical way to handle the problem but was wondering if I am missing anything obvious by approaching it this way.

Benjamin Gale
  • 12,977
  • 6
  • 62
  • 100

2 Answers2

0

IMHO you're complicating your life unnecessary. Domain events are usually available cross bounded context and they should be associated with an aggregate root (AR) by referencing its id.

In your example, I'd consider Tag to be a value object, so it would require a post id. But if you want the Tag to be available as itself, then it would be an AR and so, the event would have a TagId property.

Btw, a domain event is a DTO, meant to be available everywhere, they're not a domain detail that needs to be encapsulated in an aggregate.

MikeSW
  • 16,140
  • 3
  • 39
  • 53
0

I think you missed the concept "tag catalog" or something like that. It could have a single aggregate (or perhaps you will sometimes have several catalogs for different user groups or something like that) with the catalog as the root, containing all the tags as value objects.

Holger Thiemann
  • 1,042
  • 7
  • 17