We've extracted our email sending into an EmailService - this is a microservice that provides resiliency and abstracts the email logic into an Infrastructure service. The question is how the interface to the EmailService should be defined, with respect to the information it requires about the [User] domain
Approach 1:
EmailService exposes an interface that takes all the fields of the [User] domain that it requires.
Approach 2:
The EmailService interface takes only the UserID
. The EmailService then queries the UserService using this ID to fetch the fields that it requires
There are some obvious pros/cons with each approach.
Approach1 requires the calling service to know everything about a User
that the EmailService
requires, even if its not part of the callers Domain representation of a User. On the other hand the contract between the services is explicit and clear.
Approach2 ensures that the [User] fields are fetched as late as possible, minimising consistency problems. However this creates an implicit contract with the UserService (with its own problems)
I've been doing a lot of research here and on SO, but I haven't been able to find anything around this specific interface design problem. Keeping DDD principles in mind, which approach is correct?