Service Design
I have 3 services that im trying to figure out how they should interact at a DI level.
1) a scheduling service that fires an event at a given time. this event is of predetermined types (Reminder, Send a message, etc).
2) an approval system for communications. User1 creates a communication, user2,user3,user4 vote to approve/deny/modify the communication.
3) a notification (sending) service that transmits the communication/ releases it to other users to view.
the most basic flow would be Api call to submit the communication=> Approval service (wait for approvals) => Schedule Service (after approved, when should this happen) => Sending Service (when the schedule trigger fires off).
how do i resolve the dependency injection for the various services? Does the Sending service only require the Schedule service, which in turn only requires the Approval service?
and what is the best manner to chain these together, or am i better off redesigning in a different schema?
In the current design i am running the Scheduling Service as a singleton, the approval service is likely scoped, and the sending service should be transient right? this raises the issue that the approval service cannot access the Scheduling service through DI because of the longer lifecycle. Looking for any advice on if im off base here.
TIA!
5 Replies
Wouldn't your sending service basically be the standalone service which does not reference any business logic related service?
you may be right with that. so singleton service for the sender, singleton for the scheduler, and scoped for the approval service? Inject the sending service into the Scheduler and when the Scheduled item fires off its event, push it through the sending service. Am i understanding your comment correctly?
From what I can tell I'd definitely put the notification sender at the edge, as a way to translate from business logic to an external output.
I think for the scheduling, you can then think about whether it should reference the approval system or work through some kind of event, decoupling both of them (implying they are not 100% tied together).
On a quick glance, I feel like the dependency chain might be
Scheduling service -- triggers --> approval system --broadcasts--> notification sending
the business logic throws the approval prior to the scheduling service. which shouldnt make much of a difference right, just approve the item to be transmitted, then schedule it, the approval system is scoped so should be able to access singleton instances thru DI right?
the the injection would be approval -> schedule --triggers -> notification?
at which point the Notification service is just a background consumer off a Channel
the approval system is scoped so should be able to access singleton instances thru DI right?yes