Robert C Martin - Clean Architecture

[loicyvonnet]

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.

[danthi]

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

[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.

[kanstantsin-bucha]

It is still straight to the point, in 2023

[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.

[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.

[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!!!

[Yetipfote]

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

[ngocthanhao]

thanks you so much about this amazing talks :D

[clarkflavor]

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.

[budi]

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 YouTube, 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?

[BryonLape]

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

[quinnjones]

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!?!

[rogerioliesenfeld]

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).