Eric Evans: What I've learned about DDD since the book

March it's the August we march but I'm really learn much in the last four weeks
or so so this will be for the last six weeks I mean so this will be close
enough
I did it at q con london where they add a DD track and that was quite
interesting one of the patterns in the book
his hands on modeler and that means that people who are involved in the modeling
process for a for some software should be involved in the development of that
software they should be hands on to some degree not saying that everyone has to
be a full-time programmer but that they should be they should get in there
to some degree and in my case it means that i have to be involved in real
projects and involved hands-on sometimes have people want me to talk about
strategy and you know the big picture of their system and that's mostly what they
want from me but I tell them that you know I have to also have some contact
with that ground level or else i'm not going to give good advice or on another
level if I don't have any involvement in project and some hands-on experiences
I'm not going to stay sharp and stay up to date and keep learning things that I
can talk about it so it's very important to underline that every effective
DD person is a hands-on modeler including me
and so a lot of things i'm going to talk about are not exactly different from the
book especially the things on this list but with a little different emphasis and
one thing that I think I've learned is better how to pull out those things in a
500 page book which parts are really really the most essential and i'll start
with this one which is pretty early in the both to bring about a creative
collaboration of domain experts and software experts now what patterns in
the book would be related to that anybody
somebody say ubiquitous language please
it didn't and when you thank you
ok there would be one and quite a few of the patterns are actually about creating
this creative collaboration of domain experts and software experts delicious
focus on that one because we aren't content to just create an elegant model
ourselves and i'm assuming that most of the people here are the software expert
side of things
anybody here not software person like you're involved in the more in the
business side
everybody here is software
exploration and experimentation so many times and still is a you around this all
these projects and they're trying to do
ddd and so on and one of the ninety percent of the time they are not
experiment and they'll do the process
sort of and then they come to a point where they have a good model
they have something that's useful they stay there
we're done but the first useful model you encounter
what are the odds that that was the best you could have done
you know you're you're just you just you've just gone to the very first good
idea
and so people need to do a lot more that and then they get that one and they
start building and they never look back
but next week when you start to get a glitch or to do you say okay we can work
around this we can work around that and you've already frozen yourself your mind
into that shape of that original model and so you're already working around its
limitations
instead of challenging and in saying it doesn't handle this case very well let's
go and look at what the options are and I mean blasting wide open because you
might discover a much better solution or you might at least discover one that
will resolve the current issue without lots of additional complication
this is an exploration process exploring alongside our partners
the domain experts
and then there's this round and round thing that language of balls and the
model balls and then we you know dive into the thick of things for a while and
things get a little confusing and then you explore again and then you come back
to the model and the ubiquitous language you might discover that it's hard to say
something you know this new case comes up and your language doesn't quite
capture it concisely you end up with a big complicated explanation may be a
complicated explanation and carefully written kind of standard English but you
saved my ubiquitous language
I mean like I want to be able to say these things crisply and unambiguously
time to go back to exploring and to you explore with somebody can save him
thank you good he'll break down all right explicit context boundaries
this is in the book sadly it's in chapter 14
most people haven't gotten that far in
so yes in chapter 14 and talks about the importance of explicit context
boundaries if I had it to do over again that would be in chapter 2 or 3 and it
is so important because just like the just as a language you know just as a
statement in a language makes no sense
just floating around by itself models make no sense just floating around if I
just laid a UML diagram on the table and said tell me something about this
you couldn't answer any useful question you could just you could guess and you
could you know you but which would be guessing it would be the context within
which it should be and then
but if i told you a lot about the context then you can maybe make some
statements about this could be useful for this but what after all back here
without any context without any notion of the application its relationship to
other modules within the system so if you haven't already done so i urge you
to look into context mapping i think it is perhaps the one thing in there that i
would say should be done on every project
I've never seen a project that i wouldn't have done a context nap I've
seen many projects why would not have done elaborate object modeling or any
other time but I never seen one that wouldn't benefit from some kind of
context map and finally focus on the core domain that's chapter 15
sadly but the core domain is these is one of those kind of soft sounding
things find the differentiator involved in your software right how is your
software supposed to change the situation for this business you're in
and i don't mean well we're going to be able to save five percent a year over
the next five years
by doing this process incremental e more efficiently
I mean that there was a whole new market that we could get into if we had this
software or weekend offender market share from that of the guy who can get
it
something significant ok this is the list that I come up with if I had to
give up everything else
these would be the things i would focus on improving the relationship of the
domain experts and the software experts making the whole process more
exploratory and experimental which end and especially in regards to keeping it
connected with ubiquitous language nailing down the context boundaries and
really focusing relentlessly on the corner of Main moving on
there's a section in the book called the building blocks and this is talking
about the problem of all right I'm modeling and in a sense are modeling
paradigm is too general
in a sense it's just saying what we have objects we have relationships between
objects and this is just too broad
because what we want i think is something that structures that a bit
more puts things into categories helps you make some shortcuts
good guesses helps communicate the nature of your choices
so you say that so there's a handful of these patterns
Mike value object you say is a value object and someone else who knows these
patterns will immediately be able to him for a lot about that
so communication is better but also people through experience have found
that certain kinds of you know characteristics of objects make them
more useful are concerned kinds of relationships tend to be good solutions
to certain problems and so you leverage that and the consistency improves of
your modeling and you and you're better able to communicate about it and
collaborate with people and this is all well and good
it's i think a pretty important thing when you're trying to get down to that
nitty-gritty level of making software that really reflects the conceptual
model is part of what we mean by the ubiquitous language right that it goes
all the way down if I talked with a domain expert is the same language as I
would if I talk to another software person and even if I talk to the
computer
so to speak in terms of a computer of programming language
these kind of patterns help you to make that part work well
so what have I learned about the building blocks
well the first thing I think is that they are over emphasize although I do
think they're important people get very focused on this is one reason no one
makes it to chapter 14 because they all get stuck in chapter 5
which is where the building blocks really get going
and so they're overemphasize but heck let's add another one because the set
wasn't quite complete may still not be complete you know I don't pretend that
this is a the final word on anything and one particular one has emerged over the
last few years as being really an important ingredient when i was writing
the book there were these things and they made me uncomfortable
oh we're kind of wanted it to be an entity for those of you who aren't that
familiar with it don't worry about this part because they're overemphasized
anyway
and maybe you wanted to be an entity but you kind of wanted some of the
characteristics of a value object in the ability perhaps and neither one really
seem to capture and so what has come along and yeah there was an enabling of
this even before the book but it's really become clear to me in the last
few years is we need another category another building block and we just call
those domain events
so here's a picture and think that I'm focusing on here is this the scoreboard
there's stuff happening here this is the domain domain is the baseball game
but Sir and not everything
like let's say that this is recording that there was a someone had a ball and
are they had four balls they walked in other words they go to first base
so you could you could record that the person took a step and then they took
another step and then they took another step and then they took another step and
another and another and another and then they got to first base but no one is
interested in
that right the domain event like anything in a model zeroes in on
something important to the domain experts remain expert cares that someone
reached for a space that care that there was that there were four balls or
whatever or maybe there was a strike or three strikes and this guy's out and so
but you know along the way to the strikes
well being out of the guy sway back and forth and he raised his bad up in all of
these events in fact in our systems in order to make them work
there's all kinds of little events firing this way in that way
that's not quite what we're talking about here all right we're talking about
that level of event that you want to record it was something important
happened in the domain and they have a kind of consistent form to like they
tend to happen at certain time they tend to have some person associated with him
maybe the person who recorded it may be the person who did it
maybe both maybe a time that it happened in a time it was recorded there and they
are also typically immutable you record that this happened and that's it
the record that this guy struck out and that's it you don't go back and well you
could go back and change it if it turned out that it was an error that you
entered something incorrectly but you don't go back because oh let's just you
know I don't know you just don't
so with domain events we get clearer more expressive models but we also get
some very interesting architectural options and this is another thing that I
think has become more important
over the last few years because finally after a long wait
after expecting it for a long time distributed systems really are happening
now that's really an important thing that many of us have to deal and the
main events are really valuable for that
so because they
ok so let's imagine a kind of an extreme approach or we say that you don't just
modify the state of objects you
you have events right event happens and as a result that date is different
so let's suppose that you know looking back at our scoreboard and the bottom
line is this
this score and the old school way would be that you know basically each team
against an entity in their score is a value that they would have and it goes
up and someone gets a point that's really all it can to change the two two
three three runs but in this world
we're saying well maybe the run is an event so the the run is recorded and
then if you want to know the score of this team
you look at the runs right where did what events have happened and everything
this might be useful imagine in a distributed system where maybe the
equivalent of runs are being reported from different places
now you can't have a 100-percent consistent view in a distributed system
at all times but you can
but you can deal with that if you've got a very well-defined event model so runs
are coming in and you report the score according to the runs that you've heard
about now maybe run happens since you know that hasn't yet reached you
maybe you've gone off to the concession stand and someone asked you what the
score is and you tell them but there was actually a run that happened since you
got to the concession stand and then when you get back you see
oh I see the day always someone says to you know that's wrong you know there was
a run since you left
ok now I update my score and this is is really vital if you know in in these
kind of distributed systems have some approach like this because if you are
trying to maintain a consistent view of this entity across distributed system
you it it can be extremely complex but with the or it can be fairly simple if
you if you have more event already few representing the state of entities
decoupling subsystems with events dreams now here I mean designed a coupling
I'm not talking about the runtime the decoupling of run time that this allows
that is you know you've actually got these things running over here these
things running over here this thing running over here and events are going
back and forth and nothing is in a completely consistent state but it is
you know
well characterized this is the more conventional argument that all right we
have a system here let's say that is managing trades trades are happening and
that's a big job and over here we have a system that is kind of analyzing doing
metrics
maybe writing reports for people so they can know what's going on here
now one of the basic problems that teams have is that they will wire they're
reporting
analysis and all that and they just wire it right in to that transactional system
will query the database and and and the result of that is that now the
transactional system can't be changed without changing all a bunch of reports
or maybe the needs of reporting will constrain the designs they can choose
and and I'll end this is extremely tight coupling and yet it isn't really needed
because the the actual needs of the reporting
don't don't call for in particular functionality in that at that sort they
just needed that data
well what I've seen more and more often and I'm convinced it's just a really
nice solution to this sort of problem and other kind of similar problems is to
say okay you have your core transactional system or whatever
some place that you want to in capsulate and stuff is going on here and you just
constantly send out a stream of events domain events that are describing the
important things that have happened inside your module
now over here analytical people the reporting people then they can subscribe
to events they can filter the ones they're not interested in they can take
the ones they are reorganize them in any way they want and put it into their own
database to normalize put it into a data cube if that's what they like and if you
change your internal system will find the only thing you're really committed
to from their point of view is you're committed to maintaining that stream of
events
so if you want to change your definition of something that's in the event stream
you'll have to coordinate with them much the way you would have had to do if you
want to change your own database but now that's the only thing you actually have
to coordinate on this kind of decoupling not just between you and that one
reporting database our system but between you and any other system that
might be doing things in response to the things you're doing
I don't know maybe a clearing system so over here you're doing the trades and
over here you're doing the clearing
well the clearing system could receive a stream of report of events from the trip
trading system and use those to base that on
and then those two systems can evolve independently at each other don't
remember don't forget not only does the transactional system get all bound up
because it's tied too closely to the reporting system reports are highly
constrained to because they have to live within existing transactional system we
might have a model that is just really good for managing matching orders and
and executing trades but maybe it's not very good at all for reporting and if we
link these two things together would order for a week if we link these two
things together we end up with kind of a compromise
that's not all that good for the one hopefully good enough
instead by this level of the couple you can have a model that's very good for
trading and model is very good for analytical our analysis of those traits
or reporting what happened and now come back to that context map thing that i
mentioned in my first list of essentials the context map is the thing that helps
you keep track of the different models are using make sure they don't get all
mushed together into a mess help you it just make that effective multiple models
existing on the same project in a very effective way
so these things sort of start to weave together see that context map is so
fundamental
this allows you to you know d couple two systems so that you could potentially
use two different models there
you don't have to can still be a useful can still be a very useful technique
even if you are using the same model let's say for trading for clearing but
if you really want two different models and it's a great way to communicate
between these two contexts
okay there's one more about these domain in events which i think is really
important and that is there are some extremely high performance systems out
there and in the past and certainly when I wrote the book i would have said I
think that that is outside the scope with DVD i think that when you have to
handle truly high transaction volumes or that you are probably just with current
technology and how you just can't keep up with it with the overhead of an
object-oriented system more elaborate models of that's a luxury that you may
have to forgo but I don't say that anymore because there's this guy greg
young who I who has presented a few conferences
who built this system it was oddly an operating system guessing them but that
that's where a lot of the TD action happens is in financial industries and
he and to handle tens of thousands of transactions per second and he didn't
give up though on objects in fact he wrote the thing in c-sharp with C sharp
object and mostly pretty standard . net frameworks
but what he did was Eve he went to kind of radical extreme of this style of
representing domain events or really any kind of change to anything as a distinct
object so anything that changed he would just say well there's a new object and
his even his entities didn't actually ever change
they they had collections of of these little events
so every time you go would so to take mice tired old example of the trading
system but you have your order book and you say got in order and somewhere over
here we actually have a partial field so the order is now reduced but he wouldn't
change in the order say the order was 10,000 shares and you've executed five
thousand you wouldn't change that to 5,000 remaining he would just take the
execution 5,000 share execution and you witnessed
let's put it in that collection now you can compute that 10,000 - 5000 and it
turns out that this this and a few tricks that he can explain for a better
than I can
I was just an amazing effect on your scalability and he he said that he
mostly as I said use off the shelf . net he had to write a custom message queue
the ones that they had were too slow for gene and so he did that but other than
that it was pretty standard
now i'm not going to try to explain exactly what he did because there
I'm not very good at explaining it first of all and secondly we don't have time
but i just want people to be aware of it and who knows maybe you're working on
something along those lines and then you can look that up
ok still in the subject of the building blocks but not those
this is the most abstract of the aggregates
I think this is X is super important the aggregates perhaps the one building
block that isn't over emphasizing on here a lot of talk about it except for
one question which is how do you access the things inside the aggregate it's the
one question everybody asks all the time and I've almost lost interest in that
question because I think it's not actually what's important about a girl
it it is one of those things that helps you to enforce the real rules
what are the rules in aggregate will you might
so what is an aggregate first of all for those who are not up speed and
aggregates kind of like these grapes in the sense that you have a something you
think of as a conceptual hole which is also made up of smaller parts and then
you want to you have rules that apply to the whole thing so every one of those
will grapes is part of this great bunch in fact in French the word that the
cognitive grape actually isn't really cognate it really represents this
so it's one of those funny kind of examples of the word that's almost like
the other one just the way that would be most confusing
now the classic groups
the classic example of an aggregate might be a purchase order where the
purchase order is a hole might have properties like well let's say the
purchase order has a limit
we've approved five thousand dollars for this proof of purchase order and then
there's an amount that it has in it what we've got line items in this purchase
order that add up to three thousand dollars and all is well and good and in
a traditional Oh system this is actually one of those common examples and
well you add up all the things in the purchase order object compares that name
with the limit and decides whether this purchase order is valid but what if you
have like say thousands of line items in a purchase order
this is one of those places where classic Oh kind of stuff is it still a
little I think
do you want to bring in thousands of objects in order to add up one field and
then compare it to another number because that's kind of what the hour
mapper whole approach leads you to
and there are many cases where I've seen this basically this sort of thing is
part of what torpedoes sincere attempts to do DD because they run into a few of
these things and they start to think well this just isn't practical or they
say what will keep doing that modeling stuff but meanwhile we have to do this
other thing
so they'll have a query a simple some in there sequel database will do the job
and then put it in the service probably and you know so all of a sudden
what you've got is you've got anemic objects and he make objects meaning they
don't really do anything they carry some data around they're basically fancy data
structures and all the action is happening in some place else may be the
services
well so the aggregates is saying you know there are things bigger than an
object that have a cohesive wholeness to those things we want to
they have their own properties and they have their own room
so in this case purchase order as a whole has a in an amount that's it
bordered the ordered a man now you can say what it
how do you define it because it's the sum of the amount of every line on it
that's the definition if I think of a model more abstractly as opposed to the
object model where I have to say this this route
purchase order object the root of this aggregate owns these other objects and
is responsible for collecting together all their individual amounts if ice
don't quite go that
oh I think that's over specifying the problem or the the model
what you're saying is in fact that there is a property of this whole collection
and that property is the sum of the amounts if i stop there
I leave the door open to different ways of finding the answer to that question
what is the sum of all these amounts it really maybe that I need to do a sequel
some but I can put it in a more natural place
maybe in book even i mentioned the possibility of having repository queries
like count and some but some people I've seen have experimented with having an
object that actually represents the aggregate itself but they give it a few
extra privileges they'll do queries from that object and I don't know
I honestly don't have a strong opinion about how to implement these things they
do have a strong opinion that you need to loosen up a little bit when you get
to this because i think it is a week . in the 00 paradigm that o.o is a really
good at handling these little interaction
of objects of individual objects and it's not so good at handling collections
of objects big collections
now the course relational databases are are potentially really good at that kind
of thing but what we what we need to do then is think a little more abstractly
so what do we do
ok then when you start to think about an aggregate in the abstract
you're looking at basically this boundary within which we we see it as a
conceptual hole and we wanted to be consistent memorize talking about in a
distributed system
not everything is going to be consistent all the time but we need some boundary
where we know that it's consistent so let's suppose that we said that
well you know purchase order is one of these and we are going to have that as a
consistency boundary that means that we want to be consistent in terms of
transactions
well let's just stop there for a minute transactions that would mean for example
that if we had a transaction like release the trend to release this
purchase order so that part of that would be to check that the purchase
order wasn't over its limit
I can't release a purchase order if its total amount is more than its limit
so we add up all the line items we discover that they are twelve thousand
dollars but the limit was ten thousand dollars so there is the end result of
that transaction is maybe an error or some kind of you know notification or
something but not the release of the purchase order
you need in a thing like that you need to have consistent
you need to be able to say I've looked at all the line items now there would be
other ways to do it if you distributed the pieces of a purchase order all over
the place
then I'm sure there's a way to figure out if the purchase order is ready to be
released but sounds terribly complicated if you have the ability to do it
entirely within one transaction it's simple
so you you're looking for these kind of pieces that are not so big but not a
single object either and then use those consistency boundaries and you say at
the end of every transaction all the rules of that aggregate are followed
however that's not true
if in regards to other aggregates so let's say that we had a general
departmental guideline that we couldn't spend more than you know
30 thousand dollars a month on this and so this this purchase orders 10,000 and
this one is 10,000 you know we've got multiple purchase orders now we've got
his guide line that says we're not going to go over well if we have defined our
our aggregate as being that purchase order each of those purchase orders has
to be completely consistent at the time of its edits transaction commits but it
doesn't mean that it has to be consistent with all the other so it
doesn't mean that when we commit we have checked to see if we push the whole
department over its limit
that's got to be handled at some higher level and then whatever response to that
might know of course i'm not saying that this is the way to run a department is
so I'm just saying that's what it would mean it would be that we would allow
short-term deviations from the rules
if they were beyond the level of an aggregate if you want to distribute in
system me
you just have to have something like that but distribution and concurrency
both the trouble that you run into there is that you need to have some unit that
that you need to define what has to be consistent at the end of every
transaction what doesn't have to be in the aggregate pattern tries to relate
this back to some kind of conceptual hole
so it's saying don't just every time you encounter a new
oh you know we've been having problems with that transaction
well let's see i see we need to do this check before it's committed and this and
then over there you say oh when we distributed this
ok we need to pull this thing with it too
and every one of these decisions ad hoc and separate so that you've gotta sit at
a situation no human being can understand and if you can't understand
it you can't change it
so instead of that keep pulling back to the models do
we've got this transactional problem why what's the rule that isn't that we
discovered we need to enforce and how can we incorporate it into our
conception lon
how can we make it makes sense as opposed to just being a rule one of
hundreds if we discover that we need the other thing to be on the same node in
the network in order for things to work well in a distributed system
well that's not the end of the story but next question is why
what is it about that that's so tightly associated with this that we really need
them together is this
should that thing be in the aggregate but that would mean that the
transactional rules also apply at all times or is it
they can also go the other way we've got this big clunky thing and we discover
that there are that that we are causing
that were causing locking problems that we're causing that because we basically
are trying to enforce too many rules at once that the various transactions that
are happening
keep getting blocked by other ones so we say well maybe our concept that this is
essentially one thing is just maybe that's not a useful model
it's a model right maybe the entire maybe it's not right to have an entire
purchase order be one aggregate maybe we should have had different elements
within it
so use that aggregate concept
I already talked about this that you know an aggregate should be a conceptual
hole in it has properties it has invariant rules
all right moving along
what have I learned now we talked mostly that's enough about building blocks
so now on to strategic design which is like the last third of the book
as I mentioned context mapping is one of the principles of strategic design
distillation of the core domain is one of them and large-scale structure was
the third there were three principles of a lot of strategic design that are
presented in that last section and I'll talk first about large-scale structure
what have I learned about that I learned one important thing just doesn't come up
that off
so if you're going to skip that chapter skip that chapter and luckily its way
back at the back of the book so probably already haven't read it anyway
oh I find that stuff interesting and sometimes it's been useful to me in the
past but you know you got to set priorities and this one just doesn't
doesn't come up all that often so let's move along the other ones i've already
talked about right distillation and distal and context mapping i already
said how important that those were ok here's another thing
setting the stage what does it take to set the stage for a successful
ddd project with one where you're going to do some cool modeling and build this
system that maybe couldn't have been developed another way or put up in by
some army of thousands of developers but then it couldn't be you know actually
changed all the time
what would it take well one thing is I kind of alluded to at the very first
slide when I said why model really need to know why
and that means not spreading it too thin because if you look at systems you'll
find most of them
my that the bulk of the system is pretty straightforward stuff
maybe there's lots of crud lots of just data that has to be collected and may be
reported on or maybe the ability to view it and just keep it as a reference
information but the place where modeling pays off the most is in those intricate
little problems everywhere there's a lot of business logic and kind of confusing
cases and if you can focus down find a way to not spend much time on those big
simple things big
you know they may be complicated in the sense of just how huge they are but they
are not intricate focus down those intricate parts then another way of
reducing the amount of modeling you do is find out with that core domain is not
just the intricate parts but the intricate parts that are in the core
domain
the other ones well let the army attack then
but you are you know what you want for a DVD project that's really going to be
valuable and everyone is going to walk away inside
well that was that was cool and that was really valuable that is going to be in
the core domain is going to be some kind of intricacy there or at least a need
for extreme clarity
I find sometimes the problem isn't even all that complicated but it's one where
clarity where there's a value to just making it incredibly clear the clarity
is just so sharp you know you you look at some of the Apple products and people
there well that they're so nice
well what makes them so nice i think if you look at the ipod for example
it must have had fewer features than any of the other mp3 players and by far the
most popular the nicest one
why partly because it had fewer features than any of the other in peace
replay as they were utterly focused what is it people want with their include
three player
they figured out exactly the most important things and that's what they
gave them and they made sure those parts were just crystal clear and the rest was
just gone
or at least it was out of the way now I'm not saying that I wouldn't have
liked to feature to that they didn't put in
i'm saying though that if you want
yeah bill great to do
modeling modeling is kind of an intensive activity if it's spread to
thin it just really creates a mediocre result that isn't really distinguishable
from other ways of doing it except that you tend to take on heavier
infrastructure like all those are mappers and things
what do you need to know or remember for if the objects you're creating are no
more useful than the database tables were in the first place
so focus down then the next thing you need is clean bounded context i don't
know how many times i've already mentioned how important these contexts
boundaries are
but it's not enough times because if you really got to have and so bounded
context is the thing I said you know that that context map that tells you
where your context are and has boundaries around that's something i
think almost any project could benefit from i'm adding word clean here because
I'm saying to do
ddd very effectively you need to be able to carve out this space and within the
space things are clean
you don't have all that chaos is the the the cowboy code or running around making
a mess
you don't have 50 people who don't quite understand what each other is doing you
do you have a focused
well coordinated team within a clearly defined boundary
and you need an iterative process because to create a great model you need
the chance to experiment and then and the experiment part extends to having
that software get used a little bit and then you really learn and then you fold
that learning back into a new model and i'll just say it because you can never
say this one too many times must have access to a domain expert
funny thing in the last few years since i wrote that book where I wrote in the
preface
there are two prerequisites to DD and they are an iterative process of some
kind and access to domain experts and I very often get asked
so we've kind of got a waterfall process dictated to us
how would you suggest we apply DVD or even more common area is what we just
don't really have good access to the domain experts but we want to do TV
anyways I want you to help us figure that and it's surprising how hard it is
to get across sometimes that what I mean is that you must have these things just
have to have them and if you don't you can't do DVD just can't
I mean you can go through all the motions you could do all the work of
course you can apply the process but you won't get any good out of you won't get
a good result so don't waste your effort go back to another more conventional
approach but if you've got these ingredients you can do wonderful things
but if you don't have them
it's the process history homework it's like
you could if you don't have any gasoline you can buy a car anyway but what's the
point you just wasted thousands of dollars and now your driveways full so
don't do it
ok and then start to bring a little faster context mapping this thing I keep
bringing out but I've learned a few things about this - and one of the
things is a well okay
I already told you that defined in context
so one of the things that I have learned about context mapping it is that well so
that ok for those who aren't that familiar though with context mapping
there was several patterns about the nature of these different contexts and
also the way they relate to each other things like maybe this one is upstream
of that one
and so as a result you know this guy is kind of on his own and he asked to build
a sort of defensive software structure we call the anti-corruption layer to
keep but those people are doing from messing them up or maybe you need to
integrate with someone and they don't really care if you integrate with them
so it's all on you
versus other situations where there might be more cooperation and I realized
as we were actually trying to do all the context maps of many different project
that there are a few patterns that were missing
so one of those is this thing I'm calling partners and that is where you
have two teams that are mutually dependent
this does not mean dependency in the technical sense
it means the pendency in the sense of can I deliver my project successfully if
he doesn't deliver his project successfully and of course in many cases
the answer is no because if maybe maybe in a technical sense he's completely
dependent on you but in a actual project sense
yeah okay you could run your software without him but no one would want it
no one wants it because they need both pieces to make it a useful system
whatever the reason in these cases usually have a cooperative kind of
relationship because people are forced to be cooperative
not because they like to be cooperative because they're forced to that's why I
chose this picture
this is a three-legged race anybody ever participate in a three-legged race
yeah so two peoples one leg is tied together and they have to run a race and
so the thing about this is that being the fastest runner is really not the key
to winning a three-legged race
in fact if you have a very fast runner tied to a very slow render it may
actually be a disadvantage but what's most important is that they managed to
sync up very well so they run it exactly the same pace exactly in sync with each
other and that's really who wins the three-legged right
these people i think are winning and those people must be pretty well think
these people are out of the race
they one of them went to vast maybe I don't know
anyway the point is that too when you have to be cooperative
not because you want to be because you want to win ok here's another missing
ingredient
I just one day I suddenly had a light come on and I said half at least of the
of the context that we're putting up here on the board are made up of a big
mess that there is really no reason for us to be worried about picking apart
in fact it fits a pattern which was written up
it's a wonderful pattern that you should look up so I put the URL there
original version and or if you just Google for big ball of module finding
and these guys observed that there was very little written about what as they
put it is arguably the most successful architecture ever applied and that's
what they call the big board where people just do stuff people just you
know when they need to change they just stick it in there somewhere
they just connect these two things if it's handy to do so and worry about the
consequences later I just don't worry about it
and so on and so on it just builds up and it builds up and yet functions and
they said well you know we go on and on and on about all these elegant
architectures that we like so much
the truth is when you look at most software that's actually out there
running doing useful things that usually looks like this and so I thought well
that's brilliant and not only that but you see it all the time and people and
people get kneecapped buy it - because they feel like if they're going to do DD
they have to fix this
this doesn't look like anything that was in my book and so how do you do that
and the truth is well
how do you do that I don't think you can do that you know
so what do you do well the first thing you do is you draw a context map
sometime we'll tally up how many times I say that anyone talk so and you draw a
big circle around this big ball of mud and you say this is a big ball of mud
and here is a boundary around it
you got to define that boundary and some terms of something real
how do I know where the big ball of mud will sprawl and we're one big ball of
mud tend to sprawl
they tend to reach out their tentacles anything nearby will get sucked into the
big ball of mica
that's its nature and so maybe sometimes you kind of build a little wall around
yourself and you say well i'm just going to keep the ball mode out of here and
maybe not forever either just long enough for us to build this one
extremely valuable intricate thing
the big ball of mud the funny thing is the big walmart is not destructive as
the big ball of mud oozes out features never go away
they never get rid of anything in fact so if you can build your thing you know
enclosure let's say that keeps the mud out for let's just say one year one year
of paradise within your little walls and you have built this intricate and
extremely valuable thing and then as it inevitably will the wall will break down
and that mud will come oozing in it will not make your system stopped working
no matter how intricate your system was it will continue to do the same things
that did before
it's just that no one will be able to understand it anymore and we're going to
be able to change it anymore
but you had a year and you've got something valuable built that you
couldn't have done if you just admitted that there was going to be a big problem
and try to build it in the ball amount so
ok that's all
yes in fact I'll bet if you could you know an archaeology of a big ball of mud
would probably be a fascinating thing i'll bet that again and again and again
people created kind of temporary
they probably didn't think of a temporary but they built highly
organized systems there and then eventually the ball might be enclosed
and it will in-close yours too but that doesn't mean those things were
invaluable doesn't mean it wasn't available right
you have that year and that here will you could do in that year but it might
take 10 years to do in the ball of mud directly or just couldn't be done and
also be fun
so i think is a important value also of course a motor or a wall is two
metaphors for that obstacle that boundary boundary has to take some form
you know it so I've actually seen cases where the adoption of a new technology
and usually I say oh who knew technology or just distracting himself has actually
seen cases where someone will they'll say well we should do
java and what I see is that for a couple of years they actually get good results
in Java but not because there's anything better about java then there was about
the old technology
it's because it's an effective boundary the old ball of mud which was saved
you know written cobalt course
and
but it can't lose directly it can whose indirectly and once it starts to lose it
comes the flood it is indirectly because you have to integrate and so all those
nicely carefully crafted bridges that you've created between you and the old
cobol system but eventually they get overwhelmed but for a while it it really
can work and I'm not really going to propose the people adopting new
technology every two years just to keep the big ball of mud out but it's
interesting what can create an effective barrier that's in another thing that I
think there's more to be learned and it's observational stuff you can look at
your own project and see
was there a project that somehow got a little space sometimes I think that the
best defense of your little Enclave from the big ball money is just a ferocious
project manager
I've seen those cases eventually people do leave your bowl of your little
context alone because they're just afraid to tangle with that guy and that
can work that could be an entire job
you know like he could be the defender of your your contact
I think that I have much more in the last few years emphasize the importance
of strategy may be coming from a small talk background gave me a certain
bottom-up bias that i am still gravitate to
but i think that unless you've carved out that context map
I mean unless you've carved out that clean context all that fine
elegant modeling and design is for nothing because it will get sucked into
the bottom and faster than you can
on the same time if you are working on some problem that is secondary and not
directly related to the Quartermain you may well succeed in delivering and
everyone will be on a little pat you on the back and say nice job and that's all
because nobody really cared very much but when you are working the corner of
main and you managed to carve out that context and you do something incredible
in that you know you're the hero
they will remember and so
oh ok just want to talk about this little needy and SOA there's like a
whole category of things like it doing this and that is something and DVD
MDA and ed what's the difference
or why should i use DVD instead of SF way I used to get that question a lot
ok what why would you use DVD instead of us i will you would you wouldn't use it
instead of SLA
the thing is that people forget how fundamentalist modeling stuff its
modeling is just a system of abstraction
now what do you think the service definition is what is it defined in
terms of some kind of concepts a system perhaps of concepts concepts
abstractions in other words services are based on systems of abstraction and in
order to have a good service
not now there are lots of services that i must say frankly the definition of
them is he passed in this sequence of strings and hence and you get out this
sequence of string sentences
that's the definition okay but that's not really the vision I think that the
SOA people had beginning
they had something much more conceptually coherent in life that these
services would mean something and meaning demands context and so the
service interface has to be defined in some contexts in the same context i was
talking about context aren't just for the objects or whatever
in fact they apply to Kobol programs and they apply to service-oriented
architectures and then the internals now
often you'll find that the inside of the service is radically different in its
concepts than the published interface with the actual implementation is based
on a whole different world view that may even be the big value of the service
there are services whose real value is it just sort of takes some messy thing
let's say some functions of the ball of mud and it sort of reef raises them into
this elegant model and offers them up as this clear well-defined service
have you encountered that anybody where you have a service
it doesn't actually have a lot of logic of its own
it's great value comes in allowing easier access to the functions that are
in the legacy system but that are too hard to get to another thing is that at
that sometimes that service interface to find the context boundary for you
remember i was saying look for the things that can mark them on
maybe you don't have to go to a whole new technology platform to escape the
big ball but maybe you can use some kind of you can say well i'm implementing
this service and everything in here is mine
people tend to sometimes into that
well anyway my point here is not to go into all this
nitty gritty about it too . is to say this question just you know that
question i mentioned
why should use DVD and service away it doesn't even it it doesn't make sense
ddd helps you make better
ok - better ass away