Eric Evans - Good Design is Imperfect Design

well hello I guess we're at the end of the conference and usually I I often earlier and I say welcome to the conference with this phone saying goodbye from the conference but I've been enjoying it in fact the things that I've been seeing here this week of well basically I had a presentation fairly well worked out and I've redone it about two thirds so different from what I had been planning to present that I hope I don't mess the time up to battle but bear with me the title is the same though and the basic point I wanted to make and one of the problems I think that has been with us from the beginning with domain-driven design is that either it there's something about it that brings out the perfectionist in people and people often get stuck trying to make perfect design and or maybe it draws perfectionists to it it may be that but whatever it is I really want to attack that point tonight so you know basically BDD is not for perfectionist or if it is it's for reforming perfectionist which maybe I'm a little bit of that you know but let's let's stop that now in order to stop doing that though you really have to think about it's not like okay I won't be a perfectionist anymore you have to actually have some idea of how you're going to go about creating software that is well designed but not perfect now let's start with bounded context this concept really originally the purpose of it was to say look the environment in which we develop software is pretty messy the projects are pretty rough-and-tumble we have to deal with a lot of things a lot of legacy systems and external systems and also other teams that may do things differently a lot of stuff and the bounded context is it and yet you know a model of the kind of clean sharply defined concepts that we want to have they can't really cook this with all that so again and again you see people trying to just replace everything just that the total table rasa with everything clean and perfect for all time which just never works not only in software but probably in anything really complex just to review probably most people know what I mean by bounded context and I know that there's been a lot of talk about it at the conference but even so I want to go through the definition a bit I'm pretty much defined it as a part of the software in which you have consistency conceptual consistency this of course there are many kinds of boundaries and many kinds of consistency but this is the consistency that when I say a particular word I mean the same thing or if I talk about a relationship between two things that relationship is defined the same way that's not perfect because this is being created by people but within a bounded context it should be pretty good a bounded context has a boundary around it I should be able to know if I'm a developer whether I'm in that boundary or outside of that boundary and if I'm in that boundary I know that I need to follow the rules that have been laid down for that bounded context and if I'm out of that boundary then I'm free of those rules I might have to follow some other rule set that's been defined within another bounded context this freedom that rather this boundary creates freedom to define the rules that apply here not just what is our design what are our names and so on but the architecture can be different within different bounded contexts the process because development process is never going to be uniform anymore than design it and that's all there is to it I mean now people then extend it and say well okay so I pointed out for example that sometimes services especially when they are very autonomously developed as in the micro service movement that a service development can be good bounded context but sometimes people sort of skip a few of the words in that sentence and they come up with you know abounded services abounding context that's not what I said all right a service where we have autonomous development can be a bounded context if we're doing this or maybe it's not the service itself maybe it's sort of the certain spaces between the services like all the messages that we use to make of these eight services communicate smoothly I will define that interchange as a bounded context and I will use it to define the messaging protocol between all the car all the services that are involved not inside of those services necessarily that's up to the people who own those contexts so an interchange context then is a little bit less tangible and there would be many forms that these bounded contexts take now one of the common things that gets a slipping in to perfectionism is okay we have a sub-domain you know we'll do the accounting within bounded context called accounting will do the purchasing within a bounded context called purchasing and so on so these are subdomains and we'll make bounded contexts that align with these and a team will work on each one or whatever and actually you know that works well that's a good thing to do when we can but I'll get to in a few minutes why that isn't the same as saying that a bounded context should be aligned with a subdomain and how about Conway's law certainly big topic this week and there's an obvious relationship between Conway's law and the concept of a bounded context I think and I want to talk about that in a minute here all this say we want to set things up in a way that Conway's law is helping us by sort of filling our sails so we have to be kind of conscious of that force that is a real force on a software project and especially we want to not get in the way of it right not be flattened by being trying to fight against the organizational structure so let's just imagine that we have a system in these are more or less this is fresh software and fresh software tends to follow Conway's law very closely so we have a team responsible for credit cards and we have a team responsible for cash accountants and they each have a model and the terminology is a little different you see that over here they talk about the amount of a charge and over there they talk about the debit of a withdrawal and you know then you could translate between these two you could come up with a value for the balance of a of a checking account that would relate to the credit limit of a credit card that may or may not be necessary so we've got to your alignment between a subdomain the way that we've chosen to breakdown the business the organizational structure and the bounded context but now as tends to happen there's a reorg so the business says well wouldn't it be better to focus on a market segment the difference between checking accounts or you know cash management accounts and credit cards isn't really the key to our business the key is for example to address business like accounts differently than personal accounts the way we interact with customers different the way we market it is different the kinds of things these people need are different so let's reorganize and so we create a team that's focused on business accounts and a team that's focused on personal account now so now what is the context what does a bounded context look like well they look exactly the same as they did before there's no magic about a reorg that causes the software to restructure itself right the Conway's law will work if there's no software there but if you reorganize the software that's already there will resist a change so now what we've got is something like this where we have two teams they're sort of tugging at these two contexts and the stewardship no one's talked about it as usual as so often they don't or they talk in kind of idealistic terms so we'll just coordinate and cooperate and so they start to make changes you know this team makes a change and that team makes a change now this is a metaphor that I like to apply because I think this is a familiar game here as well all right so who wins a three-legged race well these kids are winning this free legged race they have a good balance between coordinating each other with each other and also running reasonably fast and these guys will they've got good coordination but they just slow runners and these guys might be fast runners but they haven't coordinated well so you know now if we had a regular footrace like just let you know cut the cord and let all the kids run who would win the race you know it is quite a different set of criteria right let's say that it would be these guys the actual fastest runners the independent of whether they can coordinate with another runner so in our software development most of the time it is not a competitive question that is internally it's not a question of do we want this team to be better than that team we want the both teams to succeed as well as possible so what that means is that if you were independent if each Runner was running independently they would all run faster and fewer of them would trip and fall translating that back into the terms of our software development you know what does this trip in fall look like here well you know these guys are adding a feature and those guys are making a change and those guys out of featuring those guys and exchange them so there's a term people have used for a long long time called the big ball of mud and the big ball of mud is a way of describing software that has no structure to that anyone could you know that would anyone would be willing to use the name for and and generally speaking we don't enjoy working on software like that but you know you can make you can make incremental changes to it and it comes about for various reasons but one of the common reasons I observe is that there's not clear stewardship of software there's multiple teams making changes to it we don't fully understand what each other is doing or they don't care enough about the you know the long term life of it and it ends up terrible mess so that comes a concept called anti-corruption layers so this is a kind of context relation a kind of boundary that we might place between bounded contexts and as and it's one of the ones I described in the book is pretty popular and basically it says I have a bounded context and there are forces that I think are going to cause it to become corrupted would be to lose its clarity one of those forces might be a real more a lot more generally I usually describe it in terms of here's a big legacy system that's probably already a big ball of mud and here's a new development team or rather a team on a new development project and part of the goal of this project is to develop a clean model that will help address some new important strategy but if you just start doing that in the context of the big ball of mud you will simply fail it will never work the big ball of mud is just incompatible with elegant models so we build an anti-corruption layer that is a software an actual piece of software whose purpose is to communicate between our software and the other software now it doesn't have to be with a big ball of mud it can be with another nicely designed system but that does not follow rules remotely like out right it could be with external software that we have to import and it might be of varying quality it could be with it could be many things and so this you know this picture of the garden wall and on one side is a public street and on the other side of the garden and there's a space so I was a chance there for communication so there all kinds of metaphors for software right I've probably been responsible for one or two myself and so let's look at another one a community garden so in a community garden we have you know a different plots that are allowed to be garden by different people and you've look at you know typical community garden in it doesn't look like a designed garden like you know a Buckingham Palace garden or something it's got you know kind of wild variation within it but there's an exuberance to a community garden but community gardens are not just free throws you know they don't happen just because you say well here's a you know some space and now everybody go in garden they're actually coordinated my partner and I we signed up for community garden a few years ago and this is a picture of that one and what makes the garden work well partly there are some rules you know some skander for example no invasive plants generally speaking you can plant almost anything you want in your plot of a community garden but but there's a long list of prohibited plants because they tend to spread so then there's some rules around the compost you know if you're going to take your garden waste and compost them they have some compost heaps there and there's rules about what you put where and so on there a handful of rules it's not onerous but they're carefully selected rules is one rule so important and so but kind of obvious it is not even on the list and that is you stay in your plot right you garden your plot you don't go gardening other people's plots but it's a the most important rule and then they provide some infrastructure to they provide some tools and some water you know like a water hose um I was trying to be all eco friendly with a rain-fed watering system and it was a kind of dry summer so that didn't work out too well but the concept was nice a very important service they provided was coordination with the city and other you know organizations so but there's a service it's fairly obvious which is they allocate the plots and they decide who who's at a you know gets to use this plot and when that is no longer applicable reassign a plot to someone else so they don't really do much right there's the space go at it go plant your garden follow these rules but them but there's certain critical things in place they make sure that we have a good gardening experience now this was the plot next to ours and so this person showed up one day and kind of half killed and then I didn't actually see them but I could tell they came because then one day there were some little you know the little plants or packages with the plants in them and they laid a few of those out and then they never came again and the plants sort of grew in their little packets and then died and then the weeds grew and grew and well you know that happens that's the community garden equivalent of the big ball of mud and except it's even worse really because the big ball of mud is actually quite useful but you know the thing is then you were concerned about the boundary right I didn't want all the weeds that they were growing to come over into our garden I spent you know almost as much time pulling weeds at the border between the two Gardens probably as of all the rest of our garden but you know that happens now one thing about it so that's a terrible mess and no one would like that I'm sure they reassigned the plot to a different person the next year right but now the late summer garden you know it doesn't look too tidy either kind of it looks a little messy it's actually probably more structured than it looks in the spring it looks super tidy you know everything pin meet but late summer looks a bit messy but that's when it's actually at its most abundant most productive right a lot of times very productive and abundant things are kind of messy looking there is a kind of underlying order to them that may not be so readily visible I say this to some extent because we do 10 we as a large class of software professionals who care about design we tend to dismiss the legacy systems too quickly I think we don't appreciate them enough appreciate what they've you know what they actually can do how how they've formed into the shape of the business not to say that those systems aren't creating obstructions as well right and it's not my thing to work on those well ok enough about big picture for a little bit let's talk about fine-grained design when I say not everything will be well designed and we have to face imperfection I also don't want to make it feel like I'm saying well there will be some really messy legacy systems and then they'll be within your bounded context you're absolutely perfect and pristine little system that's not what I'm saying either within the well-designed parts things won't be perfect so I want to get really specific and I want you know so to get a specific example I said well all right let's look at something it's actually pretty well designed it's the joda-time library which most Java developers will know about this at least a little bit but it's just a library that gives you things you know gives you date times and allows you ways of manipulating them and it's been a library that people have used for many years in an open source library that's been used for many years in Java and recently was adopted into the Java standard libraries so it's actually Java time now but I'll call it joda-time so one of many features of this library is that you can take a time and you can add a period to it as they call it and get another time so for example you could say take a date 2017 January 20th and then you could take a period and say one month and you can add those you can say 2017 January 20th plus one month is January says February 20th right that's so there you go that's a nice clear thing and you can say plus two months and you'll get March 20th now let me ask you this January 30th plus one months what is this I mean I could think of at least two probably three reasonable answers and so probably some of the Java programmers know the answer but I went in and checked to make sure and so this is the answer January 30th plus one month is February 28th and although I think it's a reasonable default but it still doesn't seem quite right to me am i are you with me on this I mean this seems like kind of fudging a little it's certainly it's not obvious which is a characteristic I like my designs to have if possible and and the rule isn't really conveyed by the name but so you know I said that joda-time is pretty good but it's not perfect so for a starter I'll just say well kudos to them for actually shipping something that's not perfect I'll bet somebody in the Java in the joda-time development community said hey we can't ship this plus period feature look at this you know I'll bet that happen and then somebody else said well it's useful it is true there's some quirks but we need to get this thing out and so they shipped it and for starters I'll say they did the right thing joda-time is extremely useful and if we were as perfectionist as all that would have never been shipped just like 90% of the open-source projects that I say 90% on an eternal optimist so I'm glad that they shipped it but now that you know acknowledging that let's look at what might have been done even without fixing the problem to make it a little more satisfying or something or let's say to maybe make the future path better so I'll talk about honest means so if you look at this you know that doesn't sound like plus plus is the wrong word for that and if I start thinking about well what could the name have been and I do this I'll just have like my notebook sometimes you'll find pages they're just long list of possible names of something that I'm puzzling about so maybe you could say well it's sort of plus rounded right to the nearest month or it's not just month of course but any irregular kind of time period or maybe it's well as a constrained plus or maybe it's plus with a ceiling you know I can think of a lot of possible name and I I would I would just come up with lots of names and I brainstorm names with other people and then I would give it one of these type of names the the thing is that I think there's value in giving awkward concepts awkward name it not only you know you don't really want to call a function in your library plus with ceiling and that's maybe a good thing because that makes your mind keep coming back to it right but you want something honest and the awkwardness is slag plus sounds elegant plus sounds uniform so it misleads let's look a little more at this so we have March 30th plus one month is April 30th and March 31st plus one month is also April thirtieth that's the same thing again but here's an interesting one April thirtieth plus one month is May 30th what do you think March 31st plus two months is well if you won't be able to I mean you can guess and you'll have two guesses and one of them will be right so it's May 31st which seems is right at least as right as the other one so why does this feel so wrong I think that it feels wrong because when we hear the word plus it brings to mind a lot of things it's a well known abstraction and usually involves the concept of associativity and this is not associative so you know one if you add one month plus one month without parentheses you get a different answer than if you put parentheses around the plus or the two one months and things we call plus usually would give the same answer for those two things not always so all right so actually there are lots of very well-defined in you slap operations that do not have associativity it's not like I'm saying all your operations should be associated far from it but I am saying is that maybe we don't want to call those plus not that you couldn't define a plus operation as not being associative but you'll have to tell people you know we could call it let's add some possible names how about plus a non associative so I think that yeah we need a name for this thing and it needs to be something it doesn't lure people into expecting things that they won't get because it's really perfectly valuable useful feature well so I would just take one of these names and I would use it and I would be a little embarrassed about it in the library but it would be out but it would also be sort of flagged as you know this is a nice operation but a little bit awkward now there are other operations similar looking ones the periods themselves can be combined with a plus operation so you can say period plus a period gets a period one month plus two months is three months and the thing is as far as I can tell but I haven't exhaustively tested it or anything but as far as I can tell this actually does follow associativity so you know one month plus two months is the same as two months plus rather one plus two plus three or wherever you put the parentheses it comes out and saying as far as I can tell with a cursory examination so probably plus is a good name for that you know and so I'd keep that one so basically I'd have something like you know period plus period but I might have you know time plus ish rounded ceiling period I probably would use all that one of those CNS to to market but that keeps something's going to niggle in the back of your mind you know just keep jiggling possibly for a long time and then there's always the chance that in a later iteration of the library you know someone comes up with a nice idea for a different model or a different name one day you might be playing Candyland and I don't know if people play Candyland here it's a game when I was very young it's like a game that I think it says on the Box like ages 4 and up and basically you draw a card it has a number you go bump-bump-bump up that many spaces and then the other persons are all the card and it has a number and you go bump up that many space that's yet now the here's what's interesting about this game so suppose that you were on this you know you're near at the beginning you're on this purple square let's say you draw a six so you go bump bump bump a bump right that will take you 1 2 3 4 5 6 over to that purple square by Lord licorice there okay now let's say you drew a three and then another three I mean you draw a three in this turn you go bump bump bump and you're in that bread square and then all of a sudden you go zip right over the rainbow trail in your next turn you draw another three so bump bump bump now you're in that red square you know and your already almost over to that peanut-brittle house order so what that says is that these moves that you make in Candyland are not associative I can have two moves of three each and if I advance three and then three that is not the same as advancing six so ah that's interesting there's a system that it has this sort of you know progression in it and yet it isn't it isn't associative so makes me start thinking well okay another metaphor the calendar is like a board game so we have rules to move game pieces around that are less regular than just you could make a game even simpler than Candyland I guess that had associativity but I think even four-year-olds might get bored with that game but here's the thing we would not call those things plus or plus rounded you know plus with ceiling well we have other names we say things like you know move forward so many spaces or maybe advance so let's try out that language with our time library so instead of saying time plus ceiling period is a time we could say plus advance period gives us another time the nice thing about this is that the term advance doesn't make me think about associativity it wouldn't I don't expect that it will be like addition where I I guess I'm sort of on unprepared for a rule like if you end up rolling over a month you stop at the end of the month it doesn't tell me what that rule is but it tells me that there might be rules like that if I say well how would that you know maybe there are other words I could use things more time related like later so I could try out you know time later by one month gives me a time again later by a month doesn't suggest the same things to me at least that plus does so actually I don't change the functionality at all I think I have changed the model though at this point I think I've changed the model because we've subtly without hardly noticing it we have changed the concept of that operation we were thinking of it as a mathematical operation plus like at least something like plus but now we're thinking of it as movement through some kind of a sequence and sequences can be much more arbitrary so I would be happy to have advanced or later as the operator at that point I would even you know I wouldn't consider those particularly awkward names okay so anyway there there is what I'm that was one point you know basically that I wanted to make about how I would respond to these imperfections in the model not by trying to perfect it but by trying to make it more honest about itself may not hide kind of awkward things under pretty names now mean one so sometimes it isn't so much that your model is a little awkward in the spot maybe it's just a little incomplete or you know can't handle all the cases or something I remember the that I was on a project once and we came up with really elegant model it was easily understood by businesspeople and it could handle like well over 90% of our cases and and it has almost mathematical kind of clarity to it but it only handled you know I don't know 90 or 95% of the cases and we did have to handle all the cases so what I do what do you do so one thing we did was we explored other possible models you know and they could handle more of the cases most of those models were rather awkward sometimes they contrived like you know weird little appendages sometimes they were just a whole different concept there was one constant one model I remember could handle a much higher number of cases but it was sort of very abstract and it didn't communicate to the business people at all so I considered that to be a weakness so anyway even with it we were stuck with a model didn't cover all the cases and we had some very awkward looking things that did cover all cases what to do so what we actually decided to do we created a function and we called the function cases we haven't figured out yet so when you know one of these requests came in we could identify which category it was in and we would either put it through the really elegant model it handled nearly everything and by that I don't mean happy path I mean it could handle all sorts of strange cases just not all of them so we would put most of those things through there and then the other ones we put through this other function and this other function had a funny rule we said no abstractions of course I'm sure we must have had some abstraction but no high level concepts here use if-then-else logic so that we don't start creating a whole other kind of weird awkward model here and those if-then else's did not proliferate too wildly because we already remember we're only covering a few cases right and each one of the cases we didn't know how to handle it was basically covered by one of these things so basically if you were saying oh yeah we can't handle the case where this and this and this so well add a clause if this this and this then do that now writing a whole system like that would just be you know not domain driven design at all I would not be modeling it would just be actually the way lots of people do write software and it can work and in simple cases it might be the best but what about a complex case like this where we have a model that we like but that doesn't quite cover everything well we have a model that we don't like that does cover everything etc this was the trade-off that we made and I thought it was a good trade-off and in fact what would happen sometimes as we saw the cases remember you know as they accumulate you can kind of get some sense of what you haven't figured out I would start to get glimmers of like you know I think I might see a another model that could handle more of these cases and I could have conceived of a situation where we might have a couple of elegant models and still a little spill zone where 1/10 of a percent of the cases that we just couldn't handle to go in there with if-then-else if they male but I wasn't I don't know how that came out actually a lot of times I'm involved in a project for a while and I don't see the very end and I suspect that it looks exactly the same as when I left but with a few more clauses because one of the things this allowed us to do was to move on to actually complete that functionality and ship it and that's what you've got to do right you have to get stuff out we have to get Oh this idea that design is something which you invest some extra time in upfront and then it gets paid off in the long run I don't think that's what really happened I think most of the time we invest upfront and don't get paid off in the long run because the investment upfront is just all spinning our wheels trying to imagine the perfect model or trying to finance us when we haven't got our hands dirty enough to really understand the problem yet so you figure some stuff out and you get it shipped there's a model that's the best one you can come up with right now and with some honest name and maybe a spill zone here and there and then you move on and you ship and repeat the cycle whoops whoops the spill zone is kind of a specific example of a principle I would apply more broadly if you've got a abstraction that's really leaky or an abstraction that's really confusing or vague just don't use it it's better to just program if-then-else than to program with something that gives the illusion of an elegant model but actually has to do all that same stuff through more hidden means I mean if you have a abstract interface but then when you actually get the value ask to check instance of instance of to see what class it really is or whatever well then that's no abstraction that that's just something that will make your thing look superficially like a nice model it will actually get in the way of finding a model it will really help better to be honest if you don't have a good abstraction then don't use any abstraction I didn't say perfect though use the perfect abstractions that actually help now there's two different things I'm kind of talking about a little bit at once one I've been talking about how in the actual production system we have imperfections and we need ways of sort of highlighting them we need ways of separating different types of you know the Messier bounded context from the nice ones ways of sort of marking an abstraction as having some problems in the discovery phase exploratory phase things are messy and there's no reason to fight the mess at all this of course the picture from Alberta Brandolini workshop earlier this week and Alberta of anything Alberto is involved in is always extremely messy and out of it comes tremendous creative productivity and of course out of it can come real clarity as well right just because the process is messy doesn't mean the end result is messy so what I've talked about up to now is mostly the part of the actual end result that I don't like it's not perfect and saying we got to go ahead and ship and flag them but this part there's no reason to resist it at all a reason to try to make this seem orderly at all and people do people say well what's the first step now to getting a good domain driven design model what's the first step and what's the second step of it sir the DDD isn't like that this is the diagram I you know made a few years ago called the whirlpool I called it that because we've always used the waterfall method or everyone likes a waterfall method you know and I said all right if people want a violent water metaphor that will give them one and so the waterfall method you can see why it appeals to people because you go in a straight line you go along the river metaphorically go along the river and you go a little faster always in a straight line and then at some point you're going down the waterfall and so you go faster and faster and then you hit the bottom and the boat breaks on the rocks and everyone died so it's a very good metaphor because it describes what really happens now the world whole model I thought well okay I think this it was also a good metaphor because it also describes what can happen on projects where we do modeling and design the risk of a whirlpool you'll never get you know carried down a cliff and crash on the rocks but what can happen is you'll get trapped in the currents and you can't get out and you just eventually become exhausted and then you just slip under the waves and drown that's what happens to design project if they get too perfectionist if they don't do this and talking about it just saying you know this isn't perfect but it has value in it and it's going to ship how can we do a few things to make sure that we don't just hide the issues that we have and now let's get it out actually I don't even like to make things quite as tidy as I could make them I must admit that when I'm still not completely haven't complete don't completely feel settled about a certain concept or a certain term I actually kind of like to leave a few loose ends around here's an example let's suppose we had a method in this application that was doing something with you know now at this point we have modified the time library to say later rather than plus and later I kind of like that word actually I still maybe don't feel entirely settled I think well I'll just keep a little bit of the jangling going for a while so I we've used the probably probably preferable name in the library later by but here in a less public place where we're doing application logic I've got a method that says advance to because that word advance didn't seem bad either and then sometimes when I'm you know walking in the woods thinking about stuff and I'll think maybe advance would have been a better name more like the board game and so I've still got it in there and someday we could refactor this away it'd be hard to refactor the library if we decided someday we really like that but another thing that happens is see that if you don't resolve all those tensions then somehow you keep thinking a little bit you know and sometimes you get a real conceptual breakthrough that that really does take you to a different place so this one maybe we don't even need to try to do this but still I know that I am NOT as tidy a coder as a lot of people are and so one I remember it's a few points in my life I thought I should do it like those people do they're right you know I'll do all I'll do all these behavior preserving transformations and I'll reflect their names completely in blah blah and make everything very consistent and then I slipped away from it again and then I do it again and I thought boy I must be really lazy and then I realized it wasn't laziness I actually when everything was tidied up to that degree I felt like my creativity disappeared the way I thought about this the design changed like it was a done thing that could never be changed or that's me you know maybe not everybody's like that I think it might be ok to have some tension even in code now here's one that will upset some people dry you know don't repeat yourself I don't believe in it or what I really believe in it I do believe in it within a single bounded context I think it is a rule that works well if you are working within one of those very well beside the well bounded areas where we are trying to make a very tight model and design and that kind of context not only are we going to try to attain that level of perfection but we are also it actually makes sense so when you talk about between bounded context first of all it isn't practical think what it would really mean if I'm developing a feature now I don't just mean like copy paste although I might be okay with that in some situations but I don't really mostly mean copy paste I mean I'm developing a feature and somewhere else in this enterprise system there is a similar feature it has a different name I don't know how I would even know it was there the only way I would even know it was there is if I had a high-level communication with everybody else in the whole development organization which I just won't or if we had a big infrastructure of oversight you know lots of architects roaming around looking of approving everything you do after having exhaustively looks for anything similar that might be a duplication now just to plication really sound so bad so here here's a two bounded context okay here's a kitchen and a bathroom and actually there are a lot of commonalities I use very much of the same infrastructure right they both need water and plumbing you know more so than any other part of the house right in many ways bathrooms and kitchens parallel and so let's take a specific feature both of these in both of these context we have a way of disposing of solid waste okay in the kitchen most modern kitchens the sink has a garbage disposal so if you drop food down into the drain and you push the button it will grind up the food and it goes down into the sewer and in the bathroom we have a toilet and I don't need to explain to you I think Cal toilet sick disposed of solid waste so shall we refactor and we need one way of disposing solid right all right so maybe we agree that we are not going to do that this DRI is just a principle you know it's like a heuristic that I think is a good heuristic for certain kinds of bounded context internally where we're trying to get that kind of consistency it's not even a good heuristic for all bounded context if you if you have one where things are a little free-for-all where you're sort of halfway to a big ball of mud or not quite there but it certainly doesn't apply between bounded context even if it weren't for you know the Grossman's factor there's the coordination overhead because if we do develop that feature you know remember I said oh I'm developing a feature and someone in a totally other part of the organization has already developed a feature that is very similar not a feature but say a capability within the system and so we're going to factor that out and share it and this means that instead of running a regular footrace we are now running a three-legged race and I have to stay coordinated with those people and if I do that with another one and I guess it's sort of a four legged race because I'll have one person tied to this angle and another one side to that ankle and we'll all be running like that we don't even try to do that at kids fairs because they just all fall down and out yet so I just don't I just don't believe in that so I guess I'll review a little I'm gonna wrap up we you know we there is a cycle that happens I suppose we're a cohesive team we'll build some coherence software in a well-defined context but then a reorg happens or just the original team is on maybe and the new team doesn't quite understand it anyway the the software starts to degrade and eventually can't really do what you need to do you can't innovate around it the way you'd like to so we hopefully at some point kind of create a new above all context as I sometimes call it where they have a Anti Corruption layer and we protects it from the other system and when we start developing fresh and so we're back to the cohesive team working in a nice coherent context and then of course the cycle repeats over and over I think this is just this is probably just natural this is just the way it is it might actually happen a little less if we were less perfectionist because not only would I be you know like in a reorg I might be thinking about what's going to happen to this software now it's not going to magically partition into these elegant new subdomains that but the business has taught has come up with so we might create new context to deal with these new approaches and maybe actually build an anti-corruption layer to protect the legacy system because the legacy system at this point is a valuable and coherent piece of software it just works in an outdated way so we create a translation between it and the newer stuff you know and and so you can look at it both ways what's corrupting what sometimes the new can corrupt the old as well and then you end up somewhere you know a big sprawling system with lots of choices that you'd rather you know not have made and in inside of the bounded context I'm sure that if you talk to the people who actually designed the johto library they would say oh you know every one of them would probably say well this is the thing I most wish we had done differently or that's the thing I most wish that we had done differently but nonetheless the truth is they did a good job you know they shipped these things are path dependent and we can't always and a lot of times it's like we want to start fresh we want to say well you know find you then what I know now and I do know what I know now now so I'll just build everything there even context boundaries like you know I talked about building those divisions between different contexts and translation layer and so on even those things time moves on from in New England where I live and I'm sure in lots of places they used to mark property lines with rocks that they would get out of their field and just follow them up on that edge or kind of make a little wall well here's a case that you come across this now and then walking in the woods and there's one of those things just running through you know it's no longer dividing property maybe it's all a park now but this is probably two different farm fields 100 years ago or something on them so even the anti corruption layers might kind of get passed by be compromised so many times they're no longer really working and just sort of the to context that they were separating merged into one big ball of mud and the former anti-corruption layer is part of that big ball button so you wouldn't change it either now that's just part of what happens you know we have to think be less hubristic and then we will produce better results what I am really saying is if we want to produce beautiful design we have to be less perfectionist and and a lot of the things we tend to do and I say this because I think the DVD has in reality contributed to this feeling that everything should be so perfect though it wasn't my intention but I think you would agree you have to take responsibility for the actual outcome of things not just what you wanted to happen right and so I'm saying this is hubris and it also doesn't lead to the outcome we want it doesn't lead to better design but will lead to better design is a more pragmatic approach and more humble and another thing is I think we need to broaden our aesthetic I myself have a tendency to prefer that sort of clean design the model that has you know sharp edges and everything wise I mean I'm the one who just got upset that the + operator and joda-time isn't associative so that's me but you know you broaden your aesthetic a little and you can appreciate the things that are going on in other kinds of software in the legacy system that's been running for 20 years and has somehow kept the business running all that time this is a picture that was in Rebecca where Scott's presentation this morning and I asked her if I could use it because this is a tree she took a picture of this tree in Kyoto Japan and it's obviously a very old tree I think most P would look at this and say this is a beautiful thing that is something very satisfying about this tree but it's all gnarly you know nothing's straight and the thing is can't even hold itself up you know it's propped up with these posts with this careful protector around the limb now if we looked at this tree the way we usually look at legacy software we would say look at that mess look at that gnarly old tree you can't even hold itself up haha what we need to do is we need to cut this thing down and plant a fresh new tree that will be perfectly straight and strong and people can climb on this and that would be a crime right I see most people would just say oh how could you do that now I'm saying legacy software is you know like this exactly but if we who have a tendency to over appreciate the other kinds of aesthetics and under appreciate this if we deliberately bias ourselves in that sort of direction then I think it would be a healthy thing right to look at that legacy system and say well I really don't like it and I'm sure I never am going to like it but can I learn to see what is there you know to see the value it's there and then when I'm building my own stuff be a little easier on you know myself don't don't beat yourself until the thing is perfect because then you won't and what we do sometimes do is just Carine between perfectionism and then oh my god we've got to ship something so we just hack out something horrible and ship that and just Carine back and forth between these two extremes I'm saying is we will get much better result if we're more conscious about this trade-off and and even have techniques for what we do and we're not entirely satisfied with the model that we've got so thank you for your attention and thanks for a great conference [Applause]

Channel: Domain-Driven Design Europe

Views: 15,715

Rating: 4.8392859 out of 5

Keywords: dddesign, domain-driven design, ddd europe

Id: lY54TmmEllY

Length: 66min 28sec (3988 seconds)

Published: Wed May 10 2017