=== 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.
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.
Tony Zhou "Most important parts of software architecture are: Interactor, Entity, Boundary" No, that is the implementation of the design of the use case. All use cases have those, therefore if you put those directories as the main directories, all applications will look the same... and that's exactly what uncle Bob is complaininig about. What he means is this: project chromium +---- module display +----- use case open browser +----- use case close browser +----- use case open URL +---- module tab management +----- use case open new tab +----- use case close tab +----- use case move tab +---- module html rederer +----- use case render html +---- module http connector +----- use case connect to URL +----- use case get HTML +----- use case download file
Tony Zhou not at the level of having each use case in a separate folder... and god knows I've tried... The problem: there are 2 levels of use case: business level use case and user level use case. The business level level use case has the companies, clients and providers as actors, while the user level use cases have users as actors and they can be grouped to implement the business level use cases. For the sake of simplification let us suppose that you use Vaadin, that is a Swing for the web,so everything is tidy and written in Java. You have several components written in Vaadin. Using Uncle Bob's MVC notation a Vaadin component class is both the VC and the POJO holding the data would be the M. Then when you say for example: "account withdrawal" that clearly is a use case at the user level, because there is a user at the web page, looking at his account balance, and say he wants to pay a bill or transfer money to a friend of his (so account withdrawal gets divided into 2 use cases, since his computer cannot deliver or print money, but conceptually it is a withdrawal anyway). Soooo... you create 2 Vaadin components: PayBill and TransferMoney... Vaadin components are way inward classes, at least in Java... pom.xml src --> here all your use cases would go classes and the use cases, being Vaadin classes, would be in a presentation folder... next to other components like buttons and the like... You can group them together inside com.bank.project.presentation.vaadin.component.usecase package ... But is is weird, isn't it? You have to dig them. So in a way, yes, Uncle Bob is right, use cases should be on the top, specially business use cases, but I cannot modify so much the structure of my projects as to make a directory with every use case. Besides the M, the POJOS, they get shuffled around by the VCs, so since every use case is a VC, if I make a directory for every VC Vaadin class, I'm pretty sure the POJOS should go in a totally different directory, apart from the VC that use them. This seems like Eric Evans Domain Driven Design. Which BTW Uncle Bob also advocates, so maybe we are thinking exactly the same and I just realized. Uncle Bob wants us to code all the project in DDD,using only Java classes and no web whatsoever. So all use cases should be implemented in DDD style. This would mean that Vaadin is solely a display technology. The details are hard to imagine, because how do you represent in text an account balance or an account withdrawal, without a user interface? Programming both a text UI and a web UI would be a waste of time. And the number of bugs staggering. OTOH if there is no text UI, just test cases, it might work. Because all that Vaadin needs is stable interfaces, and clearly those unit tests would allow for very stable interfaces... once all the use cases are finished of course... I had not realized this before.. Then plug in Vaadin or whatever display technology is required, hopefully, on the fly. That sounds to me like MDD: Model Driven Design. Where the system reads the model and plugs in whatever display technology is required. I mean, yes I could create a directory, and then symbolic link to all the sources... that might make sense... but since everyone uses an IDE like Eclipse, I think it would be much simpler if Eclipse handled use cases for me like an abstract concept so that all sources are somehow linked to the use case. At least I would expect it to be this way.
8 ปีที่แล้ว +1
+Tony Zhou One correction IMHO: Good architecture reveals intent and helps to defer *implementation* decision.Software architecture is itself the design, it cannot defer design decisions. But can (and shall) defer decision on HOW to implement that design: what tech to use for persistence, what programming language to use etc.
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.
Perhaps what was important to UB was the difference in how the Use Case paper contained implementation details that simply would not exist when a "User" writes a story (think BDD). That influence over how the code should / will be written embedded in the Use Case paper is undesirable.
Everything is concrete... with detailed implementation provided by the universe... yet we are not modelling the universe in object orientation... we are trying to manage a simulation of it, this simulation has constraints due to hardware limitation, nature of problem etc. So details are only needed upto an appropriate level. We are trying to keep our simulation extensible for future change, so keeping the details as far away from the domain of our simulation is what clean architecture and oop are about. Hope that made sense.
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.
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.
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?
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.
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...
This is classic uncle Bob kudos!!!. I have few questions, Thanks in advance :). Should interactor communicate with entity gateway using Entity model or business model? What if the team decides to migrate from SQL to NoSQL, this time the entity model itself might change. How can we design the system in a way that we can flip the database anytime without affecting the interactor/use case layer much? I think if the entity model comes inside the use case layer it might be tricky to make changes fast.
for example create a customer is a use case, Boundary interface declares createCustomer(); interactor implements boundary interface so it has to implement createCustomer(); Entity is a customer class interactor uses customer class and it’s methods to create new customer object (at the least customer constructor only). Changing database think in terms of doors each boundary interface is a door to another service or components. you decide what functions you would need from database and declare them in an interface. A da access class implements that interface and provide the desired functionality by implementing those methods. Your application only knows about the functions inside the interface that you provided nothing about the implementation so whenever you want to change a DB just implement the interface using a new DB. Example - you write an interface with saveCustomer(); you write a class dbAccess that implements the interface hence the method saveCustomer(){ implementation goes here with your choice of database} Whenever you need to change the database just implement the DB interface and remove old implementation. Further readings - adapter pattern, indirection
That part about not sensing the speed while in a ship cabin, needs an other more condition to be true: speed of the ship must be still (not changing) through the time! otherwise you can feel the force of your sit, or you will اول سخنرانی، اونجایی که درباره این صحبت میکنه که سرنشین کشتی، که توی یه اتفاق بدون پنجره و ... نشسته، نمیتونه حرکت رو بفهمه، فقط وقتی درسته که شتاب نداشته باشیم!
Any one else get the feeling that if IT architects built buildings, we'd all be living on groups of tiny rafts, tied together, floating around on some lake? Life wouldn't necessarily be simpler.
That's simply because the analogy is wrong (and your joke just revealed it). In software, "architecture" and "design" means something different from what the city building architect might think of. That's why some people prefer using analogy from gardening instead of buildings architecture, that is, software engineers "nurturing" their products, not "building" them.
06:00 Mass is not relative, weight is. W = mg, where W is weight, m is the mass (constant for any body anywhere) and g is gravitational pull. (For Earth it is 9.8m/s^2).
No. The point is to make you think he knows what he talks about so you (as a clueless business man) hand over your money to him in exchange for him applying his infinite wisdom to provide you technical solutions to your business problems.
Ivar Jacobsen's book was very influential, and many systems were built that embodied these ideas. For a time programming in the large seemed rational and understandable. Then the dodgey dogpile of chicanery called web 2.0 happened.
Hey Bob ! @05:57 MASS is not same as WEIGHT. You do not 'mass' 50 kilos - but you may weigh 50 kilos. Your weight (and anybody else's) depends on environmental bodies. The weight is a force of attraction between any 2 masses. But MASS as far as I know would probably be an absolute - although I concede that it may vary depending on temperature (ENERGY). The cooler it gets the more MASS will contract (shrink) and at absolute 0 Kelvin it is supposed to even disappear. No energy => no mass. MASS and ENERGY are related with Einstein famous equation, but not WEIGHT though, this remains in the scope of Classical Physics. ALSO What's the mathematics of absolutes and relative ? absolute = absolute * absolute ? relative = relative * relative ? relative = absolute * relative ? could this work out ? Maybe this is a senseless mathematics as ABSOLUTES in the physical universe are UNATAINABLE. So Einstein might have been correct: EVERYTHING IS RELATIVE. :)
Mass is relative, it depends on the frame of reference. By convention we talk about rest mass (that is mass of an object that is not moving respect to your frame of reference). In E=mc^2, that is rest mass. Ah, and that energy? That is total energy. So, yes, termal energy affects it. However, not all of its energy is thermal, because thermal energy is only kinetic energy. Even if 0 kelvin can be reached, there would still be potential energy. absolute * relative = relative. Yes. We call absolute to something that does not change regardles of the frame of reference. As such, we consider the speed of light to be absolute.
In the old days, Java and C# was more similar. They have evolved in different directions since then. I would argue (and get shoutet at for doing so) that Java is taking inspiration from lisps, with its module system, lambda-the-ultimate pattern and more, and C# probably taking inspiration from good things from Delphi. But I'm not a C# developer, so I'm not going to die on that hill.
welldudethatsjustme you can choose what type of Main() you want, the console Main(), MVC Application_Start etc. Also it serves as a place to other plugins as DI and all other configuring stuff. Your APP is a Business layer, Presentation & Data access are just plugins (just the details) - that you should be able to change without changing any of your business logic.
He's right. If you have once created some data and of course saved it in the database, but never update it afterwards (or even delete), you will never meet the concurrency. Because the data is always there, never changes, never gets updated or deleted.
It’s all good but the only thing I don’t understand is if his time was so limited, then why did he waste first 8 minutes on talking about physics on topics completely irrelevant to the talk? Perhaps, if he got down to business from the very beginning then he wouldn’t need to skip the slides and maybe even have time to talk a little about TDD (giving that it was in his slides he probably had something interesting to say about it)
That is, indeed, what is written in the blue oval at 30:25; the result model which carry the result of the processing of the use case initiated by the user from the delivery mechanism.
He confuses mass and weight. Two different ideas. Mass is independent of location. Weight on the contrary. Mass is the quantity of resistance of a body to a change in its motion and is always the same unless the speed is comparable to that of light. Mass is expressed in kg, weight in Newtons.
19:50 "the implementors of java were lazy, they didn't like multiple inheritance so they preferred multiple implementation of interfaces". 1) Can you please elaborate? 2) Which language has multiple inheritance well implemented? AFAIK, only traits is the correct implementation of multiple inheritance (not mixins) and that can be done in Java without tweaking the language, it is just a little bit tricky Java code and it works like a charm.
+gmoschwarz 1) it's difficult to deal with the situations of multiple inheritance i guess such as methods with the same name / signature, that they instead just said, nah 2) within java 8 they KINDA have multiple inheritance - you can now have default implementations (that don't require private variables) of methods, so if you implement two different interfaces you can inherit the methods of both docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html
Common Lisp got it right, but they had you specify HOW you wanted the crashing implementations got to resolve their differences. And you almost never need it there. Like... ever. Then again, multimethods are delicious.
Agree, dictating intent is fine when it's two developers conceiving the app. Three years and 20 interns later, this pattern creates some absolutely horrible directory structure.
@@williamb1933 I work with 40+ developers on my team and we use Clean Architecture. Everything has been working great for a long time and everyone follows it. Use code review and CI tools to help your team catch any discrepancies in code being produced. Also, document your architecture and important things for newcomers to know on a wiki.
He often has interesting stuff to say, whether live, on video or through books - but my God can this man waste a developers time with nonsense. Do yourself a favor and skip over the first 6 minutes.
I loved that introductory speel - it grabbed my attention immediately, as I was wondering where he was going with it, then he left a big question in my mind while he moved onto the next topic. That is brilliant.
Wow, he thinks that SSDs work like RAM and that SQL only exists because disks are slow. His devotion to pure message passing is admirable but he takes it a bit too far.
Whats wrong with me..? But I just can't trust those it-elder-stars who tells me what is MVC is and how good Uncle Bob MVC new version is better.. I think those elders should give up and enjoy their grand children's.. " Who is doing DI? Whoo most of you doing it.." I think that all that more complex stuff like DI/AOP and etc just scares elders because their mind can't handle it anymore as it was already damaged by mainframes and as a result stupid simplification patters is what is left from them mixed with bad attitude on stage.
![กี่หมื่นฟ้า | Your Sky Series EP.1 [1/4]](http://i.ytimg.com/vi/vLGjxFL6U_I/mqdefault.jpg)
=== 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.
Thank you!
I'd buy you a coffee for providing a detailed list of timestamps. Thank you very much :)
This is probably the best presentation about clean architecture on youtube.
I will agree to that :) This video along greatly improved my programming skills
10 years after, and still such a good concept
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.
Tony Zhou "Most important parts of software architecture are: Interactor, Entity, Boundary"
No, that is the implementation of the design of the use case. All use cases have those, therefore if you put those directories as the main directories, all applications will look the same... and that's exactly what uncle Bob is complaininig about.
What he means is this:
project chromium
+---- module display
+----- use case open browser
+----- use case close browser
+----- use case open URL
+---- module tab management
+----- use case open new tab
+----- use case close tab
+----- use case move tab
+---- module html rederer
+----- use case render html
+---- module http connector
+----- use case connect to URL
+----- use case get HTML
+----- use case download file
You misunderstood my statement. Other than that, I agree with the rest of what you said. Nice illustration.
gmoschwarz by the way, do you know of an existing real project following clean architecture?
Tony Zhou not at the level of having each use case in a separate folder... and god knows I've tried...
The problem: there are 2 levels of use case: business level use case and user level use case. The business level level use case has the companies, clients and providers as actors, while the user level use cases have users as actors and they can be grouped to implement the business level use cases.
For the sake of simplification let us suppose that you use Vaadin, that is a Swing for the web,so everything is tidy and written in Java.
You have several components written in Vaadin. Using Uncle Bob's MVC notation a Vaadin component class is both the VC and the POJO holding the data would be the M.
Then when you say for example: "account withdrawal" that clearly is a use case at the user level, because there is a user at the web page, looking at his account balance, and say he wants to pay a bill or transfer money to a friend of his (so account withdrawal gets divided into 2 use cases, since his computer cannot deliver or print money, but conceptually it is a withdrawal anyway).
Soooo... you create 2 Vaadin components: PayBill and TransferMoney... Vaadin components are way inward classes, at least in Java...
pom.xml
src --> here all your use cases would go
classes
and the use cases, being Vaadin classes, would be in a presentation folder... next to other components like buttons and the like...
You can group them together inside com.bank.project.presentation.vaadin.component.usecase package ...
But is is weird, isn't it? You have to dig them.
So in a way, yes, Uncle Bob is right, use cases should be on the top, specially business use cases, but I cannot modify so much the structure of my projects as to make a directory with every use case.
Besides the M, the POJOS, they get shuffled around by the VCs, so since every use case is a VC, if I make a directory for every VC Vaadin class, I'm pretty sure the POJOS should go in a totally different directory, apart from the VC that use them.
This seems like Eric Evans Domain Driven Design. Which BTW Uncle Bob also advocates, so maybe we are thinking exactly the same and I just realized.
Uncle Bob wants us to code all the project in DDD,using only Java classes and no web whatsoever. So all use cases should be implemented in DDD style. This would mean that Vaadin is solely a display technology. The details are hard to imagine, because how do you represent in text an account balance or an account withdrawal, without a user interface?
Programming both a text UI and a web UI would be a waste of time. And the number of bugs staggering. OTOH if there is no text UI, just test cases, it might work. Because all that Vaadin needs is stable interfaces, and clearly those unit tests would allow for very stable interfaces... once all the use cases are finished of course... I had not realized this before..
Then plug in Vaadin or whatever display technology is required, hopefully, on the fly.
That sounds to me like MDD: Model Driven Design. Where the system reads the model and plugs in whatever display technology is required.
I mean, yes I could create a directory, and then symbolic link to all the sources... that might make sense... but since everyone uses an IDE like Eclipse, I think it would be much simpler if Eclipse handled use cases for me like an abstract concept so that all sources are somehow linked to the use case.
At least I would expect it to be this way.
+Tony Zhou One correction IMHO: Good architecture reveals intent and helps to defer *implementation* decision.Software architecture is itself the design, it cannot defer design decisions. But can (and shall) defer decision on HOW to implement that design: what tech to use for persistence, what programming language to use etc.
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.
Perhaps what was important to UB was the difference in how the Use Case paper contained implementation details that simply would not exist when a "User" writes a story (think BDD). That influence over how the code should / will be written embedded in the Use Case paper is undesirable.
So many echoes to my very early career in 2001 and to the architecture issues I encounter on a daily basis nowadays ...
Really an excellent talk.
Probably we'll se more about it in the upcoming book "Clean Architecture"
"Use the framework. Don't merry it."
marry*
Another great talk by Uncle Bob. BTW, Einstein's special relativity paper was more like 30 pages not 5 or 7...
The whole digression about physics of the first five minutes is so full of inaccuracies it's embarrassing.
Everything is a detail. Life is a detail
Everything is concrete... with detailed implementation provided by the universe... yet we are not modelling the universe in object orientation... we are trying to manage a simulation of it, this simulation has constraints due to hardware limitation, nature of problem etc. So details are only needed upto an appropriate level. We are trying to keep our simulation extensible for future change, so keeping the details as far away from the domain of our simulation is what clean architecture and oop are about. Hope that made sense.
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.
Great talk ! i always thought that components architecture makes more sense !
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.
inspirational!
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?
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.
I love Martin's intros
Save 15min of your life and watch this at 1.25 speed (:
Still totally understandable
+Navarro Laerth
After 3-rd watch I watch it on 2.00 speed :)
i watch at 3*10^8 speed
pizdish -_-
Best comment ever.
2.25 works best for me
45:06 : Terrabytes! Terrabytes! lol. And then the witch cackle! This is what spices up a software architecture presentation: 45:29 :-)
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...
Excellent talk! I wonder where I can view a copy of these slides
I've found gold with this...
1.5* speed - all the understanding, none of the frustration lol
Yeah thanks for that. 1.5* speed, 45:20 I lost my shit into a laughing fit.
Watching it in 10x speed.
watch in .75 speed when high
This is classic uncle Bob kudos!!!. I have few questions, Thanks in advance :).
Should interactor communicate with entity gateway using Entity model or business model? What if the team decides to migrate from SQL to NoSQL, this time the entity model itself might change. How can we design the system in a way that we can flip the database anytime without affecting the interactor/use case layer much? I think if the entity model comes inside the use case layer it might be tricky to make changes fast.
There are no gateways between interactors and entities. Interactors control "the dance" of the entities directly. That's my understanding at least.
That was the point. If you want to change SQL to NOSQL changes should be made under the line
for example create a customer is a use case,
Boundary interface declares createCustomer();
interactor implements boundary interface so it has to implement createCustomer();
Entity is a customer class
interactor uses customer class and it’s methods to create new customer object (at the least customer constructor only).
Changing database
think in terms of doors each boundary interface is a door to another service or components.
you decide what functions you would need from database and declare them in an interface. A da access class implements that interface and provide the desired functionality by implementing those methods. Your application only knows about the functions inside the interface that you provided nothing about the implementation so whenever you want to change a DB just implement the interface using a new DB.
Example -
you write an interface with saveCustomer();
you write a class dbAccess that implements the interface hence the method saveCustomer(){ implementation goes here with your choice of database}
Whenever you need to change the database just implement the DB interface and remove old implementation.
Further readings - adapter pattern, indirection
When he said "Put it in a separate .DLL" I had to stop the video and go lie down in a darkened room
😂😂😂
That part about not sensing the speed while in a ship cabin, needs an other more condition to be true: speed of the ship must be still (not changing) through the time! otherwise you can feel the force of your sit, or you will
اول سخنرانی، اونجایی که درباره این صحبت میکنه که سرنشین کشتی، که توی یه اتفاق بدون پنجره و ... نشسته، نمیتونه حرکت رو بفهمه، فقط وقتی درسته که شتاب نداشته باشیم!
you mean, you could feel the acceleration :)
@@Yetipfote exactly :)
Any one else get the feeling that if IT architects built buildings, we'd all be living on groups of tiny rafts, tied together, floating around on some lake? Life wouldn't necessarily be simpler.
That's simply because the analogy is wrong (and your joke just revealed it). In software, "architecture" and "design" means something different from what the city building architect might think of. That's why some people prefer using analogy from gardening instead of buildings architecture, that is, software engineers "nurturing" their products, not "building" them.
What makes you think that isn't already the situation we are in?
06:00 Mass is not relative, weight is. W = mg, where W is weight, m is the mass (constant for any body anywhere) and g is gravitational pull. (For Earth it is 9.8m/s^2).
Is there any concrete implementation of what he is proposing?
No. The point is to make you think he knows what he talks about so you (as a clueless business man) hand over your money to him in exchange for him applying his infinite wisdom to provide you technical solutions to your business problems.
Ivar Jacobsen's book was very influential, and many systems were built that embodied these ideas. For a time programming in the large seemed rational and understandable. Then the dodgey dogpile of chicanery called web 2.0 happened.
RIP: My ears
In my opinion, name of the project should scream what it does
1.25 speed; 45:25 best moment ever LOL
1.5 speed is even better
Hey Bob ! @05:57 MASS is not same as WEIGHT. You do not 'mass' 50 kilos - but you may weigh 50 kilos.
Your weight (and anybody else's) depends on environmental bodies.
The weight is a force of attraction between any 2 masses.
But MASS as far as I know would probably be an absolute - although I concede that it may vary depending on temperature (ENERGY).
The cooler it gets the more MASS will contract (shrink) and at absolute 0 Kelvin it is supposed to even disappear.
No energy => no mass.
MASS and ENERGY are related with Einstein famous equation, but not WEIGHT though, this remains in the scope of Classical Physics.
ALSO
What's the mathematics of absolutes and relative ?
absolute = absolute * absolute ?
relative = relative * relative ?
relative = absolute * relative ? could this work out ?
Maybe this is a senseless mathematics as ABSOLUTES in the physical universe are UNATAINABLE.
So Einstein might have been correct: EVERYTHING IS RELATIVE.
:)
Mass is relative, it depends on the frame of reference. By convention we talk about rest mass (that is mass of an object that is not moving respect to your frame of reference). In E=mc^2, that is rest mass.
Ah, and that energy? That is total energy. So, yes, termal energy affects it. However, not all of its energy is thermal, because thermal energy is only kinetic energy. Even if 0 kelvin can be reached, there would still be potential energy.
absolute * relative = relative. Yes.
We call absolute to something that does not change regardles of the frame of reference. As such, we consider the speed of light to be absolute.
Strictly speaking you don't weigh kg. You weigh newtons.
is the boundary concrete thing? how is a boundary defined?
I think C# had interfaces because Object Pascal (Delphi) had interfaces. C# feels more like Delphi than like Java to me.
In the old days, Java and C# was more similar. They have evolved in different directions since then.
I would argue (and get shoutet at for doing so) that Java is taking inspiration from lisps, with its module system, lambda-the-ultimate pattern and more, and C# probably taking inspiration from good things from Delphi.
But I'm not a C# developer, so I'm not going to die on that hill.
Thank you..
TAYLOR OTTWELL ARE YOU LISTENING
I assume you are sick of how laravel merges all these layers together too? :D
how can I threat Main() as a plugin, like loading it dynamically like a dll??? loading an entry point dynamically how does it work???
welldudethatsjustme you can choose what type of Main() you want, the console Main(), MVC Application_Start etc. Also it serves as a place to other plugins as DI and all other configuring stuff. Your APP is a Business layer, Presentation & Data access are just plugins (just the details) - that you should be able to change without changing any of your business logic.
8:00 in. Ummm because that helps devs know where the scaffolding is so they can add to it?
But is that was is important to an application? No, he argues not and he presents an alternative.
At th-cam.com/video/Nsjsiz2A9mg/w-d-xo.html do you think he intended for the blue circle to be a "Result Model" instead of another "Request Model"?
Can someone explain what he is saying at 48:50 . He says that you don't have problem of concurrency if all you do is create and read.
He's right. If you have once created some data and of course saved it in the database, but never update it afterwards (or even delete), you will never meet the concurrency. Because the data is always there, never changes, never gets updated or deleted.
he's talking about CRUD
PS there was no web just AOL
It’s all good but the only thing I don’t understand is if his time was so limited, then why did he waste first 8 minutes on talking about physics on topics completely irrelevant to the talk? Perhaps, if he got down to business from the very beginning then he wouldn’t need to skip the slides and maybe even have time to talk a little about TDD (giving that it was in his slides he probably had something interesting to say about it)
Why "interface" ? See Modula-3.
Still useful 2019
Please could anybody spell the name of the transaction databases mentioned in the last minute? Many thanks
Datomic.
moxy in the house
Talk starts at 35:00. Watch at 1.5 speed.
Why there are two types of arrows for the boundary?
Arrows with a triangle shape are showing an implemeting/inheritance relations. Simple arrows are showing simple use/dependency relations.
ебать у него микрофон орёт, у меня чуть сера из ушей не вылетела
30:25 thats the result model in the oval, right? Not the request model back to the user, right?
Or response model
That is, indeed, what is written in the blue oval at 30:25; the result model which carry the result of the processing of the use case initiated by the user from the delivery mechanism.
I've been posting this question on all his videos, you're the first person I've seen whose wondering the same thing as me!
Wow he is real legend
This guys sense of humor is stuck on 80’s... even before the Internet.
If you wanna laugh, go watch a stand-up comedian. This is for learning.
He got confused between mass and weight
He confuses mass and weight. Two different ideas. Mass is independent of location. Weight on the contrary. Mass is the quantity of resistance of a body to a change in its motion and is always the same unless the speed is comparable to that of light. Mass is expressed in kg, weight in Newtons.
Start from 6:09 & thank me later.
start from 7:00
Actually, your weight changes... mass on the other hand...
is ruby still important?
Nope.
starting to goin down
19:50 "the implementors of java were lazy, they didn't like multiple inheritance so they preferred multiple implementation of interfaces".
1) Can you please elaborate?
2) Which language has multiple inheritance well implemented?
AFAIK, only traits is the correct implementation of multiple inheritance (not mixins) and that can be done in Java without tweaking the language, it is just a little bit tricky Java code and it works like a charm.
+gmoschwarz
1) it's difficult to deal with the situations of multiple inheritance i
guess such as methods with the same name / signature, that they instead
just said, nah
2) within java 8 they KINDA have multiple inheritance - you can now have default implementations (that don't require private variables) of methods, so if you implement two different interfaces you can inherit the methods of both
docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html
Common Lisp got it right, but they had you specify HOW you wanted the crashing implementations got to resolve their differences.
And you almost never need it there. Like... ever.
Then again, multimethods are delicious.
HrHaakon not familiar with Common Lisp.
Search diamond problem with multiple inheritance.
too easy to corrupt, that's why this doesn't work.
Agree, dictating intent is fine when it's two developers conceiving the app. Three years and 20 interns later, this pattern creates some absolutely horrible directory structure.
@@williamb1933 I work with 40+ developers on my team and we use Clean Architecture.
Everything has been working great for a long time and everyone follows it.
Use code review and CI tools to help your team catch any discrepancies in code being produced. Also, document your architecture and important things for newcomers to know on a wiki.
He often has interesting stuff to say, whether live, on video or through books - but my God can this man waste a developers time with nonsense. Do yourself a favor and skip over the first 6 minutes.
+Casper Bang thank you!
It's a rhetorical technique to prime the brains of the listeners for engaged listening.
+Qio Cio It may be, but last time I saw him live, he also wasted 25min talking about lasers.
Lol... after listening to him for 6 min I started reading comments to see for how much to skip
I loved that introductory speel - it grabbed my attention immediately, as I was wondering where he was going with it, then he left a big question in my mind while he moved onto the next topic. That is brilliant.
Wow, he thinks that SSDs work like RAM and that SQL only exists because disks are slow. His devotion to pure message passing is admirable but he takes it a bit too far.
They kinda do, but they present an interface to the OS that looks like a standard controller.
I thought that he was talking about relational databases rather than about SQL itself.
Implementation, not the query language.
Bingo.
The only way that he can be right is with a pure key value store.
Whats wrong with me..? But I just can't trust those it-elder-stars who tells me what is MVC is and how good Uncle Bob MVC new version is better.. I think those elders should give up and enjoy their grand children's.. " Who is doing DI? Whoo most of you doing it.." I think that all that more complex stuff like DI/AOP and etc just scares elders because their mind can't handle it anymore as it was already damaged by mainframes and as a result stupid simplification patters is what is left from them mixed with bad attitude on stage.
Yuuuuuckkk
SOLID sucks so does Robert C Martin
its trash talk nor archigectures