...
- 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 in shared kernelbetween services.
- Every service should have own abstraction e.g. cce 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 Who is customer? Ministry of Health or any Organization that want to implement OpenLMIS.
- Requisition is core domain.
- Sub-domains
- Stock management
- CCE
...
- 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