Support "domains" for events and services

Be great to support domains for events and services and maybe even a new page that shows users their domains where they can see services and matching events within that domain.

Questions we need to think about

• Can events/services belong in more than 1 domain?
• Can events/services only have 1 domain?
• Where should we store the domain? Guess the events and service can have a new property called domain.

Any ideas/thoughts anyone?

Be good to get some ideas going on this one.

[boyney123]

Going to close this issue now that EventCatalog now supports domains 😃

[jirayrva]

Hi @boyney123,

I think (sub)domains is a very much needed feature. Without it, everything is sort of defined in one “global” domain which is too messy for a real-world scenario.

TL;DR

• an event/service belongs to one subdomain only
• an event might belong to one specific entity within the subdomain
• subdomains might be nested (in a hierarchy)

Long version

On sharing events between subdomains

In my experience, coming from a Domain-Driven design (DDD) perspective, all services and/or events fall into a subdomain (more on this below). If the same event is needed in another subdomain, it just happens to be a copy of it, and that’s the whole “bounded context” idea. But I would argue that you wouldn’t even have much of that (events shared between subdomains), if you are respecting the boundaries between bounded context. Ultimately, an event is a notification that the state of the system has changed. If two subdomains are publishing the same event, that practically means, two subdomains are doing the same change in the system, which most probably indicates that the two subdomains have write access to the same data. That violates data ownership principle.

Even when two subdomains have events with similar names and schema, the fully-qualified name/type of the event would be different since it would include the subdomain (assumptions)

Furthermore, subdomains should enable autonomy. Meaning, you can change an event without having to revisit the entire system. Thus, having events shared between subdomains will only tangle these subdomains and prohibit autonomy.

These are all arguments to say: events belong to one subdomain only.

On having entities in the subdomains

In reality, we define a hierarchy of subdomains (hence the sub in subdomain), which is convenient for enterprises where products are split upon multiple teams. Then, we define the entities/aggregates in those subdomains. We see these more like objects in Object-Oriented Programming (OOP) sense. Thus, each entity has a set of commands and these commands result in changing the system. The critical principle here is that, if a service changes the state of the system it must notify the world about the change by publishing an event. Thus, events are defined within entities. Multiple commands within the same subdomain might publish the same event. This sharing is safe as long as these commands are within the same subdomain (unlike sharing commands between subdomains)

From a practical approach, the hierarchy of subdomains is not critical to have. On the other hand it would be great if there is the capability to define which entity within the subdomain does the event belong to. Maybe another tag called entity or aggregate

Disclaimer: many assumptions are made in my comments above (mainly, strong DDD), which may not hold true in different contexts.