Date
Attendees
- 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?
- Orderable is everywhere.
- Is Referencedata shared kernel?
- Can we extract bounded context somewhere:
- Divide Requisition.
- Report, Management, Auth contexts.
- User is used everywhere. Only display name should be in shared kernel.
- 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.
- Orderable
- 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.
- 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 blocs on Dev Group