2017-11-24 November learning session

Nov 24, 2017

• @Sebastian Brudziński

• @Paweł Gesek

• @Nikodem Graczewski (Unlicensed)

• @Mateusz Kwiatkowski

• @Łukasz Lewczyński (Deactivated)

• @Paweł Albecki (Deactivated)

• @Klaudia Pałkowska (Deactivated)

• @Jakub Kondrat

• @Joanna Bebak (Deactivated)

• Watch learning material Domain Driven Design (https://www.pluralsight.com/courses/domain-driven-design-fundamentals) - Modeling Problems in Software, Elements of a Domain Model

• Discuss watched materials and compare to how things are handled in OpenLMIS - are there any ideas/approaches/workflows we can adopt in OpenLMIS?

• Ubiquitous language – same language for developers and domain experts. We have different meanings for technical words (e.g. order line item) than client can have.

• Bounded Context – boundaries.

  • Orderable

    • Do we need whole object or just code in different services?

    • Orderable can change and we need/use its properties in requisition.

    • If all orderable information need to be in snapshot? Other approach is versioning of orderables.

  • Requisition

    • During approve we need only two fields from line items. We validate every field even we don't use it.

    • Separate resource for requisition for approval?

    • Immutable orderables as a way to make requisition proper Aggregate.

  • Do we have bounded contexts in OpenLMIS?

    • Are microservices give us proper bounded context? We believe they will after few adjustments.

    • Orderable is everywhere.

    • Is Referencedata shared kernel? We can say so.

    • Can we extract bounded context somewhere?

      • Divide Requisition.

  • Report, Management, Auth contexts.

  • User is used everywhere. Only display name should be shared between services.

  • Every service should have own abstraction e.g. CCE should not be impacted if Referencedata user is changed.

  • Importer/Exporter pattern can be helpful with abstraction.

  • Dtos are abstraction itself. Should be in shared library so every dependent service doesn't have to be updated after dto will change.

• Problem domain in OpenLMIS – medical products management.

• Core domain in OpenLMIS

  • Who is customer? Ministry of Health or any Organization that want to implement OpenLMIS.

  • Requisition is core domain.

• Sub-domains

  • Stock management

  • CCE

We have asked every participant to give a score on how useful this meeting was and how helpful this specific material was. The voting was anonymous and each participant could give a score from 1 (useless) to 10 (very useful).
The averages were:

How useful are those meetings:  7.25/10
How useful was this specific material? (DDD - Fundamentals):  5.62/10

Final thoughts

• Requisition as an aggregate, to manage line items we should use only requisition class and snapshot orderables.

• "Talking" with client on material was not necessary.

• We should follow up with DDD in more practical way.