@pr0l0gix
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
@AnthonyPaulT
This video should have millions of views
@michaelslattery3050
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.
@matheusmurray2425
Just an amazing presentation! Thank you so much, Ian, for sharing knowledge.
@rorycawley
What a journey, thanks Ian - wonderfully done.
@reductor_
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.
@trozzonick77
One of the best on youtube. Very good.
@MattHanson-j1u
Very commendable presentation given it was held during an earthquake... Even the cameraman was holding it together (barely)
@alessandrob.g.4524
Man, what an amazing lecture!
@UNgineering
45:40 600-lines class? i've seen 2000-3000-lines classes routinely at some of the companies.
@julienl.1080
Thanks !
@bobert3335
The issue I see with this sort of architecture is with how the database is handled. Dependencies are supposed to flow inward to the entities, but the entities require the database for persistence. I don't see how "dependency inversion" solves this. Regardless of what terms you use, the entity layer cannot function without a database. That means the database is a dependency. In more practical terms, when writing tests for use-cases you have the problem that the database is modelled as an external component / "observable behavior" that should be included in the test. But that doesn't reflect reality. In practice you don't really care how the data is modelled internally as long as the use-cases work and are performant.
@emindeboer5280
got it .. after the first quarter 1/4
@TheDiveO
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.
@dawid_dahl
Thank you so much. 🙏🏻
@nguyentuananh4078
Can any body have the source code and slide of this talk. Please share.
@antonfernando8409
Cool, learned something.
@thigmotrope
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
@brendonanderson8673
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.
@rorycawley