Making meta.source and meta.source.domainId optional

[d-stahl-ericsson]

I'm seriously questioning the value of making domainId a required field. The fact that it is used internally in implementation X doesn't mean it's necessarily relevant in the general case.

[e-backmark-ericsson]

I agree. It should be recommended to specify a source of the events, but the protocol should not enforce it.

[rogpers-ericsson]

One consequence of not filling in domainId is that once an event has "left the message bus" it is impossible to find events from a particular domain.

Whether this is big problem is another question. Looking around at existing ES-queries, by me and others, domainId is often part of the query, This is typically "needed" as many ERs pulls in event from multiple domains - needed as ES is not federated.

[e-backmark-ericsson]

I agree with you as well, Roger. But it still think the domainId doesn't need to be mandatory. For small deployments of the Eiffel protocol, with a single message bus instance, there is only one 'domain' to talk about. In more complex deployments though, it should be highly recommended to make use of the domainId. Not the least when it comes to message bus federation and conditional storage of historical events in dedicated databases. So, maybe the recommendation should be strengthened even further, @d-stahl-ericsson , with a reference to the benefit of using domainId for message bus federation and conditional event storage? And that the scalability and traceability aspects of Eiffel would benefit from using it.

[d-stahl-ericsson]

Yes, keeping track of the source in one way or another is definitely good practice. I don't mind making e.g. A VERY EMPHASIZED RECOMMENDATION to that effect ;)

The thing is that 1) As Emil points out, in small deployments it's pretty much irrelevant. 2) There are many ways to do it. The "domain" concept is actually fairly arbitrary - it's something we made up. And it works, and because we have enforced it people use it. That's great. But the fact that when we in the public domain (no pun intended) have trouble explaining what exactly a domain is ("it's a topological concept...") is a tell-tale sign that this isn't something we want to force onto users.

[p-backman-ericsson]

Good points everyone. Just want to point out that even if you start out small you do not know where you will end up or where your events will be used in the future. So I usually tell people to think big.

If we look outside of the protocol definition we use the domain concept in the implementation of REMREM. It is a vital part for routing of the messages in RabbitMQ. So if we do not manage to define domain in the protocol definition we just push the problem to the implementation... Perhaps we should try again to define the domain concept again?

[erobged]

I'd like to throw in my two cents ... I think Eiffel will be taken up in the open source communities by large organizations. I don't feel Eiffel will be suitable for small organizations that are mainly centralized. With that in mind ,I believe the larger organizations (enterprise level etc,.) will need a Domain concept to provide their Support Organizations with the necessary goodies that come with our Domain concept. Otherwise they will have to develop them themselves, which may make Eiffel less attractive...

Maybe, define our domain concept as-is and when to use it...and then let the user decide if they want to use it or not.

[d-stahl-ericsson]

@p-backman-ericsson: That's a problem. I'd like to understand better how Remrem makes use of domainId. It surprises me that it would play an important part in that implementation. As for being a vital part of RabbitMQ routing, yes, but remember the principle to keep envelope details out of the event itself.

@erobged: Yup, the idea is to keep it, just not make it mandatory.