Domain-driven Design workshop
Instructor: Jimmy Bogard
Not all subdomains require software!
Generic subdomains, might be good to outsource / integrate different product
Supporting subdomains, low complexity / may or may not require (custom) software
- Solved problem? Yes / No
- Competitive advantage? Important / Not important
- Complexity? High / Low
- Volatility? High / Low
- Implementation? In-house / Buy / Outsource
- Problem? Interesting / Solved / Obvious
Ubiquitous language: A single, shared language describing the busines domain
- Use same language in all layers (screen, api, code, database)
- Course admin
- Tasks (Meeting, Scorm, Forms)
- Participant / Invitee / Admin
- Meetings (Attendee)
- Groups (Member / Previous member / Counselor / Leader)
- Edit form
- View results
- Tasks Variants (these belong in respected domain/subdomain):
- Variants is about who is allowed to create/edit/see them, and specifically Course which is a required Task to complete a course.
- Each should have their own endpoints to create/updateAnswerset/view, but the API should be identical, so the frontend can be as simple as possible.
- Course-Anonumous *Regular form task w/Anonumous
- Course *Regular form task
- SKIL *Global forms
- Office *New
- Doctor *New
- Kommunedashboard *New
- Preview *Hack
- Profile / Office
- Automatic emails (core)
- Helfo (supporting domain)
- Authentication (keycloak, generic/supportiv subdomain?)
- Implement outbox pattern for Integration (old Domain) events, for example "UserCreated"
- Remove "SKIL Integration messages" like UserProfileChanged, and have the domain dispatch its own messages
- Async Events (Domain Events) vs Integration Events
Link domain to Sharepoint folder? upload files there instead of to S3?
Saga = Specialized Aggregate / Entity