Date

24 Nov 2017

Attendees

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