Timeline for Separation of concerns SOAP Services
Current License: CC BY-SA 4.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 19, 2018 at 14:34 | vote | accept | CodeHacker | ||
| Oct 19, 2018 at 14:15 | comment | added | StarTrekRedneck | I think you've got a good portion of the issue solved, then. I would still go for the separate service to encapsulate the logic about reacting to certain Enrollment events. Embedding the logic to handle the events within the Enrollment service would probably bloat it. It sounds like it's doing plenty and it sounds like you sense that. Also, it may be that a couple events (or more and in any order) may have to happen to warrant a notification, and a separate service will provide liberty to maneuver in that manner. | |
| Oct 19, 2018 at 14:02 | comment | added | CodeHacker | Hello. Thanks for the thoughts- Our Email service is exactly for that.. Handling Email errors.. retrying. informing responsible people if errors occurred, etc.. That is why we never send form any service nor app an email directly... it is our policy to send it through the service. The idea of a pub/sub is really worth a thought. Right now, if the email fails, my App doesn't care... because I now the service has all information needed to inform the responsible people. (we have to register that be able to instantiate an instance of the service | |
| Oct 19, 2018 at 13:35 | review | First posts | |||
| Oct 23, 2018 at 21:52 | |||||
| Oct 19, 2018 at 13:32 | history | answered | StarTrekRedneck | CC BY-SA 4.0 |