What goes in a Shared Library? DTOs?

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

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

···

On Sat, Jan 21, 2017 at 5:43 AM, brandon.bowersox-johnson brandon.bowersox-johnson@villagereach.org wrote:

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

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 openlmis-dev@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
djazayeri@thoughtworks.com

Telephone
+1 617 383 9369

ThoughtWorks

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

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](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

llewczynski@soldevelo.com
On 01/21/2017 09:25 AM, Darius Jazayeri wrote:

    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

      On Sat, Jan 21, 2017 at 5:43 AM, brandon.bowersox-johnson <>
      wrote:

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

            --

            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                 . To view this discussion on the web visit

Darius Jazayeri* Principal Architect - Global Health*
Email

Telephone
+1 617 383 9369

ThoughtWorks

  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 openlmis-dev@googlegroups.com.

  To view this discussion on the web visit [](https://groups.google.com/d/msgid/openlmis-dev/CAOKb-R54xEfuhaJXz5QZzmFWfKaUYZXykPNbujTsbrz4ixWLzQ%40mail.gmail.com?utm_medium=email&utm_source=footer)      . For more options, visit .

brandon.bowersox-johnson@villagereach.orgopenlmis-dev@googlegroups.com
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](https://groups.google.com/d/optout).

          djazayeri@thoughtworks.com[https://groups.google.com/d/msgid/openlmis-dev/CAOKb-R54xEfuhaJXz5QZzmFWfKaUYZXykPNbujTsbrz4ixWLzQ%40mail.gmail.com](https://groups.google.com/d/msgid/openlmis-dev/CAOKb-R54xEfuhaJXz5QZzmFWfKaUYZXykPNbujTsbrz4ixWLzQ%40mail.gmail.com)

https://groups.google.com/d/optout

We’ve discussed this on the last tech call and we are all in agreement to proceed with this approach. (Meeting notes: )

Regards,

Paweł

···

https://openlmis.atlassian.net/wiki/display/OP/2017-01-24+Meeting+notes
On 23.01.2017 09:26, Łukasz Lewczyński wrote:

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
  -- 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 . To post to this group, send email to . To view this discussion on the web visit . For more options, visit .


Paweł Gesek

    Software Developer / Team Leader

      / +48 690 020 875

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](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

        Łukasz Lewczyński

      Software Developer

        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](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

llewczynski@soldevelo.com
On 01/21/2017 09:25 AM, Darius Jazayeri wrote:

      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

        On Sat, Jan 21, 2017 at 5:43 AM, brandon.bowersox-johnson <>
        wrote:

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

              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 . To view this discussion on the web visit

Darius Jazayeri* Principal Architect - Global Health*
Email

Telephone
+1 617 383 9369

ThoughtWorks

    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 openlmis-dev@googlegroups.com.

    To view this discussion on the web visit . For more options, visit .

brandon.bowersox-johnson@villagereach.orgopenlmis-dev@googlegroups.com
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](https://groups.google.com/d/optout).

            djazayeri@thoughtworks.com[](https://groups.google.com/d/msgid/openlmis-dev/CAOKb-R54xEfuhaJXz5QZzmFWfKaUYZXykPNbujTsbrz4ixWLzQ%40mail.gmail.com)[https://groups.google.com/d/msgid/openlmis-dev/CAOKb-R54xEfuhaJXz5QZzmFWfKaUYZXykPNbujTsbrz4ixWLzQ%40mail.gmail.com](https://groups.google.com/d/msgid/openlmis-dev/CAOKb-R54xEfuhaJXz5QZzmFWfKaUYZXykPNbujTsbrz4ixWLzQ%40mail.gmail.com)

https://groups.google.com/d/optout

openlmis-dev+unsubscribe@googlegroups.com
openlmis-dev@googlegroups.com
https://groups.google.com/d/msgid/openlmis-dev/46da9981-c571-2f2d-0240-7872ccbefa59%40soldevelo.com
https://groups.google.com/d/optout
pgesek@soldevelo.com