Timeline for Avoid too much dependencies for a Use Case in a Clean Architecture app
Current License: CC BY-SA 4.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 27, 2019 at 15:08 | vote | accept | Rafi Panoyan | ||
| Jun 27, 2019 at 14:56 | comment | added | VoiceOfUnreason | "the circles are schematic. You may find that you need more than just these four. There’s no rule that says you must always have just these four. However, The Dependency Rule always applies. Source code dependencies always point inwards." | |
| Jun 27, 2019 at 14:12 | comment | added | Rafi Panoyan | Exactly, following the Clean Architecture principles (blog.cleancoder.com/uncle-bob/2012/08/13/…), Use Case is application layer, and Entity is business layer. If I understand your comment @Laiv, I can keep this side effects' flow in the Use Case (app layer) and create an Entity which will only validate the answer (pure function, no mocks). | |
| Jun 27, 2019 at 13:37 | history | edited | VoiceOfUnreason | CC BY-SA 4.0 |
added 166 characters in body
|
| Jun 27, 2019 at 13:32 | comment | added | Laiv | everything involves too many things. "Answering a question" has nothing to do with sending an email if X or publishing an event if Y or updating a session of Z. Session, emails, logs, notifications can be executed as business side-effects instead of forcing them explicitly from the business itself. The business layers is not the application, the application is built upon the business. | |
| Jun 27, 2019 at 12:48 | comment | added | Rafi Panoyan | If I understand, you wouldn't consider the protocol as application specific business rules ? My understanding about the Use Cases (application business rules) was that everything that had to be done for a particular use case is part of that, including the flow of data, since this flow must always be the same application-wise for this use case. | |
| Jun 27, 2019 at 12:19 | history | answered | VoiceOfUnreason | CC BY-SA 4.0 |