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

so this talk which I did actually in March hence the August through March but I'm really learned much in the last four weeks or so so this will be over the last six weeks I mean so this will be close enough I did it at Q con Lennon where they had a DDD track and that was quite interesting one of the patterns in the book is 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 how 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 projects 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 creative so it's very important to underline that every effective Dedede 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 thing is 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 book to bringing 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 I'm waiting oh thank you okay there would be one and quite a few the patterns are actually about creating this creative collaboration of domain experts and software experts but let's just 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 experts side of things anybody here not a software person like you're involved in the more in the business side everybody here is software guy yeah exploration and experimentation so many times and still as I go around sis all these projects and they're trying to do DDD and so on and one of the 90% of the time they are not experimenting it up 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 hit a glitch or to do you say okay we can work around this we can work around that and you've already frozen yourself mind into that shape of that original model and so you're already working around its limitations instead of challenging it and saying it doesn't handle this case very well let's go and look at what the options are and I mean blast it 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 the language evolves and the model evolves 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 maybe 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 who do you explore with somebody can say them thank you little Maina good you'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 it talks about the importance of explicit context boundaries if I had it to do over again that would be in Chapter two or three and it is so important because just like 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 it 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 what you'd be guessing at 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 would have drawbacks 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 map I've seen many projects where I would not have done elaborate object modeling or any other kind but I've never seen one that wouldn't benefit from some kind of context map and finally focus on with core domain that's chapter 15 sadly but the core domain is 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 say save five percent a year over the next five years by doing this process incrementally more efficiently I mean that there was a whole new market that we could get into if we had this software or we could defend our market share from that other guy who can get it something significant okay 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 core domain moving on there's a section in the book called building blocks and this is talking about the problem of alright I'm modeling and in a sense our modeling paradigm is too general in a sense it's just saying well we have objects and 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 objects you say this is a value object and someone else who knows these patterns will immediately be able to infer a lot about that so communication is better but also people's through experience have found that certain kinds of you know characteristics of objects make them more useful or certain 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 a software that really reflects the conceptual model which is part of what we mean by the ubiquitous language right that it goes all the way down if I talk with a domain expert I use 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 emphasized although I do think they're important people get very focused on them 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 over emphasized 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 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 where you 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 over emphasized anyway and maybe you wanted to be an entity but you kind of wanted some of the characteristics of a value object and ability perhaps and neither one really seemed to capture and so what has come along and yeah there was a nibbling of this even before the book but what'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 cert and not everything like let's say that this is recording that there was a someone had a ball on our they had four balls I walked in otherwise they go to first base so you could you could record that 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 another on them and then they got to first base but no one is interested in that right a domain event like anything in a model zeroes in on something important to the domain expert so domain expert cares that someone reached for his base that care that there was that there were four balls or whatever or maybe there was a strike or it's free strikes and this guy's out and so but you know along the way to the strikes well you know the guy swayed back and forth and he raised is bad up and all of these are vents in fact in our system 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 right we're talking about that level of event that you want to record it was something important that happened in the domain and they have a kind of consistent form to like they tend to happen at a certain time they tend to have some person associated with them maybe the person who recorded it maybe 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 you 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 it'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 happen now that's really an important thing that many of us have to deal with and domain events are really valuable for that so because they okay so let's imagine a kind of an extreme approach where we say that you don't just modify the state of objects you you have events right an event happens and as a result that state 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 I guess is an entity in their scores and value that they would have and it goes up and someone gets a point that's really all it can't you change the two to a 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 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% 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 a run happens since you know that hasn't yet reached you maybe you've gone off to the concession stand and someone asks 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 that I'm out of date or someone says to you no that's wrong you know there was a run since you left okay now I update my score and I this is is really vital if you 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 a distributed system you it can be extremely complex but with the or it can be fairly simple if you if you have more of an order you representing the state of entities decoupling subsystems with event streams now here I mean design decoupling I'm not talking about the runtime the decoupling of runtime 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 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 a 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 their reporting and analysis and all that and they just wire it right in to that transactional system they'll 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 all and 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 any particular functionality in that of 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 in another kind of similar problems is to say okay you have your core transactional system or whatever someplace that you want to encapsulate 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 the analytical people the reporting people all then they can subscribe to your 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 in put it into their own database denormalize put it into a data cube if that's what they like and if you change your internal system we'll 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 wanted 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 or 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 trading system and use those to base that on and then those two systems can evolve independently at each other don't remember get 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 or we if we link these two things together we end up with kind of a compromise that's not all that good for either one hopefully good enough instead by this level of decoupling you can have a model that's very good for trading and a model is very good for analytical error analysis of those trades 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 you're using make sure they don't get all mushed together into a mess help you 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 so that context map is so fundamental this allows you to you know decouple 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 and for clearing but if you really want two different models then it's a great way to communicate between these two contexts okay there's one more about these domain 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 of DDD I think that when you have to handle truly high transaction volumes or that you are probably you just with current technology anyhow you just can't keep up with it with the overhead of an object-oriented system or elaborate models or that's a luxury that you may have to forego but I don't say that anymore because there's this guy Greg Young who I was presented at a few conferences who built this system it was oddly enough a trading system I guess in the but that that's where a lot of the DDD action happens is in the financial industries and he had to handle tens of thousands of transactions per second and he didn't give up though on objects in fact he wrote to saying C sharp with C sharp objects and mostly pretty standard dotnet frameworks but what he did was he he went to a 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 you know would so to take my tired old example of the trading system but you have your order book and you say God in order and somewhere over here we actually have a partial fill so the order is now reduced but he wouldn't change in the order say the order was 10,000 shares and how you've executed 5,000 he wouldn't change that to 5,000 remaining he would just take the execution 5000 share execution and he would just just put it in that collection now you can compute that 10,000 minus 5,000 and it turns out that this this and a few tricks that he can explain far better than I can I was just an amazing effect on your scalability and he he said that he mostly as I said used off-the-shelf net he had to write a custom message cute the ones that they had were too slow for his mean 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 okay still in the subject of the building blocks but not those so this is the most abstract of them the I think this is excess super importantly aggregates perhaps the one building block that isn't overemphasize you don't hear 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 interesting that question because I think it's not actually what's important about aggregates 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 to speed and every it's 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 little grapes is part of this great bunch in fact in French the word that the cognate of grape actually isn't really a cognate it really represents this so it's one of those funny kind of examples of a word that's almost like the other one in just the way that would be most confusing now the classic oops the classic example of an aggregate might be a purchase order where the purchase order as a whole might have properties like well let's say the purchase order has a limit we've approved $5,000 for this purchase order and then there's an amount that it has in it well we've got line items in this purchase order that add up to $3,000 and all is well and good and in a traditional system this is actually one of those common examples and they say well you add up all the things in the purchase order object compares that maybe 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 oo kind of stubs its toe 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 or 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 torpedos sincere attempts to do DDD because they run into a few of these things and they start to think well this just isn't practical or they say well we'll keep doing that modeling stuff but meanwhile we have to do this other thing so they'll have a query a simple sum in their sequel database will do the job and they'll put it in the service probably and you know so all of a sudden what you've got is you've got mEEMIC 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 someplace else maybe the services well so the aggregates is saying you know there are things bigger than an object that have a cohesive wholeness to them and those things we want to they have their own properties and they have their own rules so in this case a purchase order as a whole has a in an amount that's ordered the ordered amount 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 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 route of this aggregate owns these other objects and is responsible for collecting together all their individual amounts if I don't quite go that oh I think that's over specifying the problem or 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 may be that I need to do a sequel sum 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 but I 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 weak point in the oo paradigm that oh oh is really good at handling these little interactions of objects of individual objects and it's not so good at handling collections of object big collections now the of course relational databases are potentially really good at that kind of thing but what we what we need to do then is think a little long straggly so what do we do okay then when you start to think about an aggregate in the abstract you're looking at basically this boundary within which we see it as a conceptual hole and we want it to be consistent remember I was 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 me 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 you can't release a purchase order if it's total amount is more than its limit so we add up all the line items we discover that they are $12,000 but the limit was $10,000 so 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 consistency 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 it 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 kinds of pieces that are not so big but not a single object either and then you 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 we couldn't spend more than you know thirty thousand dollars a month on this and so this this purchase order is ten thousand and this one is ten thousand you know we've got multiple purchase orders now and we've got this guideline that says we're not going to go over well if we've defined our our aggregate as being that purchase order each of those purchase orders has to be completely consistent at the time of its at its transaction commit but it doesn't mean that it has to be consistent with all the others 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 I might yeah of course I'm not saying that this is the way to run a department so I'm just saying that's what it would mean that 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 II you just have to have stuff 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 and what doesn't have to be and 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 okay we need to pull this thing with it too and every one of these decisions ad hoc and separate so that you've got a situation no human being understand and if you can't understand it you can't change it so instead of that keep pulling back to the mom you say oh 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 law how can we make it make 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 note of the network in order for things to work well in a distributed system well that's not the end of the story the 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're causing that we're 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 whole it has properties it has invariant rules all right moving along what have I learned now we talk 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 it just doesn't come up that often so if you're going to skip a chapter skip that chapter and luckily it's 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 isn't doesn't come up all that often so let's move along the other ones I've already talked about right distillation and just to end context mapping I already said our importance of those work okay here is another thing setting the stage what does it take to set the stage for a successful Dedede project well one where you're going to do some cool modeling and build a system that maybe couldn't have been developed another way or could have been by some army of thousands of developers but then it couldn't be you know agile we 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 we 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 anyway but the bulk of the system is pretty straightforward stuff there's lots of crud lots of just data that has to be collected and maybe reported on or maybe the ability to view it and just keep it as reference information but the place where modeling pays off the most is in those intricate little problems where there's a lot of business logic in kind of confusing cases and if you can focus down find a way to not spend much time on those big simple set big you know they may be complicated in the sense of just how huge they are but they are not intricate focus down on those intricate parts then another way of reducing the amount of modeling you do is find out what 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 them but you are you know what you want for a DDD project that's really going to be valuable and everyone's going to walk away and say well that was that was cool and that was really valuable that is getting me in the core domain there's 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 look at some of the Apple products and people say 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 mp3 players they were utterly focused what is it people want with their input 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 a feature or two that they didn't put in I'm saying though that if you want to you know built great do modeling modeling is kind of an intensive activity if it's spread too thin it just recreates 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 oor mappers and things what do you need to know our mapper 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 context boundaries are but it's not enough times because if you've really got to have and so bounded context is the thing I said you know that that context map that tells you where your contexts are and has boundaries around them 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 this space things are clean you don't have all that chaos as 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 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 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 it's funny thing in the last few years since I wrote that book where I wrote in the preface there are two prerequisites to ddd 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 ddd or even more commonly is well we just don't really have good access to domain experts but we want to do TDD anyway so I want you to help us figure that out and then it's surprising how hard it is to get across sometimes that what I mean is that you must have these things you 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 at it 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 won't work it's like you know 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 driveway is full so don't do it okay I'm going to start going a little faster context mapping this thing I keep bringing up but I've learned a few things about this too and one of the things is well Kay already told you that defining context so one of the things that I have learned about context mapping is that well so they're okay for those who aren't that familiar though with context mapping there were 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 has to build a sort of defensive software structure we called the anti-corruption layer to keep what 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 moral cooperation and I realized as we were actually trying to do all the context maps of many different projects 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 dependency 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 an 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 you 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 chose this picture this is a three-legged race anybody ever participated in a three-legged race yeah so two people's one leg is tied together and they have to rent 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 runner it may actually be a disadvantage but what's most important is that they manage to sync up very well so they run at exactly the same pace exactly in sync with each other and that's really who wins the three-legged race these people I think are winning and those people must be pretty well synched these people are out of the race they one of them went too fast maybe I don't know anyway the point is that to win you have to be cooperative not because you want to be because you want to win okay 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 of the original version and or if you just google for a big ball of module find it and these guys observed that there was very little written about what as they put it was arguably the most successful architecture ever right and that's what they call the big ball of luck where people just do stuff people just you know when they need a 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 it usually looks like this and so I thought wow that's brilliant and not only that but you see it all the time and people and people get kneecapped by it too because they'll feel like if they're going to do ddd they have to fix this this doesn't look like anything that was in my book and so how do you do that and true this well I don't know how 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 in one 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 in some terms of something real how do I know where the big ball of mud will sprawl and where it won't big balls of mud send to sprawl they tend to reach out the tentacles anything nearby will get sucked into the big ball of mud 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 mud 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 ball of mud is not destructive as the big ball of mud uses 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 the mud will come oozing in it will not make your system stop 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 no one will be able to change it anymore but you had a year and you've got something valuable built but you couldn't have done if you just admitted that there was going to be a big moment and try to build it in the ball of mud so okay that's guess in fact I'll bet if you could you know in archeology 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 them as temporary but they built highly organized systems there and then eventually the ball of mud enclosed and it will enclose yours too but but that doesn't mean those things weren't valuable doesn't mean it wasn't valuable right you have that year and that year what you could do in that year what it might take ten years to do in the ball of mud directly or just couldn't be done and also be fun which i think is a important value also of course a moat or a wall is two metaphors for that obstacle like boundary my boundary has to take some form you know so I've actually seen cases where the adoption of a new technology and usually I say oh through new technology are just distracting yourself I've 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 than there was about the old technology it's because it's an effective boundary the old ball of mud which was say you know written in COBOL of course and but it can't use directly it can use indirectly and once it starts to ooze it becomes a 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 really can work and I'm not really going to propose the people adopt a 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 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 of money is just a ferocious project manager I've seen those cases eventually people do leave your bone you're a 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 context I think that I have much more in the last few years emphasized the importance of strategy maybe coming from a small talk background gave me a certain bottom-up bias that I 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 line faster than you can make it on the same time if you are working on some problem that is secondary and not directly related to the core domain you may well succeed in delivering and everyone will yawn they'll 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 core domain 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 okay I just want to talk about this little DDD in SOA there's like a whole category of things I could do in this and that is something and DDD MDA and DDD what's the difference or why should I use DDD instead of SOA I used to get that question a lot okay what why would you use DDD instead of SOA well you wouldn't you wouldn't use it instead of SOA the thing is that people forget how fundamental is modeling stuff is modeling is just a system of abstraction now what do you think a 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 you pass in this sequence of strings and hence and you get out this sequence of strings and that's the definition okay but that's not really the vision I think that the SOA people had at the beginning they had something much more conceptually coherent in mind but these services would mean something and meaning demands context and so a service interface has to be defined in some context in these same contexts I was talking about context aren't just for the objects or whatever in fact they apply to COBOL programs and they apply to service-oriented architectures and then the internals now often you'll find that the inside of a service is radically different in its concepts than the published interface with the actual implementation it's based on a whole different worldview 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 rephrases 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 that sometimes that service interface defines a context boundary for you remember I was saying look for the things that can mark them off maybe you don't have to go to a whole new technology platform to escape the big bowl 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 listen to that well anyway my point here is not to go into all this nitty-gritty about it to point is to say this question just you know that question I mentioned why should you use DDD instead of SOA it doesn't even it doesn't make sense DDD helps you make better SOA to better s away

Channel: Vladimir Gitlevich

Views: 37,031

Rating: 4.8476191 out of 5

Keywords: Eric Evans, Domain-Driven Design, DDD, DDD-NYC

Id: lE6Hxz4yomA

Length: 65min 18sec (3918 seconds)

Published: Sat Oct 27 2012