Mapping service to domain instead of multiple services versions to domain.

[kucjac]

Use Case

In real life dynamic system a new service version is being release quite often. Currently EventCatalog requires mapping each service version to a domain. This might be very difficult or even impossible to follow all the changes in a live system. On the other hand, different service versions are not located in different domains.

Proposed Solution

What if a mapping of domain - service doesn't depend on the service version. Instead a service should be an independent abstraction which might have multiple versions. This way mapping services might be much easier and more natural.

Implementation Notes

No response

Community Notes

• Please vote by adding a 👍 reaction to the issue to help us prioritize.
• If you are interested to work on this issue, please leave a comment.
• If this issue is labeled needs-discussion, it means the spec has not been finalized yet. Please reach out in the EventCatalog Discord.

[XaaXaaX]

@kucjac
seems fair to me , can you elaborate your idea?
i assume as today a domain has a collection of services inside its markdown each service is identified by a combination of id and version.

Does this cause any problem?

[boyney123]

Hey @kucjac

Thanks for reaching out. Do you have your services within your domains? /domain/A/services/B? or do you have /domains and /services folders?

Also the version is optional for the frontmatter. If you do not specify a version then your domain will always pick the latest version of that service? Does this help?

Without understanding more it's hard to advice, but I'm happy to have a 30min call if you fancy it where I can learn more of your problems and advice you/get feedback? https://calendly.com/boyneyy123/30min might be easier?