Fear of refactoring implies unrealistic expectations in your work environment. I would work to remove that fear first of all. If you want an automated enforcement toil then you will probably find that a suite of unit tests that reports code coverage will be the most-recommended approach. However all that really enforces is unit tests being written and not real refactoring.

If you have reusable code, I suggest packaging it as a nuget (or similar) package and re-using it. Update your nuget and deploy to each service that uses it as part of your next updated.

Packaging like this can encourage both comprehensive unit tests as well as logically factored components.

Then you can ask questions like "why does this nuget have compnent-x dependencies" and "why didn't you use nuget-y that already has that functionality."

Fear of refactoring implies unrealistic expectations in your work environment. I would work to remove that fear first of all. If you want an automated enforcement tool then you will probably find that a suite of unit tests, that reports code coverage, will be the most-recommended approach. However, all that really enforces is that unit tests are being written; not real refactoring.

If you have reusable code, I suggest packaging it as a nuget (or similar) package and re-using it. Update your nuget and deploy to each service that uses it as part of your next update.

Packaging like this can encourage both comprehensive unit tests as well as logically factored components.

Then you can ask questions like "why does this nuget have component-x dependencies" and "why didn't you use nuget-y that already has that functionality".