Robert C Martin - Clean Architecture and Design

preview_player
Показать описание

Рекомендации по теме
Комментарии
Автор

=== Preamble ===
00:05 Begins talk with discussion of physics. Mass, speed, Einstein, and relativity.
06:00 Mass is relative to some other thing. How can it be relative? Mass must not be what we think it is.

=== Talk Topic ===
07:40 The genesis of this talk was 3-4 years ago. Why is project structure telling me how it's made? Why doesn't it tell me what it does?
08:55 The web is a detail -- an IO channel. Why would it then dictate the structure of our app?
10:23 Architecture is about intent.
11:38 Ivar Jacobson: "Use Cases drive architecture." A use case is a description of an action that a user will perform on a system, how the system processes that action, and what data is returned by the system. Notice that the use case is independent of the web.
14:50 You can put use cases into an object.
15:35 Interactors use command pattern and with 'execute()' method. Interactors have application specific business rules.
16:16 There are two kinds of business rules and you must keep them separate. 1) Particular to the app being executed. 2) The other kind can be in many apps.
17:10 Where do we put these second, lower level business rules? In the Entity object. The Interactor tells the Entity what to do.
17:56 Boundary object. These are interfaces.
28:25 An Overview: How should this work?
33:35 MVC was originally much simpler and smaller. Nowadays MVC has become much more complicated and loses defined boundaries.
36:49 How do we do it in clean architecture? Model-View-Presenter example.
39:40 A pattern is developing. It's the component boundary. Across that black line, all dependencies must point inward towards the application.
41:42 Here's what the whole thing looks like without the entities.
44:16 The reason we have databases is historical. But they're becoming obsolete. The database is a detail and it needs to be treated like a plugin.
56:00 Think of your app as a group of Use Cases that describe the intent of the app and then a group of plugins that give those Use Cases access to the outside world.
56:30 Good architecture allows you to defer decisions to later.
56:50 A good architect maximizes the number of deferred decisions.

AlexandriaRohn
Автор

This is probably the best presentation about clean architecture on youtube.

matheusdallrosa
Автор

10 years after, and still such a good concept

Valo_iO
Автор

Very nice talk from Uncle Bob.

My take away:

1. Most important parts of software architecture are: Interactor, Entity, Boundary

2. Good architecture reveals intent and helps to defer design decision

3. Make your software the sultan and the frameworks and databases the harem. Harems are plugins.

ReflectionOcean
Автор

11:45 - Listening to UB talk about how horrible the time of Use Cases was, I really don't see much difference between that and what some clients do with User Stories.

AggieEric
Автор

So many echoes to my very early career in 2001 and to the architecture issues I encounter on a daily basis nowadays ...

zofrenlepetitkopat
Автор

Another great talk by Uncle Bob. BTW, Einstein's special relativity paper was more like 30 pages not 5 or 7...

iconjack
Автор

Save 15min of your life and watch this at 1.25 speed (:
Still totally understandable

navarrolaerth
Автор

Probably we'll se more about it in the upcoming book "Clean Architecture"

mikasa
Автор

Everything is a detail. Life is a detail

iiinjoy
Автор

Great talk ! i always thought that components architecture makes more sense !

naimal
Автор

"Use the framework. Don't merry it."

mrAtari
Автор

Interactors seem very similar to Evans AGGREGATE ROOT/ANTI-CORRUPTION LAYER. Entity Gateway Interface seems analogous to REPOSITORY. Are there substantial differences? Would it help the industry to converge to a common language (like design patterns) for these higher level architectural patterns?

leadvisionary
Автор

1.5* speed - all the understanding, none of the frustration lol

nstyle
Автор

30.43 the result model in the interactor ( data coming back to delivery mechanism) changes to request model at delivery mechanism. I assume this is a typo on the diagram.

utubeify
Автор

Excellent talk! I wonder where I can view a copy of these slides

Reliant
Автор

45:06 : Terrabytes! Terrabytes! lol. And then the witch cackle! This is what spices up a software architecture presentation: 45:29 :-)

another.worlder
Автор

Mass relative, and energy is relative. However, not as described. We have a rest mass, and that is what we use in E=mc^2, which by the way is only valid at rest. That is, when the measured object is not moving respect to the observer. If you want to talk me about a moving object, you need the full equation: E^2 = (pc)^ + (mc^2)^2 where p is the momentum and m is the mass at rest. Edit: and all that without mentioning that mass is not weight.

Theraot
Автор

Can anyone recommend what I should search for in terms of learning more about storing transactions rather than state? I'm reminded of another talk describing how Photoshop doesn't store state but rather a great big reversible `std::vector` of interactions...

RoamingAdhocrat
Автор

Theophrastus classified magnetite (magnatic attraction) and ambar (electric attraction) together. The next link was discovering that electric discharges (such as those from electrostatic generator) can make a compass move. So the idea of some link was quite old. We just had no idea what could it be.

The Ether was not a new idea when the link between electricity and magnetism. The idea was already there as an attempt to explain light, which was considered a wave since Newton.

Finally, that the speed of light did not change regardless of the frame of reference was discovered experimentally. Einstein did not come up with the idea.

Theraot