Gang Fang's Blog

The defect coaching team’s services are organized in a very fragmented way, as in the dependency relationships span among many different packages. I am attempting to add attributes to simple foundational class but found it is used and created in multiple dependent services’ test classes, which implies I need to go to all these dependent services to update the creation of the object of the class. Moreover, these dependent services’ pipeline doesn’t include the package where this foundational class belongs as a dependent package, hence it is likely that to deploy safely (i.e., not to break any dependent services) I need to manually merge this update into all these pipelines.

Nov 15:

There are some workarounds to this, for example, setting a default value to the new attributes so that existing object creations don’t need changes. However, that isn’t a solution. To do it the right way based on the current code structure, all those dependent services require changes. So then the question is: is there a way to restructure the code to avoid such pain in the future?

Backward compatibility.

What I had in mind can be articulated as:

Microservice Architecture: If not already in place, consider a microservices architecture where each service has its own bounded context and data model. This can reduce the impact of changes in one service on others.

But is that a violation of DRY, Don’t Repeat Yourself principle as the same data model is defined in multiple bounded context? I am reviewing why the class I am looking at is used by other services.