@AlexandriaRohn

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

@Valo_iO

10 years after, and still such a good concept

@matheusdallrosa4698

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

@ReflectionOcean

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.

@AggieEric97

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.

@zofrenlepetitkopat2979

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

@acidFreak420

Really an excellent talk.

@mikasa1641

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

@Theraot

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.

@naimal5184

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

@iiinjoy

Everything is a detail. Life is a detail

@iconjack

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

@mguven

inspirational!

@cesardmora86

I love Martin's intros

@navarrolaerth1662

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

@leadvisionary8174

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?

@Theraot

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.

@utube999ify

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.

@RoamingAdhocrat

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

@another.worlder

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