2017-11-24 November learning session

Date

24 Nov 2017

Attendees

• 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)

Goals

• 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?

Discussion

• 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

Wrap up

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.

Action items

• Nikodem Graczewski (Unlicensed) to choose more practical DDD material and organize meeting
• Paweł Albecki (Deactivated) to follow with implementing some DDD building blocks on Dev Group