What goes in a Shared Library? DTOs?

[brandon.bowersox-johnson]

Hi Dev group,

You may know that a Shared Library for java code now exists. The idea is to keep common classes in one library for use across the different OpenLMIS v3 micro-services. Examples might include Money.java or Message.java, which is a wrapper for our translate-able error messages.

This week we were asked whether DTO classes should live in a shared library. What do folks think? Obviously we don't want tight coupling between different micro-services. Yet on the other hand, currently when a DTO changes, it is my understanding that the code is being copied and pasted into the other services that use that same DTO.

-Brandon

[Darius Jazayeri]

I haven't read up on best-practices for this, but I think each microservice should be responsible for building and publishing its own DTOs as a (separate) library that can then be used by other services (and it can use it internally also).

For example the Reference Data service would define the DTOs in a maven submodule that builds referencedata-client-utils.jar (and publishes it to maven).

Any service may choose to import the xyz-client-utils library for any other service on an as-needed basis, instead of implicitly introducing dependencies between every pair of services via library they all share. (A shared library that's purely full of utility classes doesn't have this problem.)

The other benefit of what I'm suggesting here is that the library is version along with the microservice that generates it, so implementations have more flexibility in using different versions of services, rather than having a shared library force them to use a particular set of versions implied by the reference distribution.

-Darius

--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/42b488d7-7f42-427a-81a7-6f48ee94b07c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Darius JazayeriPrincipal Architect - Global Health

Email

djaz...@thoughtworks.com

Telephone

+1 617 383 9369

[Łukasz Lewczyński]

Hi,

I agree with that each micro-service should provide a library that should be used to communicate with that service. So for example the fulfillment service should provide a communication library that would contain DTO classes and a class that should be used to send/receive data to/from the fulfillment service.

In the shared library there should be only classes that could be used by each micro-service like for example classes that we use to create a Spring Context ( CustomWebMvcConfigurerAdapter, Application, MethodSecurityConfiguration, etc) or classes that we use to create a localised error message.

Regards,
Łukasz

Łukasz Lewczyński
Software Developer
llewc...@soldevelo.com

SolDevelo Sp. z o. o. [LLC]
Office: +48 58 782 45 40 / Fax: +48 58 782 45 41 Al. Zwycięstwa 96/98 81-451, Gdynia
http://www.soldevelo.com

Place of registration: Regional Court for the City of Gdansk KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585, Share capital: 60,000.00 PLN

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.

To post to this group, send email to openlm...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAOKb-R54xEfuhaJXz5QZzmFWfKaUYZXykPNbujTsbrz4ixWLzQ%40mail.gmail.com.

[Paweł Gesek]

We've discussed this on the last tech call and we are all in agreement to proceed with this approach. (Meeting notes: https://openlmis.atlassian.net/wiki/display/OP/2017-01-24+Meeting+notes)

Regards,
Paweł

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/46da9981-c571-2f2d-0240-7872ccbefa59%40soldevelo.com.

For more options, visit https://groups.google.com/d/optout.

--

Paweł Gesek
Software Developer / Team Leader
pge...@soldevelo.com / +48 690 020 875