What is DDD - Eric Evans - DDD Europe 2019

well welcome to DVD Europe and thank you for the welcome so today my my talk I think the the one I'm assigned is sort of what is domain driven design and so I'll try to get across sort of the basic concepts and the motivations and then they'll go into more detail in some of the other talks about some of the important principles as you've seen on the agenda I always like to start the discussion with this statement it's like a mantra almost that I do because a lot of people come to design with deep-seated perfectionist

tendencies and those tendencies undermine all our attempts to do good design this I say as someone who has this tendency and speaking to a room full of I'm sure 90% of you have this tendency to so keep that in the back of your mind as we go along now there are a lot of people who don't have that tendency and when they look at some of the things we do and they'll say you know you don't need all that and truth and beauty it's just the truth and beauty and all you need is software that

runs and what we're doing is about software right we're really our goal is to create software that does an important job and so what is the most effective way of creating software that does an important job it isn't a given that that would be models or a particular style of doing models that shouldn't be taken for granted we should always be questioning our assumptions but I think there is a good case for it and I will try to illustrate that case with an example all this stuff is so abstract I like to get straight to

an example so mostly in this talk I'll go through the the example is from a domain of container shipping this is for bulk cargo transport and most people I think are at least a little bit familiar with this almost all bulk cargo these days is loaded into containers like this one and then put onto ships like this to go across the ocean transfer it in ports like this to go on to other ships or on the trains you just simply attach a chassis to the bottom of the container and it becomes a train car or

a different kind of chancing it becomes a the trailer of the truck and so this kind of intermodal transportation it's very efficient and you can imagine it has some logistical complexity and because of that logistical complexity there's a lot of software involved well anyway so imagine that we work in a company a shipping company and our job is to write software that addresses those logistical issues so a typical kind of problem a kind of case that we might be looking at would involve say a customer calling one of our clerks and saying I have a

container in Hong Kong I want to ship it to Dallas Texas so the clerk might say alright they put into the computer the origin is Hong Kong the destination is Dallas and the computer will come up with routing for that cargo and then they will explain it back to the customer alright your cargo would be loaded in Hong Kong on to a specific vessel voyage ABC is the designator that in this picture and then in Hong Kong you'll be transferred onto a train XYZ and that will get it to to Texas to Dallas Texas on

a certain date and time my customer says all right that sounds good book it so then they take a few more steps and it's stored in the computer this is our first use case and we could start immediately thinking about alright what kind of what kind of objects do we need or what kind of functions do we need and we could develop a design and a model for this thing but that ignores one of the realities of software development and that is that we already have software that does this in almost every project we are

working with in a problem space where there's already a lot of software our software will have to coexist with that software perhaps it will be perhaps we're talking about a refinement of the existing software perhaps we're talking about some new piece of software they'll integrate with another piece of software or baby we're talking about a new piece of software that's replacing a piece of existing software but there's always existing software even in so-called greenfield projects there's still existing software and that's a very important constraint so I don't like to ignore that constraint and a number

of the of the techniques that will be talked about later some of those are related to that especially context mapping but right now we'll sort of assume that we are going to be refining an existing piece of software so let's look briefly at the design of the existing software so this is a very high-level view and in this very high-level view we can see that we have an object called a cargo which is populated with all the information that the clerk would collect as they talk to the customer especially the origin and destination of that

cargo then they pass that information to a service called the routing service and that service will figure out the steps right which actual vessel voyages which ships at which times can actually take the cargo from its origin to its destination and as it does that it puts its answers into a database table called cargo bookings now this design which is fairly typical I think of legacy software of a certain generation and it's not a bad design it has one characteristic that's quite good which is I can explain it at a high level very quickly and

clearly so I think everyone understands this high level view at this point that's a good characteristic not all designs have that but it also has some drawbacks and some of those drawbacks might be preventing us from adding features or or improving features that we want to do now when I look at a software design I try to have smooth two perspectives and I try to shift back and forth between those two perspectives one perspective is the software designer software engineer type of perspective this one I apply all the principles that you know that we have

learned about how to make software somewhat clean and changeable and so forth for example with this set of eyes I might notice that there is a side effect here kind of a problematic side effect that as the routing Service does its job one a very complex piece of logic is also updating the database to combine complex logic with a database update is basically a violation of an old principle of the separation of the logic from updating state and that's principle that goes back before domain driven design as a name anyway so I would notice that

in other things but there's another perspective I want to bring to it which is the domain perspective if I were talking about this design with a person who is not a software developer but instead an expert in shipping how would I explain it to them and it would start out much the same as the way I talked about it with you I would explain how you give the routing service an origin destination and a few other things and then it will come up with the stops that the cargo will have to make and put them

in the database and at this level communication is pretty good a shipping expert would understand that would understand these kind of components of a software system and how they interact but we need to get a little more detail than that we can't always have such high level discussions suppose I wanted to discuss a an issue that comes up sometimes I showed you an itinerary for a for a shipment that looks like a pretty good one but sometimes for various reasons you end up with something like this so notice that now the cargo is unloaded in

Long Beach California and then loaded onto the train in Sacramento California which is hundreds of miles away so how did it get from Long Beach to Sacramento well it wouldn't if we had an actual itinerary like this in the system they would follow the instructions of the itinerary when it arrived in Long Beach they would unload it but then when the time came for the people in Sacramento to put it on the train they would look around for it and couldn't find it and then eventually someone would figure out what had happened but what we

want is to be able to notice when this happens and take a corrective action and people talk about this and they talk about these kind of disconnect that I Center Ares but how is it reflected in the software as it exists well it is there we have some relational integrity constraints in the database table but when I start talking about this and this solution I find that the I lose my connection with the domain experts I can't talk about this with a shipping expert who doesn't really understand software that well so we have to find

another way of dealing with this and a way that gives us a design just as clean and effective but written but maintains that communication so in these kinds of combining these two perspectives this is how I want to think as I go forward now I think about what concepts are we missing that we are using when we talk to the domain expert we're all shifting between two conceptual system between two models two languages so to find the an alternative we need to somehow get into a creative collaboration with these software experts I mean between the

software experts and the domain experts and that's not so easy to do you can get sometimes you can get one of these people into a room and got a nice whiteboard and you say you know like well what concepts are we missing here and you know nothing will happen here so the thing is that getting these conversations started is quite difficult I'm going to talk about sort of the things I often do kind of tell a little story of a typical way but but that doesn't mean this is the way it's done and in fact

later in the day Alberto Brandolini is going to talk about events swarming which is a technique that it is among other things a great way to get a creative collaboration going between those two kinds of people I think that's the that's I think the the most exciting aspect of it to me actually so um but nonetheless here's here's kind of a thing that I do is take this as a story about you know how it was done in this particular case first of all I like to go in with an idea or two you know

to just kind of start feeding the feeding the conversation and where does those ideas come from those well often you know you're just popping with ideas if you've been working in the domain but one of the principles of domain driven design is that the language is very important and one thing I've noticed is that when we talk about our software we don't use the same language that's actually in the software so for example here let's compare the way I talked about this system even at the high level with the way it actually works so I

said give the routing service an origin and a destination arrival time and if you look at the diagram you will see that in fact that's exactly what happens I mean taking this diagram to be an accurate representation of the software so so far so good and then I say that the routing service it the routing service will look up the stops the cargo will have to make now the thing about that is that the word stops does not appear in the diagram and we can do a little search of the code and so forth and

we will find that stops is never used in this way anywhere in the software it might be in a label here there so this is a concept so basic that I use it to explain what the routing service does what does the routing service to you it looks up the stops the cargo has to me but that's not actually what's happening in the software not at least in those words so maybe here we have an idea that could feed the conversation and so I could propose something I could say well cargo we already have the

cargo object maybe the cargo object could have a series of stops now I propose this and my shipping counterpart says yeah that sounds good let's do it that way and so I feel good that I had a good idea now we can take this we can refactor the software we can have a more a better communication between the two types of people and so forth and never look back actually this is often what happens and that is another point where things can go awry because at this point I will have lost a great opportunity the

first decent idea that came along is often the last idea because we latch on to it and we stop thinking as a metaphor for this think about or a comparison anyway think of what you would do if you decided to go shopping for a car you might do a little research and you'd say okay what do I need and you write down some things you need I want to have a sedan with enough room for four people and so forth and so you go and I'd like to have it be green and so you go

to a dealer you say well these are things I wanted one a four-door sedan I want it to be green and and there are other constraints there too so the dealer says all right well here's a car over here that is green four doors it meets all your requirements and so you say okay I'll take it is that how you shop for a car now what you really do probably is you say okay well let me test drive that car and then I'm going to go and shop around at some other cars too and then

in the end it's actually possible that I will come back and buy that car but I would not feel good about buying that car having not looked at any others what's the difference between buying a car and designing a piece of software I can only think of two real differences one is that the possibilities for software are much broader and less well understood so if I actually did buy that car or indeed pick a car at random the chances are that it would suit most of my needs that's the truth in 2019 I could pick

a car at random and it would suit 90% of the needs that I have that's probably not true of a software design the other thing is that most of the time software development is quite a bit more expensive than buying a car so both of those though would suggest spending more effort trying to choose a software model than we do a car and specifically I mean looking at more alternatives because there are lots of methods where people put a lot of energy into designing the software but that energy doesn't usually go to looking at a

broad range of alternatives so somehow or other we've got to get some alternatives in there and if I've been listening to the way people talk I realize that some people sometimes say that the car goes itinerary is a series of stops but sometimes they say that it's made up of a sequence of legs so the cargo will so a leg will be like you know the part that goes from Hong Kong to Long Beach California on a particular ship that's one leg so maybe we should try that out so I'm going to throw that up

there too now this time the conversation has to change the the shipping expert can't just say that's good do that of course if legs that come first that's what would have happened but now it's more of a conversation about well why should I use one versus the other or maybe it will even trigger I find that about three if you can get three it changes the way people think from sort of choosing one to realizing that they're just looking at examples from a very large set and if you can get to that point where you

have that shift in your mind where you realize you're looking at samples from a very large set it gets to be much easier to come up with more alternatives but it's not so easy to get those first three I can do my little trick again so for example what I said earlier is that a car goes itinerary is a series of legs and that and I explain what a leg is but let's just ignore the bubble on the right do the trick of comparing what I say to the more formal in this case it's just

a diagram on a board we don't have real software but still the diagram on the board has already diverged from the way I talked about it so look at that for a moment what is the difference and someone just point out a difference any difference the so of the words I mean how did the words not correspond to the diagram the cargos itinerary is a series of legs and I had that diagram the lower one so there are two differences and I think I heard them both come from various people one difference is that the

diagram is less specific it doesn't say that the legs are a series it just says it's a collection so we could fix that and that's kind of a detail though I mean to say it would be a good thing to fix but it isn't a fundamental change because the series is a collection but the thing that really is missing is the word itinerary that is the statement doesn't say a cargo has legs in fact as an English statement that sounds very weird a cargo has legs what sort of cargo has legs maybe we're transporting live

animals or something our chairs [Applause] yes I'm transporting chairs and my cargo has legs well that's not what this means that right that's a different sense of legs so we need a we need to really take seriously that we're not using the same language and here's an observation I want to make I've used the word itinerary in this presentation many times but I don't think people were sitting there saying well why isn't he putting itinerary up as a as a concept to use in our model you weren't thinking that nobody would think that because we're

just used to hearing words and you know we get the gist of what's being said you get the meaning of what I'm saying but not paying enough attention to the actual words themselves and I think that if you pay attention to the words themselves gives you wonderful clues to models that can really help solve the problems in the software so I'm going to add a couple more one would be that a cargo would have an itinerary and that itinerary would have a sequence of legs and another would be that it would have a sequence of

stops I can do it both ways so now I've got at least four distinct models and minor variations around those and at this point hopefully we would have other ideas as well so but that's enough to get I think the sense of what I'm trying to do here and notice that these diagrams are written in a very informal style the point being that we don't want to invest a lot in these ideas at this stage we want quantity but not depth of analysis we can do the depth of analysis later if we need to but

right now we want to get broad that means in fact we need some ideas we don't really have any in this picture but we need some ideas that are just bad you don't know if you've if you've really explored of the problem unless our that rather than space of possible solutions if you never come up with a bad idea but because when I made this slide I was too familiar with the problem perhaps or just to embarrass to show a really bad idea I this isn't a good illustration of that principle all right so there's

one of the things you've got to generate some variation but you've also got to keep moving one of the things that happens to people doing software modeling is that they get and this is the perfectionism again they get into a loop of just doing more and more spending time if you're not getting good at ideas then move on to something else come back to it later and don't be too finicky duh you know I don't think you can really succeed in this if you have a group of people that's working on it where you will

really be where your where your prestige will be lowered but by you putting up a bad idea if you put up a model and everyone says well look it's got the wrong kind of dependencies in it and then you say oh well I'm sorry I'll go away and never talk again if you're in that kind of place this isn't gonna work so now also implicitly I think I've said that there would be more than one session like this I don't like these sessions to run on for hours and hours an hour and a half is

long enough at that point you're not gonna have any new ideas so you have to have multiple sessions and then people get to the question well what do you document about this this is meant to be low cost so I would say that I would just look at the board and say is there anything here worth remembering that we would want to feed into the next session and the answer might be no it was a good discussion but we don't need to keep any of this and then you can just forget about it and schedule

the next meeting and and be done here I think we did get some things I would just say those three words would be sufficient but maybe the diagram of the cargo itinerary stop would be good to have that would be enough and I might write those in my design notebook and just leave it at that we don't have to have a wiki documenting every idea that we have and how we have to move on now at some point you're going to have to decide right generating variation it's very important but then you have to select

from the variation so it's a very different kind of thinking different mode of thought and also different criteria and I think different people so one thing that I think is important too is that you have different meanings probably with different people to come up with the ideas or to select or most importantly to decide whether to actually use something so that's really I guess three different kinds of things but the most important is when it comes time to actually decide and we're thinking about oh should we actually do this thing be sure to have a

meeting where the stakeholders that would be affected are there that might be the the project manager might be another project manager from an effect you know another team where your stuff is used if you don't do this the next time you try to have idea generating meetings you'll have all those people there and you won't be generating very many ideas well anyway how do we choose a model and I don't mean forever necessarily but for now so stopped your legs for example let's just boil it down to these two we're gonna have a car go

with an itinerary which stops or car with an itinerary with legs and just have a show of hands who thinks we should choose stops and who thinks we should choose legs all right legs wins I think this would be a better process than what we usually do what we usually do is we'll have some document with a nice diagram in it and then at some future time a programmer will get a story card and it will have you know require some of this functionality and they'll do it some way that's about it or maybe they'll

get the diagram with no kind of meaning and so they'll make those objects but none of the none of the sort of kind of subtlety of the concepts will come through so we can do better than that but before we do I want to talk briefly about what I mean when I say model because I've used the word a lot of times but I haven't really said what I mean and there are a lot of meanings to the word model and you guys know many of them you can eliminate some of the obvious ones don't

mean a tiny ship in a bottle but there are for example people often say model and they mean a UML diagram and I've used the number of UML diagrams but that's not what I mean what I really mean is the concept behind that diagram so if we look at a map of the world we could say that this is a kind of model of the world and yet and it is but still it's not quite the kind of model I mean I mean the model behind this map so take a quick look at the map

and you can see things like I don't know how big things are you could say the United States and China and look about the same size and they actually are approximately the same size or you could look and see the Greenland and Africa about the same size so I suppose by extrapolation that they are the same size oh I see someone shaking their head so apparently they're not the same size here's a different map of the world this one shows Africa and Greenland and oh I guess they're not quite the same size in fact Africa

is 14 times bigger then Greenland but they look the same size on that map now is that because the people who made that map didn't know how big Greenland was or perhaps they thought you know this is my pet theory that got shot down by this xkcd comic but my pet theory was that this map was made in the US you can tell because it's right in the middle of the map and so you know where it was made and then there was a there were some immigrants on the team that made the map from

Greenland and they said Americans aren't very good at geography and if we make Greenland huge generations of Americans will think that Greenland is big and so that's what happened but actually it turns out that's not what happened the Mercator projection is the reason now why though did the Mercator projection become so extremely popular that turns out to be because it was very useful for a particular case which was important in the 1590s when it was made which is that if you make a map based on this projection you can draw a line between two points

and that line course but the angle of that line corresponds to a compass heading if you want to know what direction you know New York is from Lisbon you draw a line between New York and Lisbon and if you pointed a ship that direction and went in a straight line of course you wouldn't do that but it's a sort of starting point for a navigator so this map was really made for use on ships by but then it was good enough to use for many other purposes and sometimes you can even tell things like how

big something is you can tell that the US and Canada and China about the same size because they're at about the same latitude long as something's at the same latitude you can compare the size if you wanted to you could compare the size of Africa and Greenland by making an adjustment based on the latitude it would be a more complicated calculation so by choosing a model that is well suited for a particular problem you want to solve you can make the complan make the computation simpler or more complex this one makes figuring out directions very

simple but it makes figuring out the size of things a bit complex but it's still possible to do if I wanted to know the population of the US versus China I could not do that with this map no matter how complicated the calculation was so there's these sort of factors now what is the model as I mean it well behind this model behind that map or other is the concept that the world is round it's implicit in it but that the world is round and that all we're interested in is the surface and certain points

on that surface we're not interested in the chemical makeup of the land or the anything about the magma underneath we're interested in where the coastlines are so we need a way of describing that a spherical coordinate system such as latitude and longitude then we transform all our data into that form then we need to convert it into a flat map or technically into a cylinder because you could pro Tate that map and we need to do this in a way because there are an infinite number of ways of transforming a spherical surface into a cylinder

but we need to do it in a way that preserves the direction of two points relative to each other there's only one way to do that and it's the Mercator projection this is the model and if you take that model I mean if you look at the pieces of it you see that here's an abstraction this very complex and concrete thing the earth is abstracted as this simple Geograph the geometrical figure and we aren't using all the data we have we're using certain kinds of data in this case the location of coastlines and rivers and

so on using another abstraction to represent it in terms of to the other that is latitude and longitude is meaningful in relation to a sphere then we need some math to do the transformation now I don't know exactly how Mercator did it's some kind of geometrical technique I'm sure with protractors and stuff but the modern way of expressing it is this function this projection function and then we can make an assertion and this assertion is where the power of the model comes from I could take a different data set and I could apply the same

model and I get a different map this is marketers original maps this time Europe is in the center specifically Belgium is in the center because Mercator was from Belgium but you can see that the map is essentially the same a lot of details are different because their data set wasn't as good but if you look at Europe and Mediterranean and the data is pretty good you look over in North America and the data is ok South America it's actually a little better on the East Coast the west coast of South America is weirdly sort of

shifted to the east I think there's an offset error in the data and the west coast of North America is kind of vague it's like they knew there was a west coast so they just sketched it in we could call that an extrapolation or an interpolation of incomplete data and boy this starts to feel to me like the kind of things we do on software projects we take a data set that is imperfect than incomplete we apply transformations to that data that allow us to to make meaningful decisions the decision in this case is which

way should I point the ship so the domain is just anything that you could know about but the model is a system of abstractions representing some selected aspects of that domain this is a very basic definition of model but I think anytime we start to get more concrete more hands-on than that we lose the power of the model power the model is that it is a set of concepts but it's not neutral it distills some assumptions and knowledge that we have that's and some models are good for some things other models are good for other

things this is not a way of representing reality in fact I think realism is a distraction consider is this a realistic picture of the world well you know we discussed for example that Greenland is not the size of Africa maybe this then is a more realistic picture of the world Greenland and Africa are in their proper perspectives but somehow the idea that you know if you went east from Africa you would just end up in space doesn't feel right either so neither of these is realistic nor are they trying to be this is pretty realistic

picture of the world if I were a navigator at sea though I would rather have either of those other two than this and I would much prefer the Mercator map over the Dymaxion one but I would settle for either rather than this very realistic picture realism doesn't give us models that we actually can use another thing about models is they need a narrow focus i googled for domain model and found this the web and I think there were some more complicated but this was all I could really fit on a slide completeness really leads us

off the track and yet we say but we have all this information we have to represent it somehow we have to get it into the computer and yes that's true I could picture having a database where we just say this database is for archiving all the data we've got in some kind of canonical form but that's not the kind of model I'm talking about if you're going to do that what you need to do then is have a separate representation of that of some small selection of that data that will be used to solve specific

problems in the domain and you'll transform the data back and forth and I think that is in fact the recommended thing that is we want multiple models from multiple problems within a larger domain so a model should be focused on a specific difficult important problem this is obviously too hard to do for everything don't do this for everything do it for the hard problems the ones that you don't think you'd get right if you just started writing well if you know this then this if you think you could get it right doing that then do

that but if you don't think you could get it right doing that maybe a model would be helpful and for that then you need to say well then this model would be helpful for what for a specific use right a specific kind of problem this is one of the reasons that I emphasize concrete examples earlier I asked which is these two models you like better that's not really the right answer the question the question I should ask is which do you think would be more useful and when I asked the question like that it might

cause you to change the way you're thinking and think well useful for what what am I being asked to do at using this model and then my said well okay we need some scenarios some specific stories about the business that tell us what we're going to use this thing for and I did tell you one I told you the initial booking and you might say well for that purpose I think either these would be fine I could describe the result of the initial booking using the series of stops an itinerary has a series of stops

or an itinerary has a series of legs I don't think that would really be much difference so let me give you another scenario another thing we have to solve and I think it can be we can use the same model for both of these sometimes a customer will call up and say something like I want to send my cargo to Dallas then a little bit later they will say oh I want to send my car go to Seattle not to Dallas but by this time the ship is already sailed the cargo is somewhere in the

middle of the Pacific Ocean if only they had called a few days sooner we could have just done the whole thing over again right then it's simple from a software point of view because we can just undo everything we did and do it all from the beginning but now we cannot do that we need to do something to get rid of the legs I mean basically this ship is going to go to Long Beach California and then is our next chance to change anything our cargo will be unloaded in Long Beach and we could put

it on something else we don't want to put it on to the leg that goes to Dallas so we want to cancel that leg and replace it with something else now the way that I am trying to explain the problem might lead us to think that the leg model might be helpful for this problem because it's so natural to talk about cancelling a leg from Long Beach to Dallas and replacing it with a leg from Long Beach to Seattle but I can do it the other way and I will try because it's worth looking at

our alternatives we could cancel the unloading portion of the stop in Long Beach and stop in Dallas merge the remaining part of the Long Beach stop with a load portion of the stop that sets the cargo bound for Seattle and add a stop at the end that unloads in Seattle that's not so bad here's a pseudocode version of that and it is actually something you could do this is not out of the realm of reasonable solutions but here is the solution with the leg and not only is it fewer steps but each one is less

confusing it's not so much the number of steps here its how tricky some of those steps are the ones that involve taking a stop apart putting it back together again in the leg based one we take things apart between you know we so back to our original design if we're going to transform this thing it did look like this and now it's going to look something like this when you you're still going to send the origin and destination to the routing service but instead of updating the database it's going to create an itinerary pass that

back notice that we now have rid ourselves of that side-effect the routing service no longer needs to update the database I mean someone could make it so that it updates the database and I imagine they will if we don't communicate very well but this is a great opportunity to improve the basic properties the sort of architectural properties of the design and it comes from having a very explicit way to talk about the results of this computation another thing we talked about earlier is the disconnected itinerary remember now if we will bear previously we were putting

integrity constraints in the database and stuff like that but now that we have a little more way of describing the result of routing we could talk about how this could be done in terms of this model does this model lend itself to telling you whether an itinerary is disconnected I think there's a fairly straightforward way of doing it so you could say then an itinerary is connected when the end location of each leg is the same as the start location of the next leg that's very natural you can talk about that with a businessperson and

find out perhaps it does not really what they mean or find out that yes you've got it right and that looks almost like pseudocode right you could say yeah I could code that now it looks so much like pseudocode that I want to point out something I don't mean when I say an itinerary is connected when don't mean I'm describing the calculation that you should do what I'm really hoping to do is define a new word that will be part of our language and in a new concept in other words I'm saying that the model

is not just those three objects a cargo and itinerary and some legs it's not just those objects it's also it describes the way those objects are related to each other so for example one of the properties that an itinerary might have is is it connected and that's part of the concept of an itinerary it's not just a calculation that we can do but it does correspond to a calculation we can do being able to but being able to step back from the calculation and say this is actually a concept in that sense that I talked

about what is the model earlier that's a very key thing we're not just rearranging the code in some way when we get to this point where we can talk about the solution that we have talked about our software the same way with another software person as we can with a business person and where we can have real questions with them about the things that need to be done and how we might do them differently we call that the ubiquitous language the Invictus language is one of those fundamentals of domain-driven design you can see throughout the

whole example that I've emphasized language looking at how we talk about the problem as being fundamental to finding a good solution so ubiquitous language is one of those three or four concepts one thing about that word that phrase ubiquitous language is that it kind of conveys a you know ubiquitousness in the whole sense that your whole system would revolve around one language and that is emphatically not what we mean so I like to append ubiquitous language is this within a bounded context I'm not going to talk about bounded context right now but Cyril will in

a couple of hours I can't remember exactly when he was in the agenda so we go into depth on that concept but the idea is basically that we will have multiple models with distinct languages and that that whole assembly of models will provide us with the solution to the various problems that we have so getting back to the question of why do this stuff I think that the answer lies in complexity within the domain itself sometimes we have complexity in the technical solutions that we need to do if we were perhaps if we were say

in the early days of creating Twitter Twitter is pretty simple in its logic but especially early Twitter was but at the time the idea that you would send out millions of messages in a timely way to someone's you know to the followers all those things that was a real challenge at that time now because of the frameworks that they created and made public it's not actually that hard to do now if I wanted to go create something on the scale of Twitter I think I could do it all by myself that probably couldn't get very

many people to sign up though but the point being then that the Twitter of that time would not have met this criteria right it the critical complexity that they were dealing with was a technical scaling complexity whereas most of the time on the projects that I've been working on the critical complexity is in the domain itself it is that shipping is very complex and if we do our job right our software might not actually be more complex than shipping itself but if we are not careful our software might be much more complex than the actual

shipping domain and because the actual shipping domain probably pretty close to the minimum complexity that we can hope for right well that is basically my time but I want to just touch on one other thing suppose that instead of presenting the the the scenario that I did as the second scenario where in mid transit they changed the destination suppose instead I said well we're still on our original itinerary but we're about to arrive at the first port and we need to generate these purchase orders to the to tell the people in the port's how to

actually unload the cargoes what to do with each cargo and there are these companies that operate in ports and we need to figure out which one to send each instruction to and we need to get the whole story of each of thousands of cargoes right criss-crossing through an enormous complex port and when you look at this problem you start to think wow the things that happen in the port are more complicated than the things happening in the routing of the ship maybe my model should be reared around that and that might point me to the

stop small because stop has a very explicit place to talk about the port the stop represents everything that happens in a port the leg says everything that happens between the ports it literally has no place to put information about what's happening in the port and so you would have ended up with a quite different model it isn't like we're converging to the best model we are converging to a model very path dependent depending on the particular problems that we are trying to solve and the order in which we try to solve them and the ideas

that happen to come up during that process so if you encounter a different sort of problem later on you have some choices you could say well let's bite the bullet and change the stops now and you're accepting that your solution to the routing problem will be slightly more complex remember I said though it's not out of the question right it's doable but we'll reserve our best choices for the most difficult problem which is the one in port or maybe this is time for two bounded context I'll solve route related problems over here with legs we'll

have another place where we can solve problems in ports using stops and I'll have to transform the data back and forth back and forth but that's doable two or a third choice which is stick with legs and go ahead and cram the new functionality on there somehow you know I can deal with the first vendor on the unload of the let you know the incoming leg and the last vendor on the outgoing leg then I'll just put all the other vendors onto the incoming leg because I've gotta go somewhere and that is also sometimes a

valid choice but especially worth mentioning because it is the default choice that's the choice you make if you don't recognize that there's a choice to make and that's a choice that gets made all the time in fact I think probably on most projects it's sort of a timed thing how long is it before you make that choice and once you've made that choice you're kind of stuck because you have a model that no or fits the most difficult problems are trying to deal with so you're not getting much benefit from model and that's the last

thing I'll say before I turn it over to the next person remember that having a model doesn't actually give you any advantage as such the Vantage doesn't come from having a model the advantage comes from having a model that is a very nice fit to the specific set of problems that you are trying to solve in that context if you have a model no matter how nice its properties might be in an abstract sense but it doesn't fit the particular problems that you are trying to solve it will not give you any benefit it might

be fighting against you so I'll go on out on that point and I hope that this example helped to illustrate kind of the spirit of domain driven design and I'll leave it to the other guys to go into the various more detailed parts of it so thank you [Applause] you you