viting me to add red
I'm going to make a presentation is basically explaining what domain driven
design is about and what its main concern it so let me just start with
this fundamental point
why do we bother with modeling modeling is a lot of work and so it needs to have
a justification
we can't just do it because we like to do it and there are all kinds of
justifications people use is the sound working right sort of here
ok so a lot of times people will basically say we should do some good
design work here but we just don't have time
and this I think just makes no sense
the only way that you could say something like this would be if design
is a religion that is to say we're reason to do design is because it is
good it is virtuous but design is not a religion
if you don't have time to do design if the value of that time is not as
valuable as the value of some other time then you shouldn't be doing design so we
need a better reason than this
here's one that I believed for a long time that modeling and design do take
and sort of a hit
you know take extra time at the beginning but eventually you make up for
it eventually it will make you more efficient
I don't believe that one anymore because one thing that the agile people have
convinced me of is just out bad we are at forcing the future i think that if
the payoff for the design work is very far in the future by very far I mean
I don't know more than six months at the very most
then it's just speculation we need a better justification and this
so I believe that and my experience suggests that modeling and design are
often the quickest path to the actual goal that we have that goal though
what is that goal when you listen to you know are our most people here familiar
with agile development agile software development
yes nearly everyone and one thing that is emphasized in agile is focus on one
thing at a time one story or one basically feature and we focus on
getting a feature done delivering business value as they call and this is
of course a useful thing but it isn't really your goal
delivering one single feature would almost never be something you could
actually sell to a customer
maybe your goal is more realistically complete a releasable set of stories
with some acceptable level of bugs
this might be closer to your real goal and I think even at this level of a goal
it starts you start to see why you might need design of a certain type so because
you can create one feature without doing design work in fact it's almost always
fastest to do it by just taking the existing design making it work but by
the time you have done five features that way
you may already be is causing yourself some problem - 10 features that way and
you'll have a mess and that's why we need design but that's still not the
whole goal because of course we have to get to the end of that release we have
to release that and then of course they're going to want more
so then
we will want to deliver more value after that and if you've already basically if
you manage to create the first release but it's a pile of that's a mess
then then you have accomplished your real goal and then finally there is
another goal which is to deliver a cohesive user experience and for this we
need more than a pile of features more than a kind of mixture of things you can
do in all sorts of ways you need some kind of clarity and clarity comes from
modeling and design so most of the projects that people work on in software
today the critical complexity that limits their progress is in the domain
itself
this is what I have observed
now there are exceptions to this there are projects where the critical
complexity is of a technical nature
there are also quite a lot of projects where there is no critical complexity
this thing is pretty simple that you're doing for those kind of projects
domain-driven design doesn't really apply domain-driven design is really
specifically for addressing complex domains and
that turns out to be a lot of what we do and i'm going to give a an example of
concrete example of how this works
so in this example we are working for a shipping company shipping company that
transports the standard containers all over the world
you know the customer puts their cargo in this container and it's gets loaded
on a ship like this and transported and transferred in ports like these onto
trucks and on the trains and this is how car gets moved around the world and we
work for a company such as that and we write software for them
now you can imagine that this is a complex business and so there will be a
lot of of software of various kinds and here is sort of a typical use case
customer calls and says I'd like to move a cargo from the car
hong kong to dallas texas and our clerk puts that into the computer and the
computers is all right
your your cargo can be loaded onto vessel which ABC to get to long beach
california and then it will be transferred onto a train
XYZ to go to Dallas and the customer says that sounds good book that there's
our first use case and so now we could start to talk about how to design the
software that would handle this case
now there's one other thing we need to look at first because of course we
already have software that does this right this is a you know 2011 and we
have software that does everything so it's not a matter of Rights and software
that does this design some software that does this
it is to modify some software that does this in some way
or perhaps write some software that coexists with the software we already
have and that's a lot of the challenge so we really can't ignore that
so here's a very high level view of the software we have that addresses this
problem when the cut
when the clerk is putting it in you know putting hong kong dallas in he is
creating this cargo object the cargo object is passed to the rotting service
which figures out the steps to get from Hong Kong to dallas and the Browning
service ultimately populates this data table called cargo bookings
now this kind of design is very common
it's not terrible design it is in fact easy to explain for example to group
like you but it has some drawbacks which i think is illustrate domain-driven
design pretty well one way of looking at it you can look and see well this is
very side effect driven design so by side effect I mean that when i call that
writing service
it doesn't return the value or any such thing but it does a very complex
calculation followed by updating the data table and this kind of combination
of a complex opera complex calculation and an update to the state of the system
is very risky way of going about it so that's something we'd like to fix and as
technical people we can spot that that's the kind of standard design principle
but there's another way of looking at this
which leads us too much the same place but i think is more deeply connected to
the domain model and that is how would we talk about this design
not with the room full of software architects but with a businessperson and
expert in shipping so
we might start off much the same way that first explanation that i gave would
still work
I'd say that we make a cargo object we pass it to the writing service the
routing service figures out how you get from Hong Kong to dallas and it puts the
answer into the database but that's not a enough detail for the conversation we
need to have with them
we need to have conversations with them about for example well what would
correct answer look like
and so then we could start talking about integrity constraints within that
database table or we can start talking about any number of things which don't
appear here at all
but anyway you look at it
we're going to have difficulty having that conversation with a business person
and they will either have one of two reactions almost every time a common
reaction of course is that they have kind of register that this is a
technical issue is not really the part that they need to understand and they'll
just stopped listening
politely you know that will not and this means that we are going to get the
information we need another possibility is that they've been through this a few
times they understand what a database table is they understand these things
somewhat and they actually find it kind of fun
and the next time you ask for requirements or an explanation of the
business they will proudly present you with a new database schema
this has ever happened to you ok
you don't want that we want a different way of communicating with the business
people and when I look at something like this
I come to this point and I say to myself what concept is missing
what concept is there in our implicit understanding of this business or in our
business persons understanding that is not spelled out in
design and there are few and they're the reason that we are having to talk about
database structures and so forth instead of talking about the shipping business
so what I am going to do then is I'm going to have a conversation with a
business expert on the subject of this but i'm not going to go in there and say
well look here's our design you know what concepts are we missing here
I wouldn't that wouldn't work at all so there are all sorts of ways in which you
can try to engage people
this is a kind of a whole important subset i would say of being an effective
software designer is becoming good at that kind of engagement with a non
technical expert in their business but one thing I often do is I try to go in
with a few ideas of my own
so where do i get those ideas but one thing I do is I listen I listened very
carefully to the way people talk about their business domain
I listen for differences in the way we explain what the system does and the way
the system actually works there usually are significant differences so that when
i explain to a business person or anyone else
what this software does I say something like give the routing service the
required origin destination arrival times on that part corresponds to what I
see and it will look up the stops the cargo has to make and put them in the
database so that
what does the routing service do it looks up the stops
but you don't see the word stop in our design
you don't see any object called stop you don't see a table called stops there's
no artifact in our system called stop
so this is one of those implicit concepts
it's something that we use to explain how the software works but it isn't
actually how the software works so maybe it would be better if it if the software
did work that way
so there's one possible idea
so I'll go in to this conversation I'll kind of try to explain what we're trying
to accomplish and i'll put up my proposal
I think perhaps that cargo should actually have a series of stops
what do you think and of course the business person because I paid some
attention will say yes that makes sense
so yeah we're ready to go now
that actually is what often happens my first guess will not be stupid and so
I'll get confirmation of the sort
and then the mistake would be to just stop right there
because often I see that people get to the first usable idea and then they stop
but to get to the kind of model that I want
we can't be that can't be that easy to get the kind of conversation that I want
then I'm going to have to do a little more
fortunately as i said i've been listening and sometimes people don't
refer to the stops the car would make sometimes they refer to the legs of the
cargoes journey
so I've got another proposal
how about this a car goes itinerary is a series of legs
so a leg goes from one place to another on the particular transport
now i think if i had presented this to the business person first he would have
just said yes that that sounds right
just like with the stops but with two
it's no longer a yes and no conversation now we have to discuss people
what would be the pros and cons of these two alternatives and what other
alternatives might there be and there might be a lot and i would try to get
that space of designs opened up a lot and
I would hope that we would lead to bigger variations than this
this is just to get it across the general idea oh you know when we talked
about it we really said that an itinerate that car goes itinerary is a
series of legs
so there's another term that is not in the design is not in the actual software
and yet we talk about it
so maybe a cargo doesn't have stops maybe a cargo has an itinerary and I
Tyrion and then itinerary is stops and so on
all right we could go on this way for some time open up the space of design
possibilities of model possibilities and then
so eventually at some point we have to narrow it back down again and choose
something which we are going to move forward with so let's look at this thing
stops legs
i know i would have opened up the design space more but given the very limited
time
let's just say stop so legs which is better so i always like to have a vote
because you know it's a democracy so stops her legs how many people say stops
how many people say legs
you know and I have no explanation for this
but nine times out of ten legs wins by a large margin in the folks someone else
can try to explain it because I've given up
all right so which is better well before I answer that question i'll digress
I want to talk about what a model is and not because you don't know what a model
is but because you know so many meanings for the word model right model can mean
all sorts of things you know
- a lot of people model is just another word for a UML class diagram
not to me though model can be a very good looking person who wears designer
clothes
that's not the meaning on
referring to either so I heard some disappointment about that one but
alright so model as I mean it is something a little abstract so bear with
me
now here i have a map of the world and it's a familiar map you can see on this
map all sorts of things you can see
let's say you know you can see spain and the united states so you can see kind of
the relative location of those countries and the relative sides and see you know
china is in the opposite direction
china looks about the same size as the United States which it actually is
so you know we're learning things by looking at this map you can kind of know
well there's green land it also looks about the size of the United States a
little bigger
there's Africa it's let's say about the size of well maybe a little bigger
about the same size as North America a little smaller all right
are all these things that I should learn from this map
okay does anybody object to my conclusion that green land is the same
size as Africa now
haha yeah this
yep
yeah right at so his point is that this map the distorts the size of things
which it absolutely does
so that things that are very far north or very far south
look bigger and things that are near the equator look smaller
that's the that's the consequence of the way that this map is made and so you
could say well then this is a bad map but it's a very commonly used nap and
now here is another map of the world
this one was made a different way and in this one you can actually see the sizes
of things so you can see that actually Africa is bigger than green left now
should we just use this map instead then this seems more correct but i think it's
fair to say that this map is used or was used more often than the other ones so
anybody know why this map became so popular
was it just because they didn't know how to make that map yet
what is it about this map that
mhm you do you create models by observing reality but if if that were
the whole story
then perhaps we'd have a map that would just be you know a photo of the earth
from space which we could make now and we can just forget about all these maps
that people made back in the old days
so but actually the people who made this map made it this way on purpose
they knew what they were doing they knew that
greenland wasn't that big and that africa was much bigger than
that so they had a specific reason for making the map the way they did
well I'll tell you what it was it was navigation now although this map does it
does distort the size of things it has a very interesting property any angle
between two places
let's say a line from you know
hong kong to long beach california to take the one from our example if you
measure the angle of that line on this map it will correspond to a compass
direction and if you kept your ship pointed in that direction from hong kong
you would actually arrived in long beach california and that's true of any two
points on this map
now the people who made this map then made it for that purpose and they didn't
care how big green land was they just cared what direction it was so they
preserve that property at the expense of preserving the property of sight
the people who made this map this map also has a an invariant which is that
the size of things is maintained so if you look at the size of some land mass
on here
it will actually correspond to the physical size of that land mass but the
directions are distorted this would be a terrible map for navigation
you would have to make adjustments for the direction of things depending on
your latitude so
let's look at what i mean by a model now I think that the model is not the map
itself although people often say you know the map is look like the model in
the world is like the domain
I don't even think the map is the model in our since the model is more like this
that we will approximate the surface of the earth is a sphere with points of
interest located on the surface that we will identify functions which can map
points on that surface 2 points on another surface on a flat piece of paper
or actually as they call this the cylinder because if you wrap around the
east and west meet and then there's a particular projection a particular
mapping function
out of all the possible infinity of mapping functions which we have chosen
and this mapping function has that property of preserving angles the
direction of points relative to each other
this is a model which can be used with a data set to make the map we were looking
at
so let's take a different data set and the same model and here we have
the map that mercator himself made back in the fifteen hundreds and you can see
that it looks somewhat different from the map that we were looking at before
but all the difference is just the quality of the data set and you can
really see for example that the that Europe looks very similar to the way it
looks on a modern map
that's because that's where they had the best data
Mercader was European in the European ships of course traveled more there than
anywhere else and collected more detailed geographical data so their maps
of Europe were very accurate the east coast of North America is recognizable
it's a little you know the scale is little off North Africa looks quite
close and so forth
you can really see where they had explored and for example the west coast
of South America is just guesswork right they knew there was a west coast of
South America
so they put it there now and Australia is not on the map at all although there
is something here because they had lost a few ships they knew there was
something they must be crashing into so they just put it there
this is what I mean though
when I talk about a model not the map but the concepts the set of abstractions
that is used to make the map from data that's what we do as in people who
develop software right
we transform data into various forms that are useful
so i'll define a few terms
the domain again a word which you know but which you probably know many
meanings of for us the domain is just some fear of knowledge is not a part of
the software it's not a layer
I mean sometimes we use the term
in reference to layer the software wing where we are trying to model that to me
so in the example the domain is shipping and a model is system of abstractions
that represent selected aspects of that domain
it's a distilled form of knowledge and it captures certain assumptions that
were making about the domain and it is a lot of choices that we've made
it's important to let go of the idea that our goal is to create a model that
closely reflects reality that is a a possible goal
that's the goal that for example some physics theoreticians have but it is not
gold it's particularly going to get us where we need to be
what we want is a model that is useful
so the mercator map the Mercator projection and the mat made from that
they are useful if you are a navigator the equal area projection which was the
other one I showed is probably more useful if you're trying to teach
children
geography but neither one of them is correct we could show a picture of the
earth from space and that might be correct but it would be less useful to
for either of those purple for either of those purposes
you know I don't believe it or not i think that's my phone
thank you
which is some kind of a first i think the speaker in a beauty there is a
zipper on the front of that bag and if you have to just hit it with a hammer
did you find it
ok it alright so back to the chase
okay sorry about that now we want to model that serves the use and I don't
care whether it reflects reality ultimately so usefulness is specific
I mentioned that that one map might be good for navigators another map might be
good for teaching school children
so it's the same with our models we can't say well you know it's matt this
model is useful we have to say it's useful for something so I like to always
when I'm talking about modeling in the domain
I'm always talking about some concrete example something very specific
a step-by-step example of a situation in the domain which is worrisome to the
business people in some way that causes them problems
another thing to keep in mind another sort of pitfall of modeling is to
remember that there are always multiple models of the domain
there's one domain but there are many models of that domain
just as there are many models of the earth
there are many models of the domain some of those models are just models that we
think about that we examine in a brainstorming session with a business
person should we use stops should we use legs
that's two models right there sometimes there's more than one model that we are
actually using for different purposes in different situations
and if we don't recognize this and manage it very explicitly then our
models become a confused tangle instead of things that bring clarity so i'll
come back to that in a minute but here is my question again but this time I
rephrased it
I actually asked you the wrong question stop sore legs which is better at this
point I think you can see why i will say that better it is not a word that
applies the models models aren't better or worse they are more or less useful
and usefulness
he's always in is always relative to some specific intended use
and so when we asked this question we have to say okay useful for what
and so I mentioned one use of his model which was that when the clerk put the
origin and the destination into the software that then the result was
described but it said go from Hong Kong to long beach on XYZ of Long Beach to
dallas on the other train and so that they use of the model and i would say
that that you could be accomplished by either of those models we could describe
that using either one of these so what we have here is two models that would
both be suitable to the task that we've described so at that point you can make
the decision on other grounds you could say well this one seems easier to
implement or maybe this one is the one that the business people seem to like
better i mean they that the way they talk more closely corresponds to it
although i don't believe that there
it matters whether the model is you is realistic
whatever that
means i do think it matters that it feels somewhat natural to the business
people so that if the business people find it very strange and artificial
that's a reason that I would like it so there might be other criteria for
choosing these two models which both seem to accomplish our purpose
however that is not the only thing we need to do with this model just
described the result of our so let's look at another scenario
so I'm going to challenge these models with a new scenario
another thing that we have to do alright so here was the itinerary that I that we
had booked for this customer they called they asked for to send the cargo from
Hong Kong to dallas and now the cargo is actually in the middle of the Pacific
Ocean it's on vessel voyage
ABC and it is on its way and the customer calls and says you know that
cargo that I wanted to send a dallas well I don't want to send it to dallas i
want to send it to seattle which is in Washington State
northwest oh well now what do we do
so now I was making this presentation one time and someone said well then we
need to improve the validation in the software so that we don't get the
incorrect destination in the first place and I thought wow that's such a perfect
example of the difference between domain-driven design and the sort of
technical way that we often think about it because he had turned what is
essentially a business problem into a technical problem
how do you keep incorrect data
I'm getting into the system is not incorrect data
this is the destination really was dallas and now it really is seattle and
you might ask a business person
why would that happen why would they change their mind about where they
wanted the car go to be and this too is a difference in domain driven design
I believe it's very important not only to understand what the requirements are
but to understand why they are the way they are why do they want to be able to
change the destination
well it might be something really straightforward well they had a buyer in
dallas and then that deal fell through that heel got canceled and so they had
to find a new buyer and that new bar is in seattle or maybe it's something more
interesting
suppose that this company has shops in all all across America and they have to
send the stock from hong kong someone in advance of when they will actually sell
it because it takes some time for it to not be shipped far enough in advance
that they don't know exactly what they're stalking needs will be in
different places so they make estimates and by their estimates at the time that
they had to book the car of the shipment their estimate was that they would need
to have more stock in Texas so they said send it to dallas texas
but now the time is getting closer they're models there to screw up their
estimates are getting more accurate and their estimates are saying we'll have
plenty in the house where we really need the stock is in seattle or rather in the
northwestern part of the country so they call us up and they change the
destination
and so when you hear that you think and especially if you've been working on
this for a while you think
then you're saying that we booked space on a specific train going from long
beach to Dallas
just because they thought that that region was where they were going to want
the material but knowing that even if they had if their prediction had been
correct they might have decided they wanted it in some other city where in
fact they'll split the car go up and send it to several cities in that region
it makes you think about a whole different way of approaching it you ask
the business person then why do we even ask them for a specific City at all
why not ask them for region if that's what they're really after
why don't we ask them for rough probability that they wanted in this
region versus that region we could write the software that would optimize the use
of resources for that instead of optimizing resources with the assumption
that it's going to this exact place and the business person says we know that's
funny you mention that because when i first started this job
there was an old guy who did the job before me who remembered a time before
we had software to do this and he said that they used to not write down a
specific City when they recorded the destination they would write down a
region they get this to the southwest and then when the time come with Kane
when it was like three weeks before it got to that place a week before they
would call the customer and ask them exactly where they wanted but then they
got the new software and the new software required you to put a city in
and so they adapted all their business processes to do that because it was so
useful to have the automatic routing that they are willing to give up the
flexibility but you know that was 20 years ago nobody actually remembers how
to do that business process now
well
you know it's worth asking these questions this opens up a whole other
now not that I'm going to go and change the you know whatever it was we set out
to do here
change destination we still need to do that but now we're into a different sort
of conversation that in a in the medium term could take this software in a very
different direction is the business even realize that it is possible for us to
change that aspect would they be asking us for the particular features they are
asking is for if they knew that they could have this other thing instead this
regional destination
all right well this of course is not a solution right send it back to Hong Kong
and start all over again
you can do that with data packets on a network but you can't do that with
cargoes what we'll have to do is something like this we will have to say
all right that thing is going to get to long beach california one way or another
and then then we can find a way to send it to seattle instead of dallas and so
what we'll do
and this would be a way of explaining it
we will cancel the leg from long beach to dallas and replace it with a leg from
long beach to Seattle as the picture shows
now at this point and just by the way I used language to describe the solution
to the problem
I think you can see that the leg model fits this problem very nicely and since
it was more or less neutral on the first one and it's seemed now I can do it with
the stop also
but with stops it gets awkward to describe what the change is in long
beach because in long beach
the first part of this stop will remain the same but the last part of this stop
will change and so if it's represented as an object would kind of like to have
objects that we can pull out and replace whole rather than operating on
meticulously so basically for this particular use i find this model to be a
better fit
so a little bit of refinement and we have a model which would look like this
in a UML class diagram cargo has an itinerary which is made up of a sequence
of legs
we passed the origin and destination into the routing service and well
actually at the beginning the cargo doesn't have an itinerary but then we
pass the origin destination into the routing service and the routing service
returns an itinerary so the writing service doesn't touch the database now
so there's no side effect here
what we could make the routing service put this in the database if we wanted to
but it would be a very displeased distinct step
no longer intrinsically tied to the calculation now
so if we want to discuss with a business person for example what
what are the rules that make an itinerary correct
for example maybe it's a rule that if you if you have a leg that in
in one location then you need and leg that begins in that same location unless
it's the last location
so you can discuss rules like that
you can discuss the rules like that very easily with a business person but you
couldn't so easily with the previous model when we get to this point where we
can talk about the model rather we can talk about the the way the software
works with a business person and it
it's true to the way that is actually built not just a pretty picture on the
wall but an actual description of how that software works in terms that the
business person finds to be straightforward and and helpful in
thinking about his business
when you get to that point we call that the ubiquitous language and that is one
of those fundamental principles of domain driven design the ubiquitous
language is this notion that that we should have one way of imagining of
describing the way that this software works
not one way we explain it to the business people and another way that we
actually do it in the code and yet a third way that we draw a pretty uml
diagrams and none of them match that one
not in a really
by the way sort of naive kind of literal way but in terms of the language the
description and
the way things fit together now
it could have gone another way if I had chosen a different case let's say
something about the management of cargoes within the ports
then you might have said stops are really more useful for this because it
lets me drill in on all the details of what's happening in the port and so you
might have chosen a model based on stops instead
but we didn't we looked at that rerouting scenario
now although I i think that there's a that people can accomplish a little bit
more in terms of a broad survey of their scope and they can factor that into
their modeling somewhat ultimately we must recognize that there will be
scenarios which you won't have accommodated in your early modeling work
so we have to be prepared for that there will come a point in the project where
you say hmm I wish we had done it that way but now you're fairly far along
you've already written software
this way there is a common sort of mistake that people make when they start
thinking about this
I think we have to keep modeling until we're sure we've covered all the cases
and that we have everything just right because once we write some code we won't
be able to change it and we'll be stuck
I think that this this is a mistake
it's even a non sequitur I say it's a non sequitur because get the model right
before you write the code i think is actually impossible and
the reason i think that is because software development process project is
a learning process
you learn so much as the project goes along and a lot of that learning comes
from the experience of having built working software seen the interaction of
the software with the people or even putting it into the field and seeing how
the business reacts so much of the learning comes from that that you'll
never get to the point where you really understand what needs to be done until
you have something working
so in this i agree with the agile people but the trouble is that it's very easy
to paint yourself into a corner or two
got yourself in a situation where you can't change what you've already done
now I don't have any magical answer to that because I think it's one of those
intrinsically difficult things i think that there are a lot of basic modeling
techniques which helped a lot and and maybe a third of my book is about the
modeling techniques that I think make a difference there
but just remember that if you think of a model as a distillation of knowledge
then it makes no sense to say that that's the first thing we must do
because all you're doing is taking the time when you are the most ignorant and
distilling that ignorance so modeling up front
doesn't work however i will readily acknowledge that you can be very
difficult to change what is already there
there is a
diagram which i won't go into any detail for a lack of time but that tries to
capture the sense of what I was just describing
so there are these kind of you know how the waterfall process has captured the
imagination of software development for 40 or 50 years now
well I figured if people want violent water metaphors
they should have them so i present to you the whirlpool
just another kind of violent water but it doesn't go straight down crashing
down the hillside
whatever reason you would want to go crashing down the hillside but seems
compelling to people goes around and around and around and it basically what
i just described
you could start anywhere in this but you might start with a model that you
already have challenged it with a new scenario
refine that scenario generate new models and so on around and around code probe
is my term for when you want to learn something that you think you will learn
best by writing some code
you know what i mean by that because all this you know there can be some logical
flaw in your reasoning that is so subtle that you won't find it in 10 years of
standing at whiteboards and drawing in modeling tools but but the day that you
try to write even the simplest skeletal code that actually works through the
logic
it will be glaring the obvious and so we need to get good at that kind of X you
know code that isn't meant to be
production code but it's just meant to test some idea experiment
all right now we're coming toward the end of my time and so I want to talk
about a very important issue and that is we have a tendency to want there to be
one answer that to unify our software with a single mob and i think this is
one of the things that undermines our success with modeling
so there's a story which i think everyone knows about the blind men and
the elephant
so there's an elephant and various blind men touch the elephant in various places
one touches the side of the elephant says an elephant is like a wall one
touches his trunk and says the elephant is like a snake one touches the tail and
says it's like a rope one fish is the leg and says it's like a tree and so
forth so representing this in uml we have four models of an elephant
now what happens in the story is that the blind man began to argue about which
one is right
the guy who says they that an elephant is like a wall and the guy who says
elephants like a snake
they become very intense and argumentative about what the IR what the
elephant is really like but to me they're making some basic modeling
mistakes and if these were domain-driven design modelers i would say that they're
making two basic mistakes
the first mistake they're making of course is trying to figure out the true
nature of the elephant but they really should be looking for is a model that is
useful to them
some way and to be useful we need to know what it is they're trying to
accomplish
let me give an example
I do a lot of financial software so one of the very common things that financial
clients want is they often are trying to estimate risk identify risk in various
ways
so let's suppose that risk assessment were an important goal of this model
all right well what kind of risks are there standing near an elephant
you might be concerned that you would get stepped on well the guy who's
standing next to the leg of the elephant actually said that it was like a tree
trees don't step on people trees are removable his model of an elephant in is
actually not going to be useful for purposes of estimating risk
let's see what other risk issues we might have will snake
now if I were standing next to a snake i might be concerned that the snake
maybe it's a venomous snake maybe it will bite me and so i might based on
that model start to you know protect myself well let's make sure we have
plenty of snake venom snake anti-venom on hand so you start to invest in
protection against this risk but of course there is no risk of venomous bite
from it from an elephant so this model has thrown us off of effective risk
management because in the one place that we know we are where we should be
watching for dangerous being stepped on
we're not because
trees don't move we're spending our energies protecting against venomous
bites
ok so this is an example of where if that were our goal we could start to
assess these models and we could probably eliminate the three and snake
models as being not only not useful but actually counterproductive against what
we're trying to accomplish so that's one you know we need to know what we're
trying to accomplish and then choose models based on how will they accomplish
those goals
the second mistake they're making them is that they insist that there is just
one model of an elephant it all wanted to be
of course their own but they but passes now if we had these for
sorry I keep changing the slides we had these four models of an elephant and
they were all being used
what's so bad about that so far we have no reason to think that there's anything
more than just four guys standing around talking about elephant's so we could
have four different ones and often in our software systems we do have this
because if you develop one system with this team and another system with that
team they will have developed two different models
if you buy some software off the shelf and then integrate with that
that'll be another model so you have multiple months in your system already
the risk comes or that the problem comes when people start to mix the models
together
if you start to think about more than one of these models at the same time
without carefully keeping the distinct and this is where a concept called
bounded context comes in
the idea is of course from a language perspective you know that context
determines the meaning of the words we say if i say i'm going home
if I said here and now you might have a hard time interpreting what that means
if i set it at the end of the day you might think well it probably means that
he's going to his hotel
if i set it at the end of the week or at the end of the last session on Thursday
you might think it means he's going to the airport to eventually get to his own
house
the interpretation of the phrase I'm going home depends on the context and
we're very good at picking the context out but when we start working on
software then it becomes much harder
so we have to be explicit about things and that's what a bounded context is it
says okay none of this subtle
I will infer the context and therefore the meaning i will explicitly state what
the context is so now if we have our four different models i will say that
under these circumstances you will refer to an elephant is a kind of a tree and
it is these circumstances you will refer to it as a kind of snake it might be
that the those circumstances might be if you're looking at this subsystem you
talk about snakes
you're looking at that subsystem you talk about trees and that's all you need
if unless you have some reason of course to integrate those systems as soon as
information is flowing between the systems then you need some way of
translating but one of the principles of this then is that we do all our
translation
at that boundary so we talk about trees and then we're passing information over
to another context we change it into wall in this case perhaps all they want
to know is where is this elephant we're going to have to come back here tomorrow
and continue arguing about the nature of elephants
so we need to agree on where it is we don't have to agree on everything about
it
about what kind of creature it is we need to know where it is and this one
guy has called that location and he specified GPS coordinates and the other
guy calls it place and he has the street address
and so we create a translator and when this set of guy says the location is
longitude x latitude why our software translator figures out that means that
the place is 74 pine streets
ok and this will work
now at some point we have a breakthrough we realized that these different
these are the reason that these different models of an elephant are so
different is because this is a big multi-part creature and they're touching
different parts
so these are parts of a whole and we come up with a new model the unified
model of an elephant
ok an elephant is a kind of wall held up by trees with a snake at one end and a
rope at the other there you have a single model that encompasses the
knowledge of the other floor
now this of course is kind of a joke but at the same time I think we should take
this joke rather seriously this is better than most of the models that I
see on software projects
serious and we should value these kind of models because their acts they can
actually be very useful
going from that earlier model to this model could be tremendously useful now
does it reflect the true nature of an elephants
well not not according to the and the way I have come to think about elephants
in my life but you know we would have specific scenarios and we would be
assessing whether it addresses those scenarios
now does that mean that i'm going to replace the other four models with this
model now we have just one model no
now we have five models of an elephant that's how many models we have now that
there is this urge we have to unify and we're going to i know we're going to
want to make a single enterprise model out of this one but resist that
temptation
maybe we can phase out one of those other models at some point maybe we can
get rid of that snake mom
let's not get greedy all right now I know the model you were expecting
something much more like this
I'm elephant is a kind of animal animals have tails and legs and an elephant is a
special kind of animal that has a trunk as well and this kind of model can be
extremely useful but it doesn't come along all that often so you shouldn't
bet your project on this kind of model emerging you're much better off if you
can succeed with the tree snake rope models and keep iterating keep pushing
always looking for that deeper inside because the process of challenging your
model with yet another scenario of
having some insight refining the model changing this code to reflect that model
using the software some more that cycle of learning does sometimes break through
to this sort of model and it's fantastic when it does but i'll tell you i've only
had a handful of those kind of really deep profound models in my career
so most projects never get to that point
nor do they need to so we set ourselves sometimes such lofty goals that they
actually interfere with making models that are very effective and also not all
of a large system will be well designed this is an important thing to keep in
your mind
so when we get to that point where we do have this model that doesn't mean we
have one model which we are now going to replace all those other models with it
means that now we have six models of an elephant right or if we phased out the
snake model then I guess we have five again we have to be
or perhaps this one does replace the immediately preceding one right so then
we would only have four but we do not have one number one
it's ok that some little part of the system is still using this obsolete
notion that it
elephant is a kind of wall it and this other part is using the notion that an
elephant is a kind of a rope because those are probably not the areas where
the real innovation is happening now they're within a nice bounded context
the integration is worked out we can focus our energies in whatever area is
that we really care about with the boundary around us that allows us to
keep refining you know to the point where we get some some semblance of that
model because there are parts of the software where design really does matter
where that hole cohesive user experience and the ability to continue developing
in the next iteration and next and the next release does matter
it's not all across the system
all right well there are a few places that you can go to find more information
about these things that whirlpool diagram I showed you is on the website
that i put here that same process although not described quite the same
way is in is in my book in section 3 then there's a very extensive discussion
about bounded context in chapter 14 of my book which i'll have to say that was
one of my little mistakes in writing the book to make that chapter 14 because
it's important than it should have been earlier in the book and most people
never get to chapter 14
finally I'll point you toward the DD community website that has various
articles and all sorts of resources
so on that note I thank you for your attention
I look forward to seeing the rest of the conference
