Timeline for Avoid too much dependencies for a Use Case in a Clean Architecture app
Current License: CC BY-SA 4.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 18, 2019 at 18:26 | audit | Suggested edits | |||
| Jul 18, 2019 at 20:01 | |||||
| Jun 27, 2019 at 15:08 | vote | accept | Rafi Panoyan | ||
| Jun 27, 2019 at 14:36 | comment | added | Rafi Panoyan |
Maybe you're right. Right now the Use Case manipulate these concepts via interfaces. What would the service you're talking about look like in this case ? I'm afraid about just moving some work at another level (service), then having nothing to do inside the UC but calling the newly created service.
|
|
| Jun 27, 2019 at 13:01 | comment | added | Laiv |
UseCase is totally agnostic to concepts like Session or Sending an Email if... or Program event. These things happen in different layers due to different reasons. Are not you, maybe, missing a service layer where to orchestrate whatever happens after the use case? Or a system of callbacks, error handling, etc.
|
|
| Jun 27, 2019 at 12:19 | answer | added | VoiceOfUnreason | timeline score: 1 | |
| Jun 27, 2019 at 8:41 | history | asked | Rafi Panoyan | CC BY-SA 4.0 |