The DCB Tag Dilemma

-

 

The “crazy wall” in the 2001 film A Beautiful Mind


DCB introduces tags as a consistency mechanism to identify the events required to enforce the consistency constraints. Along with the event type, tags are one of the two key attributes you can use to filter events relevant to a specific decision.


Type and tag describe two different sides of the same event—two complementary dimensions. Used together, they let you define very precisely which events you need to consider to make a particular decision. 


Let’s unpack what each dimension means.


Event type: what happened


An event’s type describes the nature of the fact itself: what happened.


“StudentSubscribedToCourse” is a typical event type. It doesn’t tell you who was involved or provide any context. It only conveys the kind of thing that occurred, describing the fact without tying it to the specific entities involved.


The type is also semantically tied to the business logic used to process the event. It’s easy to see why: events of the same type are generally handled by the same business logic.


Tag: who/what was involved


A tag is the identifier of a historic route in the domain.


Tags are semantically tied to the business rules, which guide the domain's historic routes in the right direction, with consistency boundaries preventing them from going astray.


The same meaning of consistency boundary was the core of the aggregate itself. The limitation was that an aggregate is only one historic route. In reality, a single decision may advance more than one historic route. The tags of DCB make it possible for the consistency boundaries to involve more than one historical route. Involving types in the selections avoids unnecessary collisions between things that are actually irrelevant.


A tag is orthogonal to the type. It identifies the elements involved in the specific occurrence—whether they are active actors, passive objects, or even contextual details.



A tag captures a shared property across a set of facts. All events that share the same tag involve the same domain element. That domain element might be a concrete entity, or something more abstract.

Examples


The actor who performed the action is typically represented by a tag.

In the student enrollment example, the student ID is a tag that marks the student’s involvement in the event.


Likewise, the course—as the target of the enrollment action—is also involved, and should be captured via a tag.


Context can also be tagged.

Consider a username change use case. An event of type “UsernameChanged” obviously involves the user who changed it and the new username. But there is another contextual piece of information which could be important to tag: the previous username that was released. Whether you should tag the released username depends on your domain constraints. For example, if the username’s state—taken vs available—matters when validating another user’s claim on that username, then it should be a tag.


In one sentence


For brevity (and with some loss of completeness), you can summarise the idea like this:


An event's type tells you what kind of thing happened; the tags tell you which historic routes were advanced by the event.


In the end, add a tag whenever you believe it will be a useful grouping key for protecting the consistency of your business model.


Want to learn more?
If you’re curious about tags, you can dive deeper here: https://dcb.events/topics/tags

Comments

Post a Comment

Popular posts from this blog

Chapter 1 - I am here to kill the aggregate

-
Image
The aggregate has always been, for me, one of the most controversial and weakest elements of Domain Driven Design. During my consultancy activity, I have been able to verify that the full understanding of the aggregate concept remains difficult for many. It is easy to make mistakes in the modeling phase, which will be very complex to fix in more advanced stages of development. As a result, some developers feel that the whole architecture is excessively difficult and complicated. I want to show you another world, where there is no aggregate. I am here to kill the aggregate. For those unfamiliar with it, let me introduce it to you. The Aggregate Its definition is, in my opinion, is quite vague: An aggregate is a cluster of associated objects  that we treat as a unit for the purpose of data changes. From blue book - Domain-Driven Design: Tackling Complexity in the Heart of Software - Eric Evans If you are confused by this definition, let's try to read what the blue book recommends for...
Read more

Chapter 2 - The Aggregate does not fit the storytelling

-
Image
continues from   Chapter 1 - I am here to kill the aggregate ...... One of the most powerful elements of DDD is that it has broken down the barriers between technicians and domain experts, thanks to tools capable of exploiting the immense potential of storytelling, first of all Event Storming. Storytelling is at the heart of human communication. Storytelling does not require any special competence or skill. It helps break down the barriers between technicians and business experts. In my experience, the usage of storytelling ensures an exceptional fluidity in the domain discovery process, but it hits a snag when we try to introduce the aggregate into the story. Indeed, by definition, the aggregate is the boundary of consistency. The aggregate is the component responsible for ensuring strong consistency constraints within an ecosystem that is, by nature, eventually consistent. But, at the same time, it tries to represent the business entity acting as the guardian of a set of bus...
Read more

Chapter 8 - The death of the aggregate

-
Image
continues from  Chapter 7 - Focus on the behavior ...... Event sourcing provides a huge advantage, because it decouples the persistence from the model needed for making a decision. Any message handler can build, on the fly , any model needed for making a decision, starting from the correct event stream. Let's make a practical example to understand better. Assume we need to handle the UpdateCourseCapacity Command .  This is a representation of the Event Store, where the events belonging to the course aggregate are highlighted in green. If we decide to use the classic aggregate approach, we need to reconstruct the Course aggregate starting from the stream of its events. Let's take a different approach instead, where the command handler is responsible for retrieving the model needed to make a choice. We immediately realize that not all the events that are part of the Course Aggregate contain information useful for our purpose. For example, the fact that the course has been renam...
Read more