There is nothing wrong with having the same code running in two different contexts. I would not even consider this duplicated code. What I would consider duplicated code is if the source code is forked and now we have very similar but potentially different or diverging code being maintained separately, and, this is a problem that can continue to grow worse over time.
Now, as you say that
changes have to be made in two places
This indicates that you have forked sources, and it is indeed duplicated. I would definitely deem two different repositories both editable yet having the same duplicated source code as an undesirable situation.
So, you have several choices:
- share source code directly from a single common repository
- make a shared library
- make a micro service
Personally, I favor approach (1) for many situations, for its simplicity, if you can get all parties to agree to source at least that set of classes from a common repository, and you can version all the consuming clients together when incompatible changes happen in that code.
I suppose you can also use multiple repositories as long as you designate exactly one as the source of truth, and the other is never to be edited by humans (I would provide some automation to copy the sources as part of build.)
Next, I favor approach (3) in a micro service environment. A shared micro service can abstract clients from certain details and allow independent maintenance of that service from the other clients, affording some looser coupling.
Lastly, I favor the shared library approach. It has similar versioning problems to shared source code with some additional build, test, and packaging issues; though in its favor can offer some formalism of your classes as an API.