Robert C Martin - Clean Architecture

[@kanstantsin-bucha]

It is still straight to the point, in 2023

[@faustofl]

Impressive to me, how some kind of information have only 457 likes since 2014. It's still a guidance for development. I see many software "engineers" that don't have these concepts.

[@dan2thi]

This is my first time listening to Robert Martin. Very impressive!

[@loicyvonnet2150]

Thanks for this talk. IMHO, the key points are: - Center software architecture on use cases. - A good architecture scheme (at least, a high level one) should tell about what the system does/provides. It should not focus on tools and frameworks. These are implementation details. - A good architecture promotes a clear separation between core business objects, and the delivery mechanism on one side, and the persistence layer on the other side. Robert C. Martin describes a solution to enforce this separation. - A good architecture enables to defer decisions for as long as possible; in particular, decisions about tools and frameworks. - DNA as a Turing machine, which is an interesting consideration. In a system based on a microservices approach, I think that any microservice could follow this approach internally.

[@DanielRamBeats]

+Loïc Yvonnet that last point is a keeper for sure. I also took away the idea of abstraction of your application away from it's tools. One class to that will call an API specific class that handles interacting with the tool. I am confused on Entity however.

[@DanielRamBeats]

I always enjoy hearing the opening of his talks haha

[@DanielRamBeats]

This was a very enlightening talk. I wish the full UML diagrams were available for DL. Really changes the way you think of application design.

[@GlebKuzntesov]

I love that guy!

[@ngocthanhao1678]

thanks you so much about this amazing talks :D

[@SrikarDurgi]

This is profound.

[@fiancheg]

TLDR. Do interaction with interface/api/etc over an interface so it’s decoupled and you are able to change your delivery mechanism in future, from thick client to web api for example. Additional bonus is you’re now able to decouple them and test separately. Same with a DB. Don’t build your app around it, create an interface and use DB as it’s a plugin for your app. Same bonus - ability to unplug and test separately.

[@Yetipfote]

13:19 btw everybody should have a folder called "Angela's Documents" at the root level

[@MatheusAugustoGames]

It's my 'new project' template!

[@frontendbrasil]

I really like the idea of deferring decisions as a way to build loosely coupled systems that can be delivered to x number of mediums - that's a fantastic advice. And so, thank you Robert C. Martin! However... - The way users interacts with the system is as important as the use cases (who wants an ugly, non user-friendly UI); - The way data is stored is also as important (How valuable is a data if a company can't do analytics on it) I'm not trying to say I disagree with Robert, far from that. All I'm trying to say is that the "plugins" are not to be left to the side as if they are less important. Great presentation!!!

[@biokode]

Does he always start his talks with something science related? I've now seen 4 of them, and they all started like this. Anyone know why? Not hating. Just curious.

[@JohnLudlow]

+Marius Haugan I saw the whole collection of his clean code videos. They all started with an astronomy fact.I think it's just a way to bring his audience in that breaks the usual structure of a talk, and (in theory) makes his audience more engaged.

[@Yetipfote]

@@JohnLudlow works for me :)

[@pyroghost11]

Probably that is where he derives his ideas from for software

[@MatheusAugustoGames]

@@JohnLudlow I'm not sure of it, but some of his 'science random facts' don't seem so random. I've been looking for subtexts that relate the tangents to the material presented; so far I haven't found any, but I intuit there may be some.

[@JohnLudlow]

@@MatheusAugustoGames I think there's often a subtle link to the topic

[@budi0580]

It would be better if provide with code example, not just a diagram.

[@PedroECunhaBrigatto]

I've read the book, watched to some of his speeches here in KZbin, but one question remains unanswered ... the main diagram in the book, for example, shows arrows going from the outer to the inner circle (frameworks & drivers, interface adapters, application business logic, entities), but one by one (adjacent circles in touch, but only this). Than he comes saying that the communication between Use Cases ('app business' logic circle) relate to the database and data access components, which are clearly (by definition in the book) part of the Frameworks & Drivers. So, the arrows in the diagram say something, but not all of it, and the text also doesn't make it clear ... my impression is that, in this architecture, the point is: you always go from outer to inner, but it doesn't mean you can't 'jump' circles. If it is coming from outer to inner, it is fine. This is, to me, reinforced when I see Bob saying that the data mappers (ORM, in the Frameworks & Drivers circle) map from entities to DTO's (he doesn't say DTO, but something that is familiar to the database, which is basically the same) and vice-versa. So, again, we'd have components in the 'Frameworks & Drivers' depending directly on the 'Entities' circle. Do you have the same understanding?

[@MonsieurCHING]

55:45 then how come his tests running at 30:20 lasted 1m46s?

[@david52875]

MonsieurCHING Propably because he was running integration tests

[@Yetipfote]

he said some tests needed to access files. If everything was in memory it was probably much faster.

[@MonsieurCHING]

@@Yetipfote ty

[@timgreenhoot5849]

Design vs architecture

[@BryonLape]

4:40 - to skip Uncle Bob's interesting, but useless opening.

[@quinnjones1221]

You totally missed the point of his opening...biological systems are like programs so what can we learn from hundreds of millions of years of biology and apply that to programming? Have you had Bob for any classes or seen him live...then you would appreciate his methods.

[@JamieTwells]

Bryon Lape thanks!

[@quinnjones1221]

The question I have Bob...why arent we working with Space X to get people to Mars?

[@yodaearth]

This is strange. Content aside, he sounds drunk to my ears!?!

[@rogerioliesenfeld9042]

Too much time just posturing and saying nothing of substance... He complains (around 11:00min in the video) about Ruby on Rails, that it dictates the directory structure of your application... sure, of course, but so what? Don't use Rails code generator then (which sucks, I agree). Then (around 20:00) it talks some nonsense about architecture being a way to defer/postpone important decisions (related to databases, frameworks, persistence schemes - stuff that you actually want to decide early on, not later) - apparently motivated by a desire to write automated tests more easily, which is fine, but does not require deferring such choices (speaking from experience as someone who writes and runs such tests every day). So, only at around 40:00 (in a 57 minutes long video) he starts talking about the actual "Clean" architecture, EBI. Unfortunately, he never discusses how the UI would actually be implemented - possibly in some MVC way; but if you know web stuff, you'll see this doesn't make such sense, when thinking about a JSF/Primefaces or JSP frontend, or an Angular/ReactJS frontend, or a PHP or Rails frontend (for example, in a JSF-based app, the JSF backing classes would *be* the Application Services from DDD or the Interactors from EBI). In the end, it appears there are no layers at all in Clean Architecture, just a Big Ball of Mud containing Entities and their Entity Gateways, and the Interactors. Personally, I prefer DDD (Domain Driven Design), with its four layers (UI -> Application -> Domain -> Infrastructure), and its core Domain Model concepts (Entity, Value Object, Factory, Domain Service, Repository).