I'm still going to read the book, but I have read posts about clean architecture and an excellent talk about it given by Brandon Rhodes. I will try to work with what I have.
We, as programmers, tend to hide I/O calls (database operations, api calls etc) in subroutines. The I/O call is hidden from us and anyone using our code. The thing is: we usually hide it but do not decouple it. You can't do the required task without making an I/O call. The I/O call is still an inevitable consequence of doing the task. This is bad for testing and for getting cached results. What the clean architecture does is the opposite: make the I/O call explicitly in the routine and work with the data in subroutines as pure functions (functions that return data just based on what was given as arguments and do not change any data outside of it). This makes testing and refactoring (in case the I/O call have to change after a version update for example) much easier.
I think there is no fast way to understand this, so I recommend the talk I linked before. It is an ELI5, but a long one :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'm still going to read the book, but I have read posts about clean architecture and an excellent talk about it given by Brandon Rhodes. I will try to work with what I have.
We, as programmers, tend to hide I/O calls (database operations, api calls etc) in subroutines. The I/O call is hidden from us and anyone using our code. The thing is: we usually hide it but do not decouple it. You can't do the required task without making an I/O call. The I/O call is still an inevitable consequence of doing the task. This is bad for testing and for getting cached results. What the clean architecture does is the opposite: make the I/O call explicitly in the routine and work with the data in subroutines as pure functions (functions that return data just based on what was given as arguments and do not change any data outside of it). This makes testing and refactoring (in case the I/O call have to change after a version update for example) much easier.
I think there is no fast way to understand this, so I recommend the talk I linked before. It is an ELI5, but a long one :)