Domain-driven versioning enables different versions of the same service to be run at the same time in the same runtime environment. That is, two consumers might call the same service using different interfaces. While one consumer uses a newer version of the service, another consumer might use an older version.
These are plenty of articles about how to deal with this issue, but these articles usually assume additional requirements that have to do with automatic updates of services. However, policies for automatic updates lead to additional complications and requirements. Instead, I'd like to present a trivial versioning approach that has proven to be appropriate in all projects I have seen so far. Because it keeps things simple, there have to be good reasons not to follow this approach. So, we'll look at this option first, before briefly exploring some alternatives.
My trivial policy for domain-driven versioning is simply not to provide any technical support for versioning. That is, treat every modification of an existing service as (technically) a new service.
If you need to modify a service that returns customer data (say,
GetCustomerData()), you simply
introduce a new service that incorporates the modification. Of course,
you should make it obvious that this new service is a successor of the
other service, which you can easily do by naming the new service
GetCustomerData_2()). To avoid having a special ...