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

kucjac commented 1 month ago

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 commented 1 month ago

@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 commented 1 month ago

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?

event-catalog / eventcatalog