yeah it's to your right yeah this is an unwavering beloved nature we all have to
biological parents how many biological grandparents do you have for is is the
most likely number how many biological great-grandparents do you have okay
yes it's yeah yeah k and as we progress up the powers of to the fuzziness of
that number grows so if we go back ten generations
you should have a maximum of 1024 ancestors at that level but it's
actually quite likely that you have less than that and if we went back 20
generations that the maximum is a million possible for bears but it's
almost certainly not a million by the way if we go back ten generations
that's about 400 years so now we're back in the 1200 a DS let's go back even
further let's go back 30 generations to 800 a.d you would now have a billion
possible for bears but there weren't a billion people at that time so no way
did you know there's been some mixing going on
go back another 400 years to 400 AD and now it's a trillion possible for bears
but there have never been a trillion people ever so this curve which starts
out at powers of two
starts to curve in words it doesn't make it all the way out to the powers or two
and in fact there's another mathematical thing going on here as you go farther
and farther back in time the odds that someone who lived before then line died
out is positive the farther back you go the more likely it is that some line
died out and it is a mathematical certainty that if you go back far enough
every line has died out except for one which means that all of us in this room
and every person on the planet ought to be able to trace our lineage back to a
single woman and a single man this is a mathematical certainty i'm not talking
about some religious thing and it's just a mathematical certainty of somewhere in
the deep dark past there is an adam and eve from which all the human genetic
material has derived and we know something about these people remarkably
enough because there is evidence within our bodies that is preserved through the
ages most of us
well all of us actually have within our cells a little bit of DNA that comes
strictly from your mother
it's called mitochondrial DNA it's not carried in the nucleus it's carried in a
little organelle called the mitochondria which is responsible for transforming
glucose into energy the mitochondrial DNA you got from your mother because the
eggs have at the sperm don't she got it from her mother she got it from her
mother she got it from her mother who got it from somewhere back in time from
the mitochondrial Eve men in the room you got your Y chromosome from your
father who got it from his father who got it from his father who got it from
his father so somewhere deep dark in the past there is the Y chromosome at
and we know a little bit about the mutation rates we know how how rapidly
roughly these bits of DNA change over the eons so we can date when these two
people might have lived and it turns out that the the mitochondrial Eve lived
seventy thousand years ago roughly and the y no excuse me that was the
y-chromosome Adam he lived seventy thousand years ago the mitochondrial Eve
lived a hundred and twenty thousand years ago before the last ice age began
the Y chromium chromosome Adam lived about 70 million years ago in the midst
of the last ice age and we also know the location they were both uh apparently
born in the east of Africa and we know this because of the amount of genetic
diversity that lives there so i think that's fascinating and it's not what I'm
here to talk about
do you remember the eighties and nineties some of us do probably quite a
few of us do in the eighties and nineties we had heroes in the software
world and those heroes looked something like this that's great ebu to remember
is Grady boots yeah
Grady boot and why do you remember him because who could forget those two words
he's got a great name
Grady Booch not he wrote a good book write a couple of good books actually
I've got it up on the board their object oriented analysis and design with
applications who read this book 20 years ago
yeah and what did it tell us you know oh you draw clouds ok we forgot about the
clouds now we're not going to do clouds anymore but but we did learn about
objects and relationships and inheritance and using relationships and
he painted this lovely picture of how to do design and architecture and that's
what we were all about in the nineties and the late eighties the nineties how
do you get the right design how do you get the right architecture remember that
guy that's your highness true strip he wrote the language c++ why did he write
this language why did yarn is true strip write C++ what was always the
programming before he wrote c++ simula yes he was in edinboro it was
programming in simula 67 the first object oriented language and then he got
hired by bell labs and they said you should write and see any kind of went oh
no and he wrote a little preprocessor that sat in front of c he called it see
with classes that made see look like simula and then that grew into c++ and
all of us at this time were interested in how we were going to do objects c++
was the language we were going to do it in and
we're going to use Grady Booch 'as ideas to do it
we were very enthusiastic about design and architecture and then along comes
this guy even Jakub person who writes this really tremendous book
object-oriented software engineering and he introduces to the world the concept
of use cases who remembers use cases who could not tell you what happened to use
cases use cases wonderful idea
you know i'm going to go back and talk about them in a minute but what happened
to them was the was the invasion of the consultants the consultants came and
thought through this is a good idea i bet i bet i could embellish it and they
did a about who remembers downloading pdfs of use case forms that were page
after page after page of fill-in-the-blank crap you know the
title of the use case the primary actor of the use case the secondary actors of
the use case the tertiary actors of the use case the preconditions and
postconditions in the first primary course and the second primary course and
the alternate courses and of course you look at all that I've got to fill off
out and then while we were in the throes of all that 1995 design patterns the
Gang of Four the guys who brought this semblance of order to the apparent chaos
24 design patterns that will live in infamy mortality the we thought there
would be many more we thought this was the first of an avalanche
of design patterns didn't turn out that way
couple more showed up here and there few people wrote a few more books with a
couple more design patterns in them but they captured these four guys captured
have probably about 75 to 80 percent of the design patterns of people use on a
regular basis and now we had all the tools we had everything we had the
language c++ well java was coming and okay we had the deal with that but in
java if you squint real hard it's still c++ and we had we had all the
object-oriented design tools and we had the design patterns we had it all and we
were ready to go and then the focus changed now it's gonna be code who
remembers this book recent who's read it it's almost the same people good
I remember reading this book in nineteen ninety five or six now
898 my son was playing hockey and I would take it to the games and the great
thing about hockey is that your son cannot be on the ice for more than about
five minutes because they get too tired they have to come in and sit down to the
coach things other people out so while my son's on the ice i'm watching and
then as soon as he sits down i'm opening up the book and reading this book and I
remember this is the first book that I ever read that presented code as
something malleable every other book showed the finished product
this is how you should write the code and at any programmer would look at
those books and go
it never looks like that when i write it there must be something wrong with me
and then Martin puts this terrible code in the first chapter of his book and it
looks very familiar yes I've written stuff like that and then shows you how
to manipulate it and twisted and turned it and turn it into something wonderful
and he implies but does not quite state that you need unit tests in order to do
it
that was clarified by this guy who came along and wrote the extreme programming
book now we're in 1999 i was here at poop in 1998 Kent Beck was teaching in
the room across from me i was teaching a c++ object-oriented design thing he was
teaching I don't know what something and I walked into his room at a break and I
said you know Kent you've been writing about this extreme programming stuff it
makes no sense to me why don't we sit down at lunch and talk about it and he
sat down with me at lunch and we started to chat and I thought you know this is
getting pretty interesting he's got some interesting ideas at the time I was the
editor of the c++ report so i asked him to write a column or
article for the c++ report which he graciously did this was the height of
sacrilege because Kent Beck was a small talk programmer and I was letting a
small talk programmer touch the hallowed pages of the c++ report there's a great
article 2 so now we've got the process we've got the designs of the tools the
patterns that use cases the process the focus on code and then the agile
manifesto bunch of guys get in a room at Snowbird and we write down these four
rules i don't remember who it was that came up with the four rules it was I
think it was word Cunningham but he denies it but there they are the four
rules individuals and interactions over processes and tools working software
over comprehensive documentation customer collaboration over contract
negotiation responding to change over following a plan it's not that the
things on the right are bad they're not it's just that we like the things on the
Left better the people who signed it you can see on the bottom that group has
never really settled we almost resembled a few years back at the agile conference
but a few were missing and even then we didn't like it
these were people who fundamentally disagree about everything except for
this one day this one occasion where some kind of magic happened and we
managed to put this together and go our separate ways and never meet again
and of course we also got that
how many are doing scrum oh look at that
lots and lots of scrub that we like scrum scrum is fine
well scrum is ok if you do it right course that's true with anything isn't
and the means began to spread courage no big upfront design know da who came up
with this idea of no documents goodness gracious you aren't going to need it
simple design all of these ideas roaring around in our minds in our heads we were
poised to do great things
it happened overnight none of us expected the bubble popped all of a
sudden all of our great momentum was just thrown into a permanent stop the
brakes had been applied we screech to a halt and we wondered what the hell
happened and now we were in a different mode now if you had a job as a
programmer it was a rarity it was these guys were actually fairly common now
that's obviously a guy who's pulling a joke but there were a lot of unemployed
programmers during that time and we took on a very different attitude and that
took place in the midst of the web growing and growing and growing and
coming to dominate everything and the web became this thing this almost a God
in the way we thought about everything that had to do with software and so did
the database anybody remember the ads these guys put on the air back at the
back at the height of the web the the power that drives the internet and I
would sit there and watch that and go what the hell are they talking about the
database is not the power that drives the internet but they said so
and then the platform's begin to proliferate we had j2ee we had java we
had Ruby we had dotnet grow out of you know what . net is everything . that
programmers in here
yeah the java programmers is what you are
it doesn't that is really just java they changed a couple of letters around and
replace the keyword with a colon the to have gone in slightly different
direction since then but you can still take some java code in some csharp code
and lay them side by side not see a single bit of difference and the
frameworks proliferated all the horrible frameworks DJ bees and jsf sin apache
and wickets and JPA and struts and velocity and we're still in the throes
of this because there's a new framework every weekend every month and our our
outlook has changed we used to be . we had the design patterns we had the
process we had that the design principles we had all of that and now
we're looking for the next big framework to help us now we're looking for the
next big tool to help us if I ask someone what is the architecture of your
system
they're almost certainly going to tell me something like it's apache and spring
and some dependency injection and oracle and that's not an architecture that's a
bunch of tools
and so came the end of design architecture since then we've been
putting the pieces together doing some integration with frameworks and stuff
what happened well the years went by a decade and all of a sudden
wait a min
the web is not an architecture the web is an i/o device the web is an i/o
device and what do we know about IO devices what did we learn in the sixties
about IO devices you want to be independent of them that's why we
created device independence
that's why in early units there was standard in and stand out we didn't want
to know what the device was we just wanted to be able to say well output
this to something and not know what it was
the web is an i/o device that we want to be independent of and we began to
realize the database is not a god
the database is not the center of our system our applications are not little
minions that serve the desire of the great database in the sky are
applications rule the database in fact the database is an i/o device
something we want to be independent and so we began to remember the design and
we began to remember the patterns and we began to remember the architecture and
we began to remember what all this stuff was about that we were so enthralled
with in the late eighties and nineties it's taken a decade but it's starting to
come back to us we're beginning as an industry to remember oh yeah there is
such a thing is actually designing and architecting applications now of course
we do this in the context of an agile process but is there any reason you
cannot design an architect something while you are working in short
iterations while you are writing tests while you are doing all of the things we
do in an agile is there any reason that you cannot do this design the answer to
that is of course not
you can do the design is there any reason that you should not begin every
iteration with the design session
no there's no reason why you shouldn't do that why wouldn't the team go to a
whiteboard and start drawing some simple diagrams you don't have to spend weeks
at it back in the days when we were doing the agile manifesto the thing we
decried was big upfront design we did not be cry up front design little bits
of upfront designer and a bad idea
and by the way if you're going to put together a large application it's
probably worthwhile taking a week and thinking about what the heck the shape
of that application really is you don't have to spend months at it you don't
have to design it down to the last little detail but it would probably be a
good idea to know what the general shape of the application is this will be
incorrect but that's okay because you can fix it in process that's what a
giant Liz good about doing allowing you just six things as you go along to have
the initial starting point would not be a bad idea at all
yeah Commission gave us use cases this is what a use case should look like it's
simple its idealistic it doesn't really say much
this one says huh in order to run this system you're going to have to be able
to create an order and in order to create an order while you need a
customer ID I'm not gonna tell you what's in the customer ID I'm not going
to try and give you that kind of detail right now it's just that I know we're
gonna have to have some kind of customer ID and we're gonna have to have a
shipment destination don't know what's in that destination don't know the form
of its ok we'll get there later right now all I know is that we certainly need
to see a shipment destination and we need payment information than we need
customer contact information and we need a shipment mechanism but i'm not going
to tell you the details because I don't know
and how does the use case work well it's kind of a a simple thing and in rough
terms the order clerk issues to create order command with the above data that's
the first step of the use case second is the system validates all the data i'm
not going to tell you how I don't know what the validation rules are i'm not
going to write them down here we'll do that later
I do not want to say though that we are going to validate the data and then the
system creates the order and determines the order ID I don't know how that's
probably a database operation but i'm not going to say that right now and
finally the system delivers the order ID to the clerk probably on a web page
somewhere but i'm not going to say that this web system could be no reason why I
couldn't be but i'm not going to say that here there's nothing here about the
web
why because we want to be independent of the web are we using oracle database are
we using a relational database
don't know don't care not important
I can specify the use case i can capture the essence of the business rule without
knowing whether we're on the web or whether we've got a relational database
I don't need to know those things how much work can you do without having to
know those things the answer that is you can do a lot
without having to know what database you're using or whether it's even a
relational database whether it's on the web or not the web is not important to
these kinds of decisions
jakub sins said if you've got to use case you can turn it into an object
there's an object i call it an interactive interactor is a simple
object it captures the essence of the use case the code inside this object
follows the decisions and the procedures inside the use case i call it an
interactive because jockelson called it a control object and I didn't want it to
collide with model-view-controller so i changed the name to interactor the
interactor contains application-specific business rules and now I need to explain
something there are two kinds of business rules first kind of business
role application-specific and that means that this business rule cannot be used
in another application then there are application independent business rules
these are business rules that apply to many applications in the same domain so
imagine we've got an order entry system and in order processing system the use
case create order only applies to the order entry system but the algorithm for
computing the price of the order very likely goes in both of those
applications so one of them is application-specific one of them is
application independent the application specific stuff goes into the interactor
the application independent stuff goes into what Jakub ssin called entities
nowadays we would call these business objects but we would be wrong because a
business object in most of our worlds mixes the application-specific and the
application independent stuff in this case the entity is a pure element of the
domain model knowing nothing about the application but knowing about the domain
instead and it is the interactors job to control the dance of
the entities so the interactor tells the entities what to do
yeah considered and one other kind of object he called it the boundary object
and I've shown them here as interfaces if I had time I would rant about
interfaces i might just have time but not yet
those are interfaces or i should say abstract classes those are abstract
classes are interfaces notice that one of them is used by the interactor one of
them is derived from by the interactive the interactor derives from the one on
the bottom it uses the one on the top
the one on the top is the output boundary anything going out of the
interactor goes out through that boundary interface anything coming in
billion her actor goes in through that bottom one notice that the two
dependencies . in the same direction that's really important
that's that's what we call architecture
yes yes there will be more now let's walk through this we've got a delivery
mechanism on the left over there it says some users going to talk to talk to it
by delivery mechanism i mean the web
well might be the web might not i don't know it's just some UI but it's going to
talk through the boundaries to the interactive the interactors will control
the entities watch how this works
the user pushes a button or enter some data or something and the delivery
mechanisms job is to create a data structure a data structure that
represents the use case the data going into the use case this this data
structure i call a request model is a pure data structure it doesn't know
about the web it doesn't have any trappings of the web it's not the little
parameter thing that you get in HD HTTP request
it's a raw data structure if you're if you're programming in.net it's a plain
old c-sharp struct if you're in Java it's a java object with
probably public data elements it's not an object it's a data structure that
data structure gets passed through the boundary object into the interactor
interactor looks at it and says huh well okay I guess they want me to do
something oppose the data out of the request model and it uses that data to
control the dance of the entities tells the entities to do things based on all
that data and then the flow gets reversed all the data comes back out of
the entities is gathered by the interactor and the actor produces a
result model result models another data structure playing all data structure no
trappings of the web has no idea where it's going that data structure goes back
out through the boundary objects to through the delivery mechanism where it
somehow by magic gets displayed to the user can you test that interactor yeah
you create the request model you handed to the interactor you look at the
response about the result model in your test you can test the interactor you
have to have the web server up to do that if the web server running to check
to test the interactor know you have the database running to test the interactor
well we don't know where the entities came from maybe they came out of the
database
well we'll talk about that in a minute but you don't have to have the web
running anyway you don't have to have the application server running if you're
very very clever you could run as these tests on your laptop without any web
server running without any connections to any databases that anything anything
just running on your laptop at 30,000 feet while you're flying over the
Atlantic this is the test of a true test a true test does not need to be
connected to anything and you can run it at 30,000 feet over the Atlantic while
sipping a gin and tonic
yes yes there'll be more
what about my love your controller i thought that was the architecture we all
used anybody know this guy wait wait he's not up there
well done but that guy anybody know that guy i'm going to completely butchered
his name when I say it it sounds like this trick virions cow had enough that's
right or not but I met him once it was in Oslo and I was giving a talk and I
was up in the speaker's lounge preparing and in lakhs trigger earrings cop
yeah now I read about him since I was you know little and i was i was in the
midst of trying to find a place to plug in my laptop when he walked into the
lounge and he saw my dilemma and he picked up a power strip and handed it to
me and i graciously took it from him and Hart our fingers touched
I haven't washed that hand trick means cat came up with this idea a very very
long time ago in the probably late seventies and it's a simple idea
model-view-controller we begin with a model object model object is just a
crystallized business rule really really small one
it does not know how it is output it does not know how its input it's just a
a processing engine the controller down there at the bottom is an input engine
it gathers input from some source maybe it's the keyboard maybe it's the mouse
maybe it's some service oriented architecture interface god help you but
whatever it is the input comes in through the controller the controller
tells the model what to do with that input and controller gives commands to
the model at the level of the model and then the model has views that funny
little arrow up there is an observer relationship
the views register with the model the model calls back to the views so
whenever anything changes in the model the views are notified a something
changed and the views go look inside the model and display it anyway they wish
simple idea input process output when we did this in the early eighties we would
have a model view controller for a button and another one for a text object
and another one for a checkbox and another one for a little edit box these
were small things we did not have a model view controller for the whole
screen with a little model controllers
then came the web and the web did that get the web over there to the right
it's gonna do some fancy dancy processing on HTTP request to the
running through some kind of router algorithm and eventually tell the
controller's hair controller you deal with this the controller then unpacks
the HTTP request and then it reaches into this vast sea of business
objects and starts to manipulate them and then it has control over to the view
and the view reaches back into the vast sea of business objects and gets data
out of them and then displays the data and the problem with this is there's no
boundaries boundaries are fuzzy there's no control over the dependencies here
and by the way the dependencies that we do have go the wrong direction and so
the business objects begin to acquire controller like teachers and they begin
to can't gather view like features and worse the controller's begin to gather
business object like features and the views begin to gather business rules as
well there's a blurring of the division what you're looking at there is a
boundary that double black line that's an architectural boundary notice that
the dependencies crossing that black line all go in one direction and point
towards the business rules a point inwards and they land on things that are
abstract like the boundary object or the data structure now here's how this works
the interactor has just created the response model the result of a
computation it's going to pass it out through the boundary object to a
presenter object the job of the presenter is to organize the data within
the response model so that it can be displayed by whatever mechanism is
supposed to display it in the case of the web the presenter would gather all
the information from the response model and organize it into strings if for
example you needed to display money there would be a money object in the
response model but in the in the viewmodel being created by the presenter
it would be a string if it had to have two decimal places of accuracy it would
be the presenter that trimmed it out and round it and did everything necessary
and put it in a nice little format if it needed a little you
no sign in front of it it would be the presenter that put that little euro sign
in front of it if you had a date that needed to be displayed the date on this
side and the response model would be a date object but over here in the
viewmodel it would be a string already formatted by the presenter for however
it was supposed to be displayed if you have menus it is the presenter that
figures out the names of the menus if some of the menu items need to be grade
the presenter creates boolean flags so that the view knows which ones to make
gray in which one doesn't anything that appears on the screen is first created
by the presenter in a in a screen independent way and then it's displayed
by the view look at the view down here it's this fuzzy little thing you can
barely see that's because there's almost no code in it all the work has been done
by the presenter can you test that presenter create a response model and
the presenter look at the view model you have to have the web running to test the
presenter know you can test the whole thing you could test all your business
rules all your presenters without having the application server running the web
running anything running at 30,000 feet while sipping a gin and tonic and of
course you can do the same thing to the database you can create another
architectural boundary that isolates you from the database using the same
technique all the dependencies . upwards you've got an interface that that at the
business model level that knows what all the queries are names them as functions
the business rules call those functions they're implemented below the line and
talk to the database the only part of this code that knows the databases even
relational is the stuff below the line if you're using hibernate who's using
happening
that's below the line
that's not above the line in fact you take real care with this stuff inside
those black lines because that's the family jewels in there those are the
business rules that's the real reason you're doing this application you don't
let things like the database in there you don't let things like frameworks in
their stuff in there doesn't know about sequel doesn't know about spring doesn't
have little at auto wired sprinkled all over it doesn't know that you're using
framework extra framework why the stuff inside the black lines you keep yer
because that's the essence of what you're trying to create and that's the
end of my talk
are there any questions
