I have got the following scenario, which I have been thinking what would be the "best" way to solve it.
Request comes from the FE, which changes the status of a delivery, and that should trigger different things depending on the value of the new status.
-if confirmed, send email and also create pdfs -if dispatched, create pdfs and send some other emails to different people.
The way we are approaching this is:
FE changes status to
dispatched -> http call, controller receives the events, handles validation and so on, then updates the
db, that in turn trigger an event
DeliveryDispatched, which we handle asynchronously. That event handler would then create the pdfs and send the appropriate emails. All fine and dandy.
The scenario that we are facing, is that business finds out a new requirement, which wants a different field in either the email or pdf, then the solution we currently have is to add that to the creation of a delivery, and that's where the "problem" begins.
new field is based on something that we already have an id from. So in this case, let's say, that we have the customer Id, but we also need the customer name, so an option would be to with the
customerId that I already have, request the
customer service, for that particular customer, which would give me the
customer name, or any other additional relevant to the customer that I would need in the future. This keeps the change local to where it's going to be used
The "problem" with this approach, since we use
microservice, is that this request is an http call, therefore, we have
tight coupling because what if your service is down problem?
With that in mind, how would you go about that? Keep adding more and more fields in the first request when creating a delivery, and running migration for the case of old ones? What are the alternatives/best practices?