Update Link Object with SourceDomain

[ebopalm]

Description

Update the Link Object to optionally include the Source Domain of the linked event.
Current Object definition:

"links": [
  {"type": "CAUSE", "target": "8f3e0f94-5d11-46e7-ae02-91efa15d2329"},
  {"type": "COMPOSITION", "target": "43ee71d2-6d91-496a-b9cf-d121ff1d1bcf"}
]

Proposed new Object Definition:

"links": [
{"type": "CAUSE", "target": "8f3e0f94-5d11-46e7-ae02-91efa15d2329", "domainId": "string"},
{"type": "COMPOSITION", "target": "43ee71d2-6d91-496a-b9cf-d121ff1d1bcf", "domainId": "string"}
]

Motivation

Today's link model implicitly assume that links between events are within the same Eiffel Domain. When several Eiffel Domains have cross-Domain link treads, end-to-end link traceability is not accurate enough without expressing the DomainId to which the link is referring.
The effort to locate a linked event that is outside your own Eiffel Domain context could be overwhelming compared to to the one when a DomainId is provided. With this expanded Link notation, Eiffel protocol will be closer to being Enterprise scalable.

Exemplification

1. Multi-Domain Eiffel Intelligence aggregation.
2. Eiffel Analytics including traceability panning multiple Domains
3. Product integration using many Eiffel Domains related to each other in a e.g. tree structure.

Benefits

Reduces efforts to locate information of a linked event.
Elevates the Eiffel protocol Enterprise capabilities.
Supports Eiffel Product development cross organizational/functional boundaries.

Possible Drawbacks

Using cross-Domain event linking will introduce the challenge of finding the entry point to related Domains and their events. How Eiffel Domains has knowledge on such Federated Domains can be solved in a a number of ways. Either "internal", where each Domain knows about its federated ones by static configuration of Domain local systems like an Event Repository or a local directory service for Foreign/Federated Domain Information, or a global solution where a central or regional entity has a Directory/Federated Domain information service. Currently a "local" solution exist in the "EasyToUse" binary distribution of the Event Repository.

[e-backmark-ericsson]

This is an interesting idea that has also crossed my mind several times. Thanks for writing it down :) For clarification, when you say 'Domain' or 'Eiffel Domain' you refer to the meta.source.domainId field, I assume. It is for example described here: https://github.com/eiffel-community/eiffel/blob/master/eiffel-vocabulary/EiffelArtifactCreatedEvent.md#metasourcedomainid. The assumption is that the domainId somehow delimits areas in which events are sent and potentially stored in some event repository/database. Including the domainId in the link itself helps a consumer to find the linked event in such a scenario where there is no global/distributed event repository that would collect all events from all domains.

We must take into consideration that this suggestion violates the idea of not repeating the same data in multiple events, as the domainId will be given both in the target event and in the event referencing the target event.

[ebopalm]

The "Domain" and "Eiffel Domain" representation as the domainId in the "proposed new object definition" is referring to link provided above. (= Yes).
However, the fact that domainId is still free text format and there should emerge a need for a more formalized way to uniquely represent an Eiffel Domain, could lead to further updates to the protocol. One thing that could be done, that is still backward compatible, is to adopt the proposal of a structural notation of domainId as described in the link above. Introducing strict format of domainId is not backward compatible.
As of the potential violation of data representation, if we regard the domainId the same way as we regard the eventId, that is as meta-data rather than data, we are not breaking the non-repeating-data clause.

[e-backmark-ericsson]

After an offline chat with @ebopalm, this request is still relevant and wanted. We should go ahead and write a PR for it.

[magnusbaeck]

Reassigning to myself after a discussion with @e-backmark-ericsson. Will try to churn out a PR within a week.