Robert C Martin - Clean Architecture and Design

hello everybody um how fast are we moving ah thank you in reference to what that is the correct answer the question about how fast someone is moving cannot be answered unless you know some other frame of reference unless you compare it to some other frame of reference we do not appear to be moving with respect to each other very fast on the other hand we're on the earth and the earth is turning at a very sizable rate of speed and of course the earth is roaring around the sun at a certain speed pretty fast and the sun is tearing around the galaxy at a really fast speed and the galaxies are moving together our particular two andromeda and milky way are moving together at a very fast rate of speed but most of the galaxies are actually tearing apart from each other at a very fast rate of speed so the question about how fast we are going is relative this is a principle that was first expounded upon by galileo galileo said if you are on board a ship and you're in a cabin with no windows if the sea is flat and you cannot feel the waves then there's no experiment you can perform inside your cabin that will tell you how fast the ship is moving some guys in the 1830s started doing experiments with electricity and magnetism they had recently discovered that there was a link between the two prior to that nobody had known that they were related and one of the things they discovered was that there was a mathematical relationship between the unit of electric charge and the unit of magnetic charge it turned out that if you divided them in just the right way and did the unit analysis you got meters per second you got a velocity when they measured the physical quantities accurately they found out that that velocity was three times ten to the eighth meters per second the speed of light can you imagine the chill that went down their spine as they did that math and they saw this constant pop out that they knew very well what does electricity and magnetism have to do with light no one knew the answer to that question but a more disturbing aspect was that that division that little experiment violated galileo's principle because in an inside room without any windows you can do that experiment and a velocity comes out relative to nothing no frame of reference implied the physicists of the day thought well we got to have some kind of frame of reference there's got to be a frame of reference um let's invent this stuff called ether it permeates all of space it's frictionless it's massless uh and the waves of light wave the ether obviously waves must wave something something's got to be waving if there are waves and so the waves of light wave ether and they came up with brilliant experiments to detect the ether all of which failed horribly it's difficult for us to imagine now how wildly disappointing and extremely disturbing these experiments were right around the 1900s when they tried to detect the ether and every experiment they did failed they tried experiment after experiment after experiment they spent really large amounts of money uh comparatively this was the first really big science they had whole rooms full of concrete equipment and big massive pads that were isolated from vibration and the light sources that were really perfect and they could not see the ether it took einstein in 1905 to say well there's no ether and he made this remarkable statement that you know everybody's kind of going well how did he come up with that he said uh there is no frame of reference for the speed of light no frame of reference at all everyone will always measure light going at exactly the same speed no matter how fast the source of the light is moving no f no matter how fast the measure is moving anytime you measure a beam of light irrespective of any other motion you will measure the speed of that light past you at ten three times ten to the eighth meters per second and from that postulate he came up with the special theory of relativity has anybody read that paper on the electrodynamics of moving bodies 1905 this is a like a five page paper maybe maybe seven pages it's very short nothing more than high school algebra there's no real interesting math in there um you know einstein wasn't a mathematical genius at the time maybe he never was but at least at the time he wasn't he just came up with this bizarre idea and he followed the very simple mathematical pathway to come up with e equals m c squared e equals m c squared interesting equation energy equals mass times the speed of light squared but energy is equal to um mass times velocity squared one half mass times velocity squared and velocity is relative which means that energy is relative which means that mass is relative we don't have an absolute mass our mass is relative to another frame of reference i do not mass at 205 pounds i do that on the earth but by some other frame of reference i have a completely different mass how can my mass be relative mass must not be what we think it is well i'll leave you with that thought because we have other things that we need to talk about architecture um the genesis of this talk was about three to four years ago and it came about because my son who is the founder of this company i now work for him came to me with an application written in ruby and he showed it to me and i noticed something and it was the first time i had noticed this something but it was a common something it was common to most ruby applications so i went back six or seven years to a ruby application that i had written and i noticed the same thing this is the high level directory structure of the application i wrote uh 19 in 2004-ish timeframe 2005-ish time frame and notice the directories at the highest level we've got substitute whatever the heck that is and then immediately below that we have these directories that have very familiar names controllers models views this is what i saw when my son showed me his application this is what i did when i did my rails application but on this particular event i looked at it and realized there's something wrong with this why is this application at its highest level telling me that it is composed of models views and controllers why isn't it telling me what it does at its very highest level why isn't it telling me what it does why is it telling me how it's made i thought about that for a minute and i began to realize something this application was put together using a common web framework rails some of you probably use another common web framework uh either in net or in java or whatever platform you are using and very likely you have some similar kind of directory structure which exposes the elements that that framework demands why is it that the first thing i see is the framework why does the framework dominate why does the web dominate here's the thing that was bothering me the web for all its complexity for all its importance the web is a detail it's not the essence of our application the web is an i o channel why would we structure our application around an i o channel why would the i o channel dictate the structure at the highest level of our application there's something wrong with that there's something wrong with that idea because i went and i got some blueprints out and i looked at those blueprints and i found for example this one this is the blueprint of a library and if you look at it it's obviously a library there are bookshelves that hold journals there's a circulation desk there's a video collection there's this area over here with pcs on it that you can look at there's reading desks this is a library the picture tells you it's a library and if that doesn't convince you this one will that's a church it's obviously a church the architecture of the building tells you not what it's made of not what its architectural frameworks were it doesn't tell you that it's a concrete building it doesn't tell you that it was built with hammers and saws what it tells you is its intent architecture is about intent this is not a new idea this is an old idea it's an idea that has been around since probably the 70s or 80s it came to a certain fruition in the 90s some of you know who this guy is his name is eva jacobsen eva jakobson got involved with the whole rational suite of tools a while ago he was one of the three amigos who worked with grady booch and and who was that other guy can't remember his name uh who did the uml and the the rational unified process all of that but before he did that he and his cohorts wrote this book this book came out in 1992 object-oriented software engineering and i remember when it came out we were all very excited this 20 years ago we were all very excited about this book because it was a a the first time someone had used software engineering principles to describe object orientation and 20 years ago we were all very very excited about object orientation what evar said in this book was that use cases drive the architecture does anybody remember the whole use case fiasco the horrible nightmares of use case forms that that happened during the 90s and then into the 2000s every consultant out there came up with some new form for how to fill out use cases appropriately and they involve these blanks that you had to fill in the primary actors and the secondary actors and the tertiary actors the preconditions and the post conditions they they had it all laid out for you it was a nightmare but that's not what evar was talking about when he wrote this book a use case written by evar might look like this a use case is a description of a an action that a user will will perform on a system it describes how the system processes that action and what data is returned by the system here i've got a create order use case this use case might be part of an order processing system and i describe the data that would go into this use case customer id shipment destination payment information customer contact info shipment mechanism notice that i am not specifying any detail about this information i don't care about the detail right now all i want to do is kind of say there's some kind of shipment stuff going in i don't know what it looks like maybe we'll figure that out later then next i talk about what the system does with that data order clerk issues create order command that's actually not part of the use case that's what starts the use case uh system validates all data well that would be the data being validated up here notice that i don't say how it's being validated i just said somehow it validates it don't know how system creates order and determines order id i presume that's some kind of database action the identification of an id but i'm not going to say that here the system delivers the order id to the clerk doesn't say how you could easily imagine that these fields of data are gathered on a web form you could also easily imagine that the order id being delivered back to the clerk is being delivered on a web page but nothing here says that nothing here binds you to the web at all there is no indication of the web here the i o channel is completely gone i don't mention it at all this is the kind of use case that jakobson was talking about in 1992 a use case not a web use case then jakobson went on to describe how this could be broken up into a set of objects he said you could take that use case and you could put it in an object there could be a create order use case object i call it an interactor here uh he called it a control object i don't like to call it a control object because that makes it confused with the model view controller other people have said you know bob you could have called it a use case object this sounds like a very good idea to me uh maybe i should change the name from interactor to use case in any case this is an object this object encodes the processing rules in that use case somehow i don't care how we'll figure that out later there must be a method on this object a method something like execute what what pattern is that by the way if you've got an object that's got a method called execute what design pattern is that command pattern yeah there's probably a command pattern so i've got this interactor it's got a command and execute when i call execute it does what is necessary to execute the use case but notice i've got some words here interactors have application specific business rules what does that mean there are two kinds of business rules in an application and keeping them separate is necessary for a good architecture the one kind of business rule is the kind of business rule that is particular to the application being executed it wouldn't make sense in another application but the other kind of business rule is the business rule that transcends the application and could be executed in many different applications sometimes we call the first kind interactions which is why i called this an interactor the communication back and forth between the user is often application specific whereas the um the lower level business rules the more fundamental business rules are application agnostic where do we put the other kind of business rule jakobson put them in a thing called an entity nowadays we would call this a business object uh if you're a fan of eric evans this would go in your domain driven design this is part of your domain model the interactor is not the interactor is part of your application model these two models are separate the interactor tells the entity what to do in fact there are probably many entities involved with creating an order there might be a customer entity and an order entity and a product entity and the interactor would control all of those entities in the context of creating an order the last kind of object that jakobson talked about was the boundary object i have drawn them here as interfaces dot net interfaces or java interfaces why do we have interfaces where did this come from this this artist artifact of these two languages java and dotnet why do why does c sharp have interfaces yeah that's a nice nice way of saying it but no um uh c sharp has interfaces because java had interfaces um why did java have interfaces what was the rationale for putting interfaces into java keep in mind that you could make a completely abstract class in java by saying abstract class something and make all of the methods abstract why do you need a special keyword to make sure that all of the methods are abstract certainly this is not what we did in c plus in c plus plus if you wanted a interface we didn't even have the concept by the way but if you wanted an interface in c plus plus you just had a bunch of pure virtual methods you just made them all abstract you didn't bother with some new keyword why did we have this keyword in java we didn't like multiple inheritance that was exactly the reason the authors of the language did not like multiple inheritance they did like multiple implementation of interfaces but they didn't like multiple inheritance of classes why not to implement it's a pain in the butt to implement if you're a compiler writer they were lazy they didn't want to implement multiple inheritance it's hard to do multiple inheritance in a compiler there's all kinds of horrible ambiguities the problem can be solved it was solved in c plus plus it was solved in eiffel it was solved in lisp problem can be solved and by the way solving that problem is very useful it would be nice if we had multiple inheritance of implementation but we don't because the compiler writers were lazy and then they kind of smoothed it over by saying oh but we're protecting you programmers from yourselves because the multiple inheritance is actually really ugly and you know compiler writers here's a little clue i'm an adult you don't need to protect me from myself if you're going to be lazy about it just say you're going to be lazy about it but don't make up some goofy story about how you're protecting me from myself all right i'm ranting sorry these boundaries are interfaces now notice the pattern of usage here the interactor implements one of the interfaces this is the input boundary all data comes in through that boundary and gets polymorphically deployed inside the interactor this is the output boundary all data goes out through that boundary notice that all of the dependencies point outwards that's important and we'll come to that a little later these are the three objects that jakobson identified in his architecture in 1992. something happened we had this it was part of our culture uh everybody was talking about this book everybody was talking about the bce model the boundary control or entity model which i've turned into the boundary interactor entity model but the bce model really important blah blah blah it was very big deal and then something happened does anybody know what that was think back in time what was happening right around 1993 94 95 what strange thing was happening to our industry some of you weren't born then well most of you were probably born then some of you are probably still in grade school the web happened the web happened in 1993 94 95 96 and the whole development world turned upside down all of a sudden everything changed or that's what we thought we thought everything changed everything changed we had to hire people lots and lots and lots of people if you had a j in your name you could get hired as a java programmer right we hired rafts and rafts of people kids went to school to become programmers because they could get rich overnight by day trading on the web it was not a very healthy time we're seeing some echo of that right now in the social networking communities there's a bubble going on in the social networkers and i don't know if it'll pop the way that the dot com bubble popped uh i kind of hope it doesn't i kind of fear it will although the pop of that bubble will not be quite as damaging as the pop of the dot-com bubble does anybody remember 2001 remember that you know you had a job one day you did not have a job the next day and had no idea when you would get a job the next day if you were unlucky enough to be working at a company that was very successful the day before you probably owed the irs several million dollars and had no way to pay it the day after there's quite a few people who went completely bankrupt because their stock options had made their wealth look very large and then after the crash the irs said well you still have to pay taxes on that even though there was no money there lots of programmers were walking around holding signs you know we'll code for food it was not a good time and it it was a very scary time and during that time we were building systems still but we were frightened and scared and it was a a time of deep insecurity so anytime anybody came along with something that might help we would grab it uh what might help j2ee uh a framework might help a new platform might help uh um what was one of the early ones uh jsf that was kind of later struts anybody remember struts anybody remember these frames we would grab onto them oh good something to help because you know if we don't get things written really fast we're going to lose our jobs and it's really bad and during all of that turmoil and chaos we forgot about this it went away forward space now 2003 2004 2005. one of the frameworks that pops up pops up in the ruby space do you have any ruby programmers in the room a couple okay good there should be a lot more of you part of the symptom of the social networking bubble is that in the united states anyway if you can write ruby code then you can write any number on a piece of paper and someone will pay that number to you because there aren't enough ruby programmers right now so in the us ruby programmers that are at a high premium i have seen whole companies purchased for many millions of dollars for the purpose of getting the ruby programmers screw the business model throw all the customers away just give me those ruby programmers and sign them to a contract for two years i think that bubble is going to pop never mind that if you are not familiar with ruby you probably should be at this point because this language is getting more and more important and will continue to get more and more important languages have this tendency to rise and fall and if you're a long-term programmer you want to be a career programmer you have to recognize when a language is starting to rise and you have to kind of watch it and learn it and then at just the right time you're kind of surfing these waves of languages right and you're surfing the java wave or the dot-net wave but the ruby waves out there and you know enough about it and at just the right moment you leap onto the new wave before the old wave goes down you don't want to ride those waves down it's not ugly it's not pretty down there so 2004 2005 2006 in the ruby community this guy by the name of david hannemeyer hanson brilliant fella invents a framework called rails and this really turns the ruby community on its head because all of a sudden it was very easy to get initial web applications working with rails it was really a matter of typing a command or two writing a few lines of code and you had a website up didn't do much but then you could very easily incrementally develop this website and the development time was fast and you could do this do that it was like magic of course like all frameworks it had its limitations and to do any kind of significant website was not nearly that easy but still it's very very powerful the rails way of thinking carried a lot of baggage with it just like any framework does if you are a struts developer the struts way of thinking carries a lot of baggage with it if you're a net developer the frameworking.net carries a lot of baggage with it there's this stuff that you are supposed to do these classes you are supposed to inherit from these other classes you are supposed to use and it dominates you and all the examples you read show how you are directly using this framework to get stuff done and none of that pays any attention to this so this disappears it fades into the background how should this work well i've got a user out here this guy is using the web if we call that the web it's some delivery mechanism i really don't care if it's the web or not and this delivery mechanism by somehow or another talks through these boundaries to my interactors which talk to my entities now let's trace a command through the user does something he fills out a form and he pushes a button and what happens is that the delivery mechanism does whatever it does to validate the data and god knows what else it does but then it creates a request model this request model is a data structure it is a plain data structure it does not know about the web there's nothing in it that knows about the web it does not derive from any framework based on the web it is not an instance of http request it is just a data structure in the simplest case it's an argument list to a method in the boundary object in the more complex case it's just a plain old java or net object that's gets passed in to the boundary object it polymorphically deploys into the interactor and the interactor looks at it and says oh i guess i've got to do some work so it uses the data in that request model to start calling methods on the entities the interactor controls the dance of the entities it is the choreographer of the methods that go out to the entities and once the job is complete the interactor reverses the flow and starts pulling data back out of the entities to construct another data structure called a result model or a response model if you wish the result model is still just another raw data structure no trappings of the web no knowledge of the web the result data structure goes back through the boundary into the delivery mechanism where the delivery mechanism displays it somehow or another can you test that stuff without the delivery mechanism of course you can right you pass the data structure and you get the data structure out you look at the data structure does the web server have to be running if you're a web application no this is by the way the goal one of the goals you should be able to test all your business rules without the web server running web servers are a pain they get in the way they take a long time to boot they take a long time to tear down there's all kinds of configuration testing while they're running isn't pain i would like to just test all my business rules by passing a data structure and getting a data structure out real easy without any other stuff running i don't want any other processes running i don't want the web server running i don't want my framework in the way i just want to be able to test my business rules what about model view controller i thought that was the architecture of the web and of course we fiddled with it then we turned it into model view presenter and model view presenter control and model view model and mvvm and all these other things where did this model view controller thing come from it came from him uh i cannot say his name properly you can probably say it better than i i would say it triggvy rinse cowg and i'm probably saying it wrong um i met him last year here at nbc he gave a talk here i was up in the speaker lounge and i was looking for a place to plug my laptop in and you know i'm wandering around looking for a place and and this guy old guy hands me a power strip and i look up and triggering scout and i take the power strip from him and our hands brush and my finger touches his and i haven't washed that finger it's triggy rings this guy invented model view controller in the 70s in small talk and the way model view controller worked back then it's very simple we would have some small object which encoded a simple business rule nothing very elaborate or big these were generally small things not big things we would have a view the view would hang what we would now call an observer relationship on the model the view would register with the model the model would call back to the view saying by the way something in me changed you need to update and again this was something relatively small and there would be a controller object the controller object would look at the mouse and keyboard and translate user gestures into commands that were relevant to the model input process output real simple kind of pattern this was used in the small these objects were small you would have a model view controller for a button you'd have a model view controller for a circle you'd have a model view controller for a radio button a model v controller for a text field these were little things not a massive application architecture we've changed that and why did we change it well there's this thing that happens in software and it probably happens everywhere some name gets associated with good mvc is good uh now i'm a guy programmer and uh whatever i do is good because well i'm good and somebody says mvc is good well that must be what i do because i'm good and so you've heard this done before right uh oh we're doing oh oh what's up oh well it's this oh yeah i've been doing that for years right because you know i'm good um so this is probably what happened here some something like this because what we now have doesn't look much like model view controller to me this is model view controller now as it is done on the web we have these controller things now um are not the first things to look at user input right we've got the whole web server out here first the web server is doing all the pathing and the routing and the gathering of data and all that gunk once the a whole pathway has been resolved we can finally call a controller with an http request or some equivalent the controller then goes to the use cases the business objects i should say and it starts telling the business objects what to do and at some point the controller hands the control off to the view and then the view reaches into the business objects and pulls a bunch of junk out of the business object and displays them and this rat's nest of dependencies is the result what happens to the business objects in the heat of battle is that they begin to acquire controller-like methods because the controllers need to tell the business objects what to do and the programmers are so busy that they don't remember to keep the controller stuff separate from the business object stuff so you start getting controller-like stuff in here and then the guys writing the views need methods on the business objects to get at the data and you start getting view like methods in the business objects and the business objects become this kind of hybrid thing of half controller half business object half view i know that adds up to one and a half um and the math works anyway so probably we have problems here now you can do this well but most people don't they're in the midst of a a flurry of activity and the boundaries are not well enough defined to do this well how do we do it in the clean architecture the jacobson architecture this shows the output channel here's our interactor our interactor has been working with entities and it has now created the response model it's about to send the response model back out to the user interface the object that implements the output boundary that the interactor communicates with it's called a presenter the job of the presenter is to take the response model and turn it into yet another data structure this new data structure is called the view model and the view model is this very interesting data structure that looks like it is targeted at the web if you're in a web application it looks like it's targeted at the web it does not know about the web it does not depend on any of the web frameworks it is still independent of the web but if you are putting something on a web page there is a field in this data structure for every element that would appear on that web page if you have buttons on the web page that have names there are strings in here that contain those names if some of those buttons should be grayed out there are booleans in here that tell you what the state of those buttons ought to be if certain numbers ought to be read there are booleans or enums in here that tell you what the color of certain fields ought to be anything that appears on the web page is represented here in the view model in unambiguous and complete ways the only thing left to do is to put it on the page and that's what the view does the view looks at the view model and just says okay take that field put it here take that field put it here take that field put it here you might have a loop in here that loops through some table but you're not going to have any if statements in here or not too many you might have a if if enabled turn it gray if not enabled turn it black you might have that kind of if statement but there's no processing in here the view is so denuded of functionality that it doesn't need to be tested no automated test needs to be written for it because there's no worthwhile code in here of course that also means it's easy to test if you want to it's really easy to test something that doesn't have a lot of code in it can you test the presenter yeah it takes an input data structure it creates an output data structure you can test the presenter do you need the web server running to test the presenter no you can see a pattern developing here can't you what is that pattern the pattern is this boundary that boundary that black line right there is a component boundary across that black line all dependencies must point inwards towards the application anything outside of this black line must point inwards why because the stuff out here is a plug-in to the application uh who's using resharper see we're making progress here this is good visual studio becomes almost usable if you have resharper in it does visual studio know about resharper no not one line of source code inside a visual studio knows that resharper exists resharper is a plug-in the web should be a plug-in to your application not one line of code in your application should know that the web exists you put the web in a different dll entirely and you plug it into your application if you don't like the web plug something else in maybe you'd like a service oriented architecture god help you using soap yikes but you could plug it in you want to use a thick client plug it in you want to use a console app plug it in plug it in across that boundary make sure all dependencies point across the line now i'm not naive enough to think that that the api created here would serve for both a web and a and a thick client and a service oriented architecture there would obviously be some differences across that boundary but those differences are manageable if you bind the framework to the application you lose control here's what the whole thing looks like without the entities our controller still exists we still use model view controller but notice that model view controller is entirely on the left side of the line our application does not know about model view controller because model view controller is a delivery pattern our controllers live on the left side of the line they construct these data structures which are passed into the interactor which manipulates the entities which creates response models which the presenter then turns into view models that get viewed and all of this is testable and all of it's nicely decoupled and all of it is a plug-in architecture what about the database databases if there is a word that has defined our industry for the last 30 years if there is a word that strikes fear into the hearts of developers for the last 30 years that word would probably be database does um that look familiar to you the database is the great god the altar upon which we all worship the applications our minions to the database all applications serve the database according to the database rules and the priests of the database are the great dbas in the sky we have built this kind of philosophical structure we have given a lot of weight to the database the database becomes important the data model is critical we have to protect our data assets who came up with that lovely term it's a good marketing line isn't it you've got to protect your data assets oh yeah i guess we do yeah pay me millions of dollars i'll i'll sell you a tool that will protect your data assets um okay there's certain amount of marketing business going on here and makes perfect sense why do we have databases database processing engines why do we have these tools like sql server like oracle like why do we have them i mean what goes into a database bits bits we know how to put bids places we store bits and places we put bits in memory why do we have databases the reason we have databases is historical we used to put data on rotating bits of steel coated with a magnetic emulsion some of us still do is there a rotating memory in this room does someone have a disc in their laptop no one will raise their hand they don't want to admit that they're living in the early part of the 2000s but the fact is that the disc is dead right you might have some discs still but bit by bit the discs are dying the solid state memories are taking over i have a half a terabyte of solid state memory in here the next laptop i have will probably have two terabytes of solid-state memory terabytes terabytes do you know what that word means can you imagine like i'm this guy you know in 1977 and and i had to buy my first pdp 11 and i had to scope out how big the discs ought to be and i was just walking around the halls of my of my company laughing hysterically like the wicked witch of the west 25 megabytes terabytes the ram discs there they're not ram discs i can't call them that the ram is coming and as the ram comes you and i will have this interesting option because ram is not addressed the way disk is there's no spinning memory there's no heads there's no records there's no sectors there's no rotational latency there's no seek time so we can get it any bite equally fast as any other which means we don't need the indexes we don't need the special access methods we don't need any special software to manage the data that's on some very difficult to use medium because the medium is not difficult to use anymore it's an address space and we've got 64 bits of address space oh hell we'll just put it all in ram and treat it like computer memory this is what's happening if i were oracle i'd be scared to death because the very foundation of why i exist is evaporating out from under me we are now moving into the realm where sequel will become something that people don't know how to spell um we won't be using these odd query statements anymore even link might start to look antiquated even though it's very cool and everything we might suddenly start looking at all data as though it's just part of our memory what's the worst problem that databases have the most complicating part of a database transactions you know got to open them you got to roll them back you got to commit them know what goes in them and what doesn't if you do it wrong you get concurrent update problems you get deadlocks unless you've got a good system this whole business of locking stuff if what if we have so much memory that and our processes are so fast that we don't need to ever delete anything again we don't need to update anything what we'll do instead is we will simply record every transaction just stick every transaction in the database we will not record the state of an account we will not record the state of a user we will not record the state of anything we will simply record all the transactions and we will recompute state anytime we want and maybe we'll take a snapshot of state every day and then recompute state on a daily basis or so but we will not save state if you don't save state if all you save are transactions then you don't have crud applications anymore because there's no updates and there's no deletes you don't have crud applications you have cur applications you can create and you can read and if all you're doing is creating and reading there's no transactions the transactions go away all the concurrency disappears all that horrible nonsense of committing and rolling back and all that just goes away is that where we're headed you use a system like this right now probably if you're sane you have a source code control system that source code control system works exactly that way it stores transactions does not source state it reconstructs state every time you check something out it decomposes that state whenever you check something in we use a system like this now to manage our code maybe it's time our clients got to use a system like that too in any case the database is a detail the database is a place to store bits the database is not the center of our system it's just the thing that holds the data and like any detail we would like our architecture to treat it like a plug-in i do not want my application to know that the database exists i want my application free of any knowledge of the database i don't want anything about the schema up here these are not schemas these are not rows in a table these are business objects how they are composed is i don't care how they're composed these are not data elements they are bags full of methods what is an object what is an object is an object a bunch of data no an object is a bunch of methods you're not allowed to see the data inside you're not even allowed to know that there's data in there all you can see of an object are the public methods an object is a bunch of methods if there happens to be data inside that's none of your business these are bags of methods i don't know what data they contain i can't see that i can't know that and i don't want these guys to know that i want this stuff to know that i want some gateway interface that allows my interactors to fetch entities across this boundary all the database stuff i want living down here who's using an hibernate or hibernate or some kind of orm that stuff lives down here not up here down here below the line with all dependencies pointing upwards nothing about the application knows that there's an orm the notion of orm makes no sense to the application by the way the notion of orm makes no sense at all anyway there's no such thing as an object relational mapping you cannot wrap map datas to functions what you can do is you can hydrate op data structures that's what an orm does it hydrates data structures it loads them from from a database of some kind i want all the database stuff living down here i want you to write your applications such that all the business rules are contained in a a component or a set of components and then i want all of the ui stuff to be plug-ins to those components i want all the database stuff to be plug-ins to those components if you've got any third-party stuff that you're dealing with plug them into the components i don't want your application to have outgoing dependencies your application is composed of business rules and those business rules are the family jewels you keep those jewels in a nice little bag and you don't let people look in nobody can look in you just keep that in there you keep them isolated you don't let the frameworks touch them frameworks if you're a framework author the thing you hope for most is that someone will inherit from your base classes because once they inherit from your base classes they have married you without any commitment on your part you are the sultan they are the harem they marry you you don't marry them they throw their inheritance relations at you and they are bound to you it's very difficult to break an inheritance relationship if you derive from a framework you are bound to that framework i don't want you doing that i don't want you treating a framework as if it were the sultan and you were the harem i want you to keep the framework at arm's length out here somewhere you can use it it's all right you can date it don't marry it put some little interface in between make it a plug-in to your application will this hamper you slightly oh it will create some minor inconveniences because frankly it's convenient to marry something but there are costs that you don't want to experience keep the frameworks at arm's length who's doing dependency injection look at that everybody's doing dependency injections cool isn't it dependency injection you get to get to kind of specify ooh these objects just come out of nowhere don't know where they come from and then who's got an xml file that describes how the dependency injection actually works who's got one of those a few of you that you've completely lost control of who's experienced you know the well i built the system and it doesn't work because the dependency injection configuration is all screwed up who has put elements in their source code that denote certain classes are dependency injected auto wire statements or things like that and in dot net these would be these square bracket annotations or attributes whatever they're called in java they're the little at sign annotations or attributes often called auto wire or something like that i don't want any of that in the business model i don't want any of that stuff up here i don't want any source code above the line to know what dependency injection framework we're using i don't mind dependency injection i just think it ought to be injected below the line what exists below the line well one of the modules that exists down there is called main main you remember main means that thing that you write at the beginning in the main program main is a plug-in main contains the strategy implementations the factory implementations the dependency injection specifications all that concrete horrible stuff that you can then pass through a plug-in connection to the application as abstract entities main is a plug-in the database is a plug-in the gui is a plug-in the frameworks are all kept at arm's length across the plug-in boundary i want you to think of your application this way as a group of use cases that describe has a bunch of use cases that describe the intent of the application and then a group of plug-ins that give those use cases access to the outside world a good architecture is an architecture that allows you to make decisions late decisions about the ui decisions about the database decisions about frameworks you can make them late because you can implement all the use cases without them a good architect maximizes the number of decisions not made the amount of decisions that can be deferred until later because later is always better when you're making decisions you have more information later i won't do the rant on tdd because i only have two minutes are there any questions yeah when so i'll repeat the question when i was talking about databases at one point it sounded like i was talking about data the atomic is a um a database engine that is that is um uh works the way i talked about uh you can add things to it you cannot delete you cannot update um there are many such debate database engines out there daytonic is just one of them i suggest that if you're interested in that kind of stuff you can look up daytonic you can look up the work of greg young who's been working on this stuff for a long time and start to investigate this idea of transaction-based data rather than state-based data anybody else the lights are in my eyes all right i think you can go then thank you you

Channel: gnbitcom

Views: 271,903

Keywords: uncle bob

Id: Nsjsiz2A9mg

Length: 58min 39sec (3519 seconds)

Published: Wed Jun 04 2014