this is the best talk on clean architecture. I hv been trying to gather more Clean Architecture. Went thru few on NDC Conf, Goto, Steve Smith and others. They r good. However, this is the real deal with covers everything. I really appreciate the effort coz every sentence is essential. I loved when presenter said do we cover use cases using code and is it visible to devs. Thanks you for this
The trouble I always find with code samples like at the end in talks like these is, that for those small demo's the original is in many cases easier to work with and understand, it's only when you get into a much larger system that it gets more useful. Unfortunately many people just see that end bit and say well it just shows this approach is not good. I'm not saying I do that, I actually believe a layered approach is the best way to go, however I know many people that think it's awful, and I think the samples they see are awful which doesn't help.
In reality, the world is much more complex. Business people tells developers to add their (unorganized) ideas and change requirements any second. Developers don't have political power to make code clean. They struggle to meet deadlines, non-devs don't read the code and don't give time to resolve tech debts. New devs join the company and complain that code is dirty. This happens like 99% percent of time. The people who preach scrum, tdd, clean architecture, etc. are coaches who make money by lecturing. They make money by telling developers that they are doing everything wrong as if they are some kind of authority.
@@sea0920in reality more people then coaches preach those things, I infact preach many of them because over the years I have seen success using them. If devs aren't empowered within your organisation I would say quit and move else where, while business people come down with requirements devs define how the code works and looks, devs should feel empowered to push back against requirements. Sure a junior might struggle to feel empowered, but senior and principal devs should be able to influence and drive technical direction.
This is the best description of clean/hex that I've found. I'm glad he touches on testing and explains to primarily test input ports. I am not sure it's right to say controllers are interactors. The problem is that some controllers are bound to frameworks. I think it's more accurate to say that controllers should be thin pass-through objects that relay UI data directly to/from the interactors. That the interactor are the control logic and controllers are the adaptors.
It's not really correct to have a infra dependency in the domain layer. If it is for domain events than it should probably move to a shared kernel layer.
do you mind sharing any articles or books where i can learn more about this? Or if you know any really good videos, really trying to get my head around software architecture atm
@@NoOne-ev3jn do you mind sharing any articles or books where i can learn more about this? Or if you know any really good videos, really trying to get my head around software architecture atm
That camera is in need of a clean architecture. Thankfully the cam didn't attempt to give a fuller picture of the presenters nose openings, like a Python cam.
I can't imagine trying to explain all these abstractions to junior devs and maintaining any kind of long term fidelity to it. No doubt it would become an unmitigated mess. And senior devs would just argue about it. Of course not doing this results in an unmitigated mess as well so I don't know. I guess I'd prefer my messes with fewer abstractions
I doesn't have to be the extremes - either not structure or the complete full blown structure (shown in the presentation). Be pragmatic and use what helps and avoid the rest. If you want to see a pragmatic example in java, checkout the coding kata from Sandro Mancusos that you can find here ruclips.net/video/XHnuMjah6ps/видео.html (this the first of three parts).
Having worked with this in large codebases I can say with confidence: it's nice in theory but awful in practice. The devil is in the details and people will abuse "interactors" in every possible way. Soon you'll have one interactor calling 5 other interactors which in turn call other interactors and in the end all you have is a procedural nightmare. Unless you're strict about everything under this architecture, it will surely make your code unnecessarily complex with very little benefit. Be very careful with this.
![BLACK BAG - Official Trailer [HD] - Only in Theaters March 14](http://i.ytimg.com/vi/Du0Xp8WX_7I/mqdefault.jpg)
There are few like Ian who can make everything so clear. Got to see him in NDC Porto 2023. Always excellent.
this is the best talk on clean architecture. I hv been trying to gather more Clean Architecture. Went thru few on NDC Conf, Goto, Steve Smith and others. They r good. However, this is the real deal with covers everything. I really appreciate the effort coz every sentence is essential. I loved when presenter said do we cover use cases using code and is it visible to devs. Thanks you for this
This video should have millions of views
The trouble I always find with code samples like at the end in talks like these is, that for those small demo's the original is in many cases easier to work with and understand, it's only when you get into a much larger system that it gets more useful.
Unfortunately many people just see that end bit and say well it just shows this approach is not good. I'm not saying I do that, I actually believe a layered approach is the best way to go, however I know many people that think it's awful, and I think the samples they see are awful which doesn't help.
There is that saying about standing on the shoulders of giants and developers are stepping on their own toes.
In reality, the world is much more complex. Business people tells developers to add their (unorganized) ideas and change requirements any second. Developers don't have political power to make code clean. They struggle to meet deadlines, non-devs don't read the code and don't give time to resolve tech debts. New devs join the company and complain that code is dirty. This happens like 99% percent of time. The people who preach scrum, tdd, clean architecture, etc. are coaches who make money by lecturing. They make money by telling developers that they are doing everything wrong as if they are some kind of authority.
@@sea0920in reality more people then coaches preach those things, I infact preach many of them because over the years I have seen success using them.
If devs aren't empowered within your organisation I would say quit and move else where, while business people come down with requirements devs define how the code works and looks, devs should feel empowered to push back against requirements.
Sure a junior might struggle to feel empowered, but senior and principal devs should be able to influence and drive technical direction.
Just an amazing presentation! Thank you so much, Ian, for sharing knowledge.
I found it really useful, third time listening to it.
What a journey, thanks Ian - wonderfully done.
This is the best description of clean/hex that I've found. I'm glad he touches on testing and explains to primarily test input ports.
I am not sure it's right to say controllers are interactors. The problem is that some controllers are bound to frameworks. I think it's more accurate to say that controllers should be thin pass-through objects that relay UI data directly to/from the interactors. That the interactor are the control logic and controllers are the adaptors.
One of the best on youtube. Very good.
Man, what an amazing lecture!
Thanks !
Can any body have the source code and slide of this talk. Please share.
Managed to find it. Just go through the branches github.com/iancooper/CA-Tutorial
Very commendable presentation given it was held during an earthquake... Even the cameraman was holding it together (barely)
It's not really correct to have a infra dependency in the domain layer. If it is for domain events than it should probably move to a shared kernel layer.
When I saw that shame I immediately stopped the video, I won’t waste the rest of the time
do you mind sharing any articles or books where i can learn more about this? Or if you know any really good videos, really trying to get my head around software architecture atm
@@NoOne-ev3jn do you mind sharing any articles or books where i can learn more about this? Or if you know any really good videos, really trying to get my head around software architecture atm
thank you both ))))
Thank you so much. 🙏🏻
Very helpful. Can i have the slide?
All of his presentations can be found here github.com/iancooper/Presentations
Cool, learned something.
Why is Clean Arch so popular among the C# community but not in the Java?
I'm wondering that too.
I think it might be connected to the fact that c# is used for creating games.
Games are performance hungry
That camera is in need of a clean architecture. Thankfully the cam didn't attempt to give a fuller picture of the presenters nose openings, like a Python cam.
got it .. after the first quarter 1/4
I can't imagine trying to explain all these abstractions to junior devs and maintaining any kind of long term fidelity to it. No doubt it would become an unmitigated mess. And senior devs would just argue about it. Of course not doing this results in an unmitigated mess as well so I don't know. I guess I'd prefer my messes with fewer abstractions
I doesn't have to be the extremes - either not structure or the complete full blown structure (shown in the presentation). Be pragmatic and use what helps and avoid the rest.
If you want to see a pragmatic example in java, checkout the coding kata from Sandro Mancusos that you can find here ruclips.net/video/XHnuMjah6ps/видео.html (this the first of three parts).
That camera work is worse than VR.
I’m feeling woozy
The camera person and speaker exhibit signs of intoxication.
Wtf is going on with that camera
Didn't expect the pope to talk about pregnancy, but here we go...
"600 line service classes" - I would much rather read through a (cohesive) single 600 line class, than six abstracted 100 line classes
Having worked with this in large codebases I can say with confidence: it's nice in theory but awful in practice.
The devil is in the details and people will abuse "interactors" in every possible way. Soon you'll have one interactor calling 5 other interactors which in turn call other interactors and in the end all you have is a procedural nightmare.
Unless you're strict about everything under this architecture, it will surely make your code unnecessarily complex with very little benefit. Be very careful with this.
Weird accent. Poor delivery. Really bad session on Clean Arch.
Would love to hear yours.
I thought it was really good.
"weird accent"? really?
I thought it was good... maybe your just slow in the head😂 your Native American name shall be “dropped on head” 😂
@@danwilson5630 pepepee pooopoopo ... how did I do ?