You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
How would you go about putting in functionality that would be shared between two or more use cases? An example is emailing and the building of those emails from templates.
User or Registration domain with a usecase that will need to send user registration emails
Order domain with a usecase that will need to send order confirmation emails
EmailRepository that does the work of sending the emails
TemplateRepository or AssetRepository that does the work of locating templates
I might do something like the following
EmailRepository
- sends the emails through an email provider or service
- Send(email domain.Email) error
TemplateRepository
- locate templates from the file system, a database, bindata, or other
EmailService or EmailManager
- contains the logic of turning templates and data into email entities
- is a domain service it will not use any repositories
- BuildConfirmationEmail(data {TBD dataType}, templates {TBD templatesType}) domain.Email
OrderUsecase
- uses EmailRepository, TemplateRepository, EmailService
- is an application service and uses repositories and domain services
When the User and Order domains want to send emails they'll need to rely on the same three dependencies. This might be OK but I'm not sure and I might have confused a concept or three and that has me tangled up in this knot.
If there were a report component to the application, it may use the same templates repository but would output CSV, Excel, or PDF documents instead. Having a template or assets domain makes sense, I just haven't found the right approach to bringing it together with the logic and other repositories in a shared manner that is used in different usecases that sits well with me.
edit: Giving this some thought and the email problem would probably be best solved using Domain Events. So instead of operating on the aggregate in the User domain performing registration and also sending the email. I would register the user then raise a UserRegistered event that would at minimum have a listener in the Email domain. There the email could be built from templates, or anything, then sent out.
A bonus question regarding this current layout and imports. When there's a handful, say 8-10, modules to import things from do you have any suggestions on organizing or reducing them?
The text was updated successfully, but these errors were encountered:
Thanks for this repo btw.
How would you go about putting in functionality that would be shared between two or more use cases? An example is emailing and the building of those emails from templates.
I might do something like the following
When the User and Order domains want to send emails they'll need to rely on the same three dependencies. This might be OK but I'm not sure and I might have confused a concept or three and that has me tangled up in this knot.
If there were a report component to the application, it may use the same templates repository but would output CSV, Excel, or PDF documents instead. Having a template or assets domain makes sense, I just haven't found the right approach to bringing it together with the logic and other repositories in a shared manner that is used in different usecases that sits well with me.
edit: Giving this some thought and the email problem would probably be best solved using Domain Events. So instead of operating on the aggregate in the User domain performing registration and also sending the email. I would register the user then raise a
UserRegistered
event that would at minimum have a listener in the Email domain. There the email could be built from templates, or anything, then sent out.A bonus question regarding this current layout and imports. When there's a handful, say 8-10, modules to import things from do you have any suggestions on organizing or reducing them?
The text was updated successfully, but these errors were encountered: