1

I have a complex system which I have done a pretty good job at separating concerns with microservices. All data is passed around through queues, and the result of the system are messages to update a database model owned by a single agent. I don't have any shared code among the agents of the system.

The problem I am having is the entire model being stored in the database then needs to be viewable in an administration website project I have. The whole model is not too complex, just a few classes, but changes have to be made in two places. It is 100% duplicate code.

Is this encouraged with microservices, or in my scenario would it be OK to put this into a shared library.

2

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:

  1. share source code directly from a single common repository
  2. make a shared library
  3. 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.

1

I see no reason to call this bad design. Indeed, if you are saving effort (across the life-time of the codebase) by sharing the model classes, then it is a win.

The only potential drawback that I can think of is that it may force the development cycles of the front-end and back-end to be more closely coordinated than if the code was not shared. But that could also be a good thing.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.