DDD By Example - Paul Rayner - DDD Europe 2020

[Music] [Applause] well good morning everybody so it's it really is such a privilege to be here DVD Europe is and this community is really one of my favorites and I kind of think of this talk this keynote as kind of like an appetizer for a tasting menu today for domain-driven design my my hope is that I will encourage you to learn more about domain-driven design and to take advantage of the opportunity that you have today to do that so you can think of it like an appetizer or maybe like an aperitif if that is more your your style and what I'm going to try and do is to give you some signposts in your journey as you discover domain-driven design and not only as you move through today but the rest of this weekend and beyond my hope is for you to come away from this with not only an understanding of what domain-driven design is but but also some signposts for your journey as well so in the last ten years I've been working as a trainer and a coach helping teams succeed with domain-driven design I've seen teams do amazing work and I've seen some other teams really struggle and have a lot of challenges DDD can seem abstract if you've read any of the material maybe you feel like oh there seems to be a lot of jargon involved in this where do I start it's a little bit I think sometimes like learning a new skill like you take up a new hobby and you get on YouTube and you start watching videos of people talking about that hobby and pretty soon you're mired down in the details of these experts talking about all this stuff that you think well I'm just a beginner I'm trying to get my head around this I don't do I really need to worry about these kinds of things and since domain-driven design is a little bit like that and it also involves an evolving set of patterns and techniques it can be a little hard to pin down I really want to say don't list this don't let this discourage you though there are common elements that carry through signposts as I mentioned and these are what I'm going to cover today to give you a place to start let me tell you about my first experience with domain driven design I was a tech lead for a company that sold extended warranties and so this isn't the exact slogan for the company but something similar to that extended warranties warranties that a consumer can buy perhaps when there is an appliance store or something like that to cover their product after the manufacturer warranty expires so it was the technical lead for this major development project to develop a completely new warranty platform for our company this was a major project and I was excited but nervous to take it on the project seemed to be going very well at first we had our challenges we had a distributed development team it was spread across three cities I worked in Denver we also had a group in Chicago and one in Buenos Aires so we had three time zones two languages people just getting to know each other on the team that whole aspect of it made everything more challenging the other thing is that the communication style in the company I was working in was perhaps not ideal for the type of project we were doing so this is a sample email exchange that occurred around this time what we found was that the developers so this is someone on the business side of things this is Pam the accountant now what language is she speaking she's speaking primarily the language of the business right she's asking about a thing called retail price that's a business term and so the businesspeople would tend to speak in their business language and the developers spoke a different language this was the response from John the developer this is the actual response from John I'm not even going to try and read it now I could probably figure out what some of these things mean just by squinting a little bit maybe it's something to do with an amount and there seems to be some STP F is maybe a percentage I don't know but we had this was the style of communication that was typical when we started so John replied the Pam and then Pam emailed the business analyst and this was her response I'm not even going to read it but it's hilarious so the development culture in this organization was that developers spoke their technical jargon and the business spoke their business jargon and there was very little overlap so we worked really hard to improve the communication and collaboration between the business and the development team but it wasn't easy we were doing agile we were delivering and demoing every two weeks and we were producing high quality code so I was feeling really good about this is the technical lead and things seemed to be going really well fast forward to the end of the year and it was really discouraging to learn that after about six months of hard work our business stakeholders were very unhappy with our progress they told us they were ready to cancel the project why well looking back a big part of the reason was that the project had taken the safe route we'd focus primarily on technical success we'd been able to pull together a great team of smart people and the functionality we were demoing was really good but it wasn't really what was most important to our organization what we had decided to do was migrate over one of our existing clients and that client was low risk which was made it easier for us but also low value to the so they didn't really it didn't really matter much to them if we succeeded on that for example we could import warranty data from our clients into our database but we hadn't delivered much more than basic functionality beyond that and after giving a demo of our latest iterations work to them at the end of that year this was the thing that really killed me one of our stakeholders senior stakeholders the VP asked me why she should even care so after six months I felt like a failure somehow we had failed I had failed I didn't even know why at the time I was worried and I was scared was I going to lose my job even more concerning to me was this nagging thought that we were focusing mostly on the easy bits as I said that the technical parts we understood I was nervous about all the complicated business logic that we would be implementing later on it was lurking there dangerous and one day it was going to surface you had that feeling on your project sometimes something had to change if we were to turn this around and what could we do differently now what I've discovered in the last 10 years is many so-called modernization or legacy rewrite projects fall into the same trap that we did you know focusing on the things that are not all that valuable to the business of being mired in implementing what you might call table stakes functionality maybe functionality that's mission-critical but but that's not market differentiating that is not actually moving the business forward and that was certainly a trap that we'd fallen into be wary of that well it wasn't easy convincing our stakeholders but what we decided to do was to change direction in the new year to go all-in and migrate our most challenging client over to this new system we were developing I was terrified we were going to be implementing an end-to-end solution that didn't shy away from the inherent complexity of that was there in supporting this client they had the most data and also the most complicated business processes so this was terrifying for me as the tech lead why because this new effort could not fail because if we did we'd probably all be looking for new jobs - nervous laughter right as we move forward with this new direction we immediately noticed an improved level of engagement from everyone on the business side of things and that's that's what we were hoping for conversely if we succeeded we'd have delivered some new capabilities that really would start to set us apart in the market and we were really excited about that and so was the business but fixing the product management piece of the puzzle and that's really what that was Sophia will be talking later today about the product the connection with product management in this that wasn't the whole solution as I mentioned we still had this entire iceberg of hidden complexity to deal with we could see some of it above the waterline but most of it was hidden and unknown so what do you do in the face of this kind of complexity we dealt with a lot of the technical complexity earlier in the project so it was less worried about that we knew how to persist data we knew how to use our frameworks and those types of things but I needed to figure out how to deal with the bigger concern so as I was reading everything I could get my hands on I was studying software patterns I was this was dotnet development at the time so as a developer I was trying to improve my skills in those areas trying to learn test-driven development behavior driven development a lot of these other approaches that were out there I went to a conference and it like like you are today intended some workshops to try and get my skills up and and all that was useful but the real struggle that I kept coming back to was understanding these core business concepts such as the intricate lifecycle of an extended warranty and how did this claim process work and and trying to come up with names for things that the business would agree on we talked to three different groups of people and get three different ideas of what we should call something in the software how are we going to represent these ideas in our software well it was about this time that my boss actually recommended I read the domain-driven design book I started my programming career actually doing software modeling for geology and geotechnical engineering my very first experience of programming was getting in a small 10 seater aircraft flying out to a mine site like this and spending a week maybe two weeks working with the geologist or the geotechnical engineer trying to understand how they did what they did how did they use the software to model this mine site how did they use it to figure out how to cut the the berms that you can see here and what angle to make them so they would be safe I read books on geotechnical modeling so the idea was to take our software and actually implement some of these geotechnical techniques in our software we code up some experimental ideas send him an updated release get his feedback make improvements and we'd repeat this process until we had something that he really felt he could use on a daily basis and what I really loved about that collaborative kind of process was his mounting enthusiasm as we converged on something that was really useful for him so these were some of the artifacts that we actually brought into the software that are used in geotechnical analysis and what's fascinating to me is I wrote the original version of this software back in 1994 and I took this off the web yesterday is something that's still used in the same product today software can be long-lived sometimes more than we would think the thing that attracted me with domain-driven design was that it seemed to work the same way it was a simple idea clever closely with the experts in your business come up with a shared language understand how they do what they do and work to represent that in the software and then as you learn refactor in refine the the code to more closely match what the business is doing that's the simple idea in theory but I found it really tricky to pull off on a real project especially one with tight deadlines and nervous stakeholders the book provided a set of coding patterns and techniques for doing this and while I didn't understand them all if you've seen this book it's a big book well I didn't understand them all what I did understand we started putting into practice on our project now you can imagine based on that email exchange this caused quite a bit of friction and confusion with our business experts they weren't used to this level of collaboration it went from passive-aggressive email exchanges like you saw to actually wanting to talk with them to understand how these things in the business work not only were they not used to close interaction as I mentioned but they were also quite disillusioned about this project as I said so this had to change if we were going to succeed but but how well we started small we started small we asked for help on some of the key specific concepts that we were working on and one of the key ideas here is to approach from a position of humble curiosity technical people often find that difficult I am speaking for myself and you know we think we know what we think we know everything just ask my wife right and so being able to approach people in the business and say I don't understand this but I need to understand this if the software is going to do what you want it to do can you explain it to me can you give me an example we ask them to tell stories of how extended warranties in the claims work to provide real examples and we listened and took notes and we asked lots and lots of clarifying questions so so here's an example of this imagine I went to one of our business people and I said how does an extended warranty work from a customer perspective and and the answer might go something like this David and Claudia have six children living at home so there are always a lot of dishes to clean and on March 10th after a particularly horrible experience where their current dishwasher just stopped working for good they purchased a new one at the local appliance store they needed a quiet dependable high-capacity dishwasher since the last dishwasher had been such a major headache so they chose a KitchenAid dishwasher because it had a good reputation for high quality and few issues the dishwasher was on sale for 1199 US dollars and included free installation saving them $200 off the regular retail price and a $75 installation fee and it automatically came with a 1-year manufacturer warranty from KitchenAid there's a lot of details in that right so what we would do is we would frantically take notes and then try to understand what are the key details relative to what we're trying to model here what we're trying to do so I say well that sounds good because I understand how they bought this product but what about the extended warranty how does that fit and so the expert in extended warranties will probably say something like well they paid an extra eighty two dollars at the checkout to purchase an extended warranty and that would cover the KitchenAid dishwasher for another three years after the manufacturer's warranty expires and it would cover that dishwasher for any repairs that needed to happen and also they would get a similar replacement dishwasher if their appliance could not be fixed that's a wealth of information packed into a very short story for what that allowed us to do is to start diagramming this thing out so we would walk over to a whiteboard and say okay sounds like we have you call an extended warranty and they say well sometimes we call it a contract it's like okay well we have to make a decision let's put contract for now but maybe it's gonna need to be called extended warranty and their software we're not we're not sure well maybe something else maybe extended warranty is too specific well we'll have to figure that out and then we heard you say some other things so we heard you say that there's a well you said they poured it from their appliance store that sounds like that's a company that we have in a client of ours let's maybe we'll call that a client company for now just tentatively like in the US it would be a company like Best Buy and they said yeah that kind of makes sense what about the dishwasher what is that well that's the product that's covered by the warranty okay well how about we call that the covered product and that's where we put the details about that okay that makes sense well what else well we need the customer information we need their name and address and information like that okay well let's call that customer information well now we have the beginnings of some kind of thing that we could represent in software so we're trying to start to bridge that gap and then we would draw a lot of other diagrams and and come up with other examples to try and figure out how these business concepts work and what are the relationships between them and like I said we'd experiment with different ways different names for things different ways of expressing that now sometimes our business analysts use sticky notes to map out these stories that the business was telling us maybe they would do it in real time as the business people were telling the story or maybe they would do it after the fact to provide a shared visual understanding of how these things worked so what we would do is we have a lively debate about these business concepts and how they relate to each other the idea is we're trying to do iterative collaborative design so we're trying to come up with something that's an initial idea and then go from there so another example of this is how might we handle the repair process when something does go wrong an appliance like that dishwasher you were just talking about and they might say something like well the customer calls our 1-800 number and they speak to a customer service representative we call them see us ours at our call center the CSI asked the customer to provide either the warranty ID or the brand and serial number of the appliance either one of those will allow us to look up the the contract in the system and from there if we find out the covered product failed during the time that the contract is active based on the effective date in the expiration date then we know that this is a valid claim so then the CSR would open a new claim and record all the relevant info they would create a purchase order send it to our Acme appliance repair company that does all our appliance repairs once the repair is completed that company would update the purchase order and send it back to us and we use that to get all the financials to send to accounting so we would do things like map that out on sticky notes Kenny will be talking about this type of technique later today have different ways of doing these kinds of collaborations and being able to see how a process works and we iterate over that we assume that the first idea that we're coming up with it's probably somewhat naive somewhat superficial but we can iterate over that and see if we can improve it over time as we work through it another thing that was critical for us so not only humility in our curiosity and not only iterative in collaborative design working together but short feedback loops and I think this is true whether you're doing domain driven design or any kind of process is having working in small batches and having short feedback loops this is critical so what do I mean by that well what we did is we usually started with understanding and implementing the what you might call the happy path the the simple option first and then quickly pivoted to experimenting with the more valuable hi wrists complex cases it's it's I think of it a little bit like crash testing our ideas right crash testing our model we'd come up with some initial ideas developers we code them up fairly quickly and then we'd walk through them with our warranty and claim experts to see how well they work so at this point in the process we're not necessarily writing production code we're writing experimental code to see if we can understand how the concepts work before we actually commit to writing production code when you don't know yet the right way to implement something trying a few options is a really smart way to figure out the best option right rather than committing to the first idea you have which is probably not going to be the best idea so short feedback loops and I'm talking days here not not weeks and showing unfinished work as part of this as well now related to this is the idea of as we were going through this like I mentioned as they're telling the story what we're trying to do is identify key concepts that we would need to express so in that story I told you okay so we have this KitchenAid dishwasher that's a covered product we have a manufacturer's warranty that's going to be important how we're gonna represent that in the software there's this $1,199 that's the cost of the product but that's a separate cost that's a purchase price but it's the purchase price of the dishwasher it's not the purchase price for the extended warranty right these were all things that we've kind of struggled with because in the code or if people just talked about purchase price we didn't know what they were talking about are you talking about what you paid for the dishwasher you're talking about what you paid for the actual warranty because those are two separate things we had to distinguish between those two things and in the code we had to make sure that we called them different things as well we had other ideas that are expressed here like terms and conditions what is that what does that mean we didn't know and then how do we express this idea of a period three years past the manufacturer's warranty so that we could avoid fraud and the kinds of things like that and then another question that came up in that story was well how do we handle replacements how do we handle that situation where well firstly how do we know how to evaluate if the product couldn't be fixed right who makes that decision and then from there how do we then pivot to handling a replacement we had to figure all that out and express that in the software as well so a lot of complexity in terms of what was going on here when we needed to express that so an example of this was expanding on this previous one was the idea that a contract had a claim I could have multiple claims associated with it and then these claims had one or more repair purchase orders which was what was talked about in the story and then run those repair purchase orders we had line items to represent costs associated with that repairs so maybe the servicer goes and replaces the soap dispenser in the dishwasher so there would be a cost for that soap dispenser and also for the labor associated with that now why am i mentioning all these details this may you know 9:30 in the morning this may seem like a little bit overwhelming I apologize for that but I want you to get a sense of when you are working in a complex domain it's like this when you start you can feel overwhelmed by all these details and what I encourage you is don't feel overwhelmed right if you start to feel that way just remind yourself we just need to get to the next step and so it's modeling these things in stages and what really helped us was this idea not only short feedback loops but tying that to implementation as well so rapid and frequent delivery what I mean by that is once we had a good enough good enough understanding of how a particular concept worked we implemented it in code as quickly as we could we try out options and once we felt like we understood how it should work then we deliver it as production quality code that iteration and it was primarily our rapid and frequent delivery of these key capabilities that led to trust with our stakeholders they trusted us because they could see that we were actually delivering things I think on a lot of projects the the tendency for management or stakeholders to ask for you know to emphasize estimation and and forecasting so much it's because they're not seeing delivery they're not seeing the team actually producing anything and so when you don't have visibility into what's being produced you you find something else that you can manage which is numbers and estimates and things like that I'm not saying those things aren't important in a lot of contexts but rapid and frequent delivery Trump's all of that if you are consistently having conversations with people in the business and or if you're a product owner and you're working with the team and you're consistently seeing work coming out of that team it's a lot easier to make the case for we're moving forward yes we're tracking towards that as with all language learning we made a lot of mistakes in this for example we started out calling them contracts and then later out founded that that name wasn't going to work and we had to change it that was a big change for us but it ultimately ended up being a real improvement to the way the software worked because we had this trust we were able to pull that off and and they could see our steady progress in learning and understanding the domain but more importantly they could see it implemented in software the actual examples we were talking about fast forward a little bit later that year we went live with in production with that client we migrated all their data from the legacy system over to the new platform in record time our stakeholders were really really happy with how the project had gone and we basically turned things around from where they were at the start of the year I I was pretty confident by that point I wasn't going to lose my job as the year progressed we continued to learn new things and had to improve the the code the model we branched out into new capabilities and had to sort of start that process all over again in these new areas but what I found was because we had expressed the model in the code the effort actually continued to accelerate right because we paid attention to design as we were going along it wasn't an afterthought it was baked into the process we were able to accelerate our development throughout the year now in the last 10 years as I've coached and trained teams I've sung I've seen some teams that try to pull this off in a similar context ours with that that culture of collaboration and communication wasn't there and for some reason it just fell flat and they weren't able to pull it off and so some teams may find themselves in that kind of situation some teams may think well I'm going to do all this collaborative stuff but then maybe they pick a part of the problem that is not that complex and so it can seem like overkill and it probably is so you have to be very careful with this kind of approach to say well here's a bunch domain-driven design is presenting a bunch of tools and techniques and you're all coming into this room and you've already got a tool belt of tools and techniques so I'd really encourage you today and over the course of this week and in the reading that you do - look at those tools and techniques and say which ones are for me which ones do I want to try you know maybe this one over here that doesn't make sense to me at the moment so well don't worry about it all right like I said when I started with this project there was a lot I didn't understand and really when I started there was only the the blue book and a book by Jimmy Nielsen though there were only two whereas now there's a multitude of resources there weren't any conferences on domain-driven design you've got a wealth of resources to draw from now some some teams are in a situation where I might characterize it like a feature Factory where the idea is that the business or the product manager product owners are really just saying here's the next feature here's how you do it go alright where it's more of a handoff and that can work really well in some context like where the functionality is really simple that's probably not going to work well for the kinds of things we're talking about today that works well often in this type of thing some some projects are like layer cakes this is from the book shape up I love this diagram where basically if you think about it in terms of the application you've got the front end in the back end and it's kind of like a layer cake where the effort to build and the functionality is fairly straightforward and with a project like this most of the risk and the complexity is in deciding what to build and what do we build next right you still have to do a good job of figuring out how the functionality should work there may still be a lot you have to do from a UX perspective but it's more about how do we store the data and how do we move the data around the intensity of collaboration and experimentation with language that I've described in my story would probably be overkill for a project like this however if you're working on a large project that has a lot of different interacting pieces to it and and this will be talked about later today a lot of different contexts maybe what you could do is if carve out one of those contexts as kind of its own scope and and if it's a relatively simple one like this this might be a better approach is to use some kind of simple approach for that these are the types of projects I'm talking about iceberg projects where the the bulk of the complexity the bulk of the functionality and effort to build is hidden below the surface like I was talking about earlier now some projects are actually you might say upside-down icebergs right where you still have to do a lot of sign but it's more on the front end it's more on the user experience so for example if you're implementing a calendar control for scheduling then there's probably a lot of UI work you have to do and maybe the effort is more on on the front end for for something like that but with most of the projects that I work with most the teams I work with it's it's more like this where the complexity is in what we might say in the domain itself in the business itself and what I mean by that as I described in the story the complexity is in the business concepts it's it's in the logic it's in the rules it's in the way that people interact it may also be in the integration with other systems that are out there and the way they need to interact as well so for the complexity is in the domain itself then driving your design by modeling the domain deeply in the code which is what domain driven design talks about is what I found to be the most successful way most effective way to move forward successfully there's three key ingredients to domain driven design in my story the first one I want to talk about is what's calling the book ubiquitous language don't get hung up on the word ubiquitous it's it's this idea of having a shared common language that you were cultivating and growing so I gave examples of that understanding what a repair purchase order is and how that relates to a claim that was all part of our ubiquitous language and as new terms got introduced into that language we would migrate those we would start trying to use them as much as we could so if I had to do to find this is well let me just talk about this it doesn't mean just writing things down this is an actual sign from a store window near my house writing things down is inherently ambiguous I'm really not sure when I go into this store how much I'm going to pay in the u.s. they have the I don't know if they have them in Europe but they have this notion of a 99-cent store where everything is $0.99 but I'm really not sure if this store is charging that language can be very ambiguous here's another example who would like to sit in a gravy hot tub there's there's a certain ambiguity to language what we're talking about with ubiquitous language is we're talking about a language that is common that is shared between it forms a bridge between the technical jargon of the developers which doesn't go away and the business jargon that is used so it's structured around the domain model it's structured around this set of concepts that the team is coming up with and it's used to by the team members to connect everything they do with the software so what do I mean by that well examples of that would be if we are talking about in the domain the extended warranty domain if we're talking about how we handle a replacement of a dishwasher on a claim then the user story or the epoch or whatever it is needs to talk about that in the language that with we're talking about so if it's called a for example a product replacement then that's what the story should be about is product replacement if on the other hand we're calling it a customer reimbursement the story should be about customer reimbursement right and we should be able to be clear on what those things mean and if we decide to change the language then we need to change the code we need to update the stories when you add a new concept in that should be reflected in your documentation in the code in the stories in the acceptance criteria so the idea with ubiquitous is we're not saying across the entire business we're not saying oh just because we call it a claim on this project everyone in the business needs to call it a claim different parts of the business are going to mean different things by the word claim but in the context of this particular application doing this certain thing it needs to mean a certain thing and that meaning needs to be clear and that is a fundamental idea in domain driven design this notion of having a language that is ubiquitous throughout the code throughout everything the team does in terms of how they talk about that with we're very very good at learning languages generally we're wired to do it from a young age right we don't get taught the language that we end up being native speakers we we are wired to actually learn that language and as we grow older we we tend to diminish in our capability to do that but domain-driven design says no we need to push forward on that and actually get better at that and it's particularly on the technical people on the team to to go out of their comfort zone to do that so the first element is ubiquitous language the second one is modeling by example what I mean by that is as I mentioned earlier is working to talk about concrete specific examples so when we talked about when we another way saying is telling stories and getting good at telling stories so knowing understanding the story of how could David and Claudia bought their extended warranty if everyone understands that story and then they understand purchasing that extended warranty for that KitchenAid dishwasher well that becomes part of kind of the folklore of if you want to call it that of the the background information the background narrative for how things work and that becomes a way of driving the model a lot of teams fall into the trap of becoming very abstract going back to those diagrams those bubble box diagrams I showed you earlier everything works on a whiteboard right but once you start talking about the specifics of well how does a replacement work or how do these particular reimbursements work well now you have to actually anchor it in something real Blaise Pascal back in the 17th century said when we wish to demonstrate a general theorem and you couldn't substitute the word model there if you like we must give the rule as applied to a particular case so if if businessperson said something like well the rule is once we hit the limit of liability in the terms and conditions then we need to perform a replacement what would be the question that we would need to ask okay can you give me an example of a limit of liability what is that I don't even know what that is what are the terms and conditions can you give me an example of that can you tell me a story of how that worked right anchoring it in something real the you know on the business side of things they deal with the specifics all the time whereas people on the technical side of things developers are much more I think you know we tend to be better on the technical side of coming up with abstractions for things but these abstractions need to be anchored in something real and then the third thing here the third element is refining the model is being able to look at what you have and say okay well that's good and the technical people on the team getting good at being able to look at it in the code and say well this doesn't exactly match what we were talking about up until now we were talking about product replacements but now we're talking about customer reimbursements we need to update the code to reflect that I went into one our organization where everyone in the organization talked about missions we're completing missions I thought that's great when I looked at the code the word mission wasn't anywhere to be found it was all campaigns it was talking about campaigns it kind of meant the same thing but not exactly so how do you think it would be joining that as a new developer and coming in and everyone's talking about missions and then you go in the code and in the database and it talks about campaigns that's just one example but it starts to feel a little bit like a rosetta stone right where you've got one group of people talking about this thing and every time they mention it you have to translate it in your mind to something else what what they didn't do and it was the lost opportunity I think at some point in the past they had the opportunity to say okay the business has renamed this I'm guessing this is what happened from campaigns to mission and that's a you know for whatever reason and they had the opportunity to say well let's update the code to reflect that but they didn't and that decision now is so much harder that that work would be so much harder to do it was a lost opportunity to refine the model and improve it why does this matter there's a lot of teams that I see that go very fast and they make a lot of progress very quickly on something new but then over time it starts to get harder and harder and they slow down and the the speed that they were able to crank out functionality at the beginning is not there anymore they become more and more mired in what they were creating and it becomes more and more of a an effort of duct-taping what they've done and writing workarounds for what they've done and they don't get the benefit of investing in design as they go along the idea is to make design part of your development culture a lot of organizations are very good at UX and product management in terms of building the right thing and building it in a way that is a really great experience for the user what DDD brings is more that it's a little bit more hidden is is that design that is happening that informs everything else that the team is doing having a consistent set of concepts that represent that and the goal is as I mentioned in the abstract the goal is not to say well we're doing DDD you know we're doing design that's not the goal that's the means to the end the the end is to deliver the functionality and to meet the needs of the users so what's your journey going to look like I mentioned some things that worked for us one of the things that that I think as I look back was incredibly valuable for us was the idea of prioritizing making over analysis you know what I mean by that that there's a tendency and I feel this sometimes is to want to make things perfect and to not move forward until I have a really good understanding of something and we domain-driven design and the idea is what you should try and do is to take what you understand and make something and then get some feedback on that learn from that and expand on it as you go that's that iterative collaborative aspect of design rather than getting paralyzed with trying to analyze it and get it perfect is learn enough of it to be able to make something get some feedback on it and move forward because you're learning as you're going it's the same way with learning a language you have to practice speaking it to be able to make progress I remember being years ago I was in Bangkok and I was walking around the city with a friend and I done six months of language learning at my university back in Australia in the Thai language and so I was practicing every opportunity I could to speak Thai phrases and she was so polite it was about mid-afternoon where she said you know I just have to say something and I don't want to embarrass you but that word that you think means beautiful when you're talking about the buildings actually means ugly oh well I'm glad you told me now I know and I think that's part of it is a willingness to experiment and make mistakes to prioritize making over analysis experiment in small batches perfection is a trap what we're really talking about here is continuous discovery and to a certain extent working on projects where there's there's a lot of uncertainty because of this complexity a number of years ago a friend of mine who lives on Lake Michigan he's he's actually being involved there's a race every year where they sail Catalina sailboats up the lake over the course of more than 24 hours it's a very grueling race he's an experienced sailor he came to Denver when we went up in the mountains and we was my first time sailing I had no idea what we were doing but he did and what fascinated me was when we turned around when we turned the Catalina the sailboat around and started to head into the wind his whole approach to sailing changed and I'd read about this I understood in principle what it was like but it was very disorienting to think okay well I'm heading towards over there I'm heading to that part of the lake but most of the time I seem to be going in other directions because he's tacking what he's doing is tacking against the wind right he has this prevailing force and he knows where he's going to get to and he keeps that as kind of his his goal but he has to pivot his way there in you know in small ways and so what we did was we focused on and he was teaching me how to do this on getting really good at tapping and once we got really good at changing at changing direction and reading the wind then I was a lot more comfortable as we moved across the lake and of course we got to where we want it to go and I think software development and and domain-driven design really shines when you're in that kind of area of uncertainty where you're attacking against the wind and you're trying to deal with that uncertainty by working in small batches by pivoting on a very frequent basis there's one team I wanted to mention that I've coached for on and off for a number of years now in the US and they seemed their context seems to have all the characteristics that would make doing this impossible they work in a very tightly managed high-stakes compliance environment and and yet they've been able to pull off domain-driven design year after year and seen the advantages from that in terms of delivery they have a great relationship with their client the software has continued to improve and evolve as they've worked on it and that hasn't happened by default they've invested in carving out time to do design and developing close relationships between the team and the product managers to really understand what it is that the business needs and doing all the kinds of things that we were talking about in here and you know month after month week after week year after year they've been able to continue to deliver what's your journey going to be like I just want to close with a couple of thoughts last year after maybe a break of 1020 years I can't even remember now I took up playing electric guitar again I hadn't played guitar for a long time I'm not electric anyway and I'd been exploring a bunch of other hobbies it wasn't like I hated guitar anything I just had other hobbies that I was interested in and what I found is that it took months of practice just to return back to the ability that I had when I stopped playing years ago and it's taken a lot of hard work to get to the point now where I'm playing better than I I remember playing when I stopped what have I learned through that process one thing is consistency is this idea of consistent practice and experimentation and related to that and and you hear about this in there's a lot of talk of deliberate practice it's the idea of learning from your mistakes of reflecting on your mistakes so individually being able to reflect on what I'm doing say where do I need to improve where do I need to maybe go into a smaller circle and focus on this one area that is not working for me so consistent practice and experimentation Trump's theorizing about perfection now in any given day or when I'm practicing guitar it doesn't feel like I'm making progress and maybe it's like that for you on your projects I expect you've experienced something similar in any endeavor where you're trying to improve your skills and as I work on speeding up a particularly core arpeggio I'm making mistakes and it doesn't sound very nice sometimes it's only as I back over the last year that I can see relative progress in my skills as you move forward in your journey with domain-driven design you to learn effectively you have to overcome your fear of making mistakes designers like artists musicians and athletes get better by sharpening their skills or by acquiring new ones they get better by learning to work and by learning from their work learning to work and learning from their work and it's the same in software developments the same in software design DDD is about applying that same mindset towards your business domain in all its apparent complexity and messiness it's about you applying your skills your your tools to cultivate a common language in your team one centered around the domain model expressed in their software and to work as a team in that because it's it's not enough just to practice a particular technique when when I'm learning guitar I really have to do two things if I'm going to take a skill to the next level one is I have to take that isolated thing that I'm learning and put it practice it in the context of something I already know like a song that I already know and in the second thing I have to do to really take it to the next level is to try and incorporate that when I'm playing in a band with other people because then I really start to see how that applies in the broader context of being a musician in a band and it's like that as a designer it's like that in software you not only need to improve your own skills but get better at using those skills in the context of other people so it's not enough just to practice a particular tech in technique in isolation my musical capacity and proficiency have increased and it makes me not only a better musician but also a better band member and it makes the music overall better now what I'd encourage you to do just closing thoughts today is take advantage of this day like I mentioned at the start that I'm really trying to present an appetizer to you of what's coming and whet your appetite for what's coming along so take this for the opportunity that is it excuse me take this as the opportunity that it is to embrace what other people are saying to evaluate it decide what is for you and what might work in your context and be willing to experiment with that experiment with new techniques challenge your assumptions and learn from others in your design journey thank you [Applause]

Channel: Domain-Driven Design Europe

Views: 36,333

Keywords: ddd, dddeu, ddd europe, domain-driven design, software, software architecture, cqrs, event sourcing, modelling, microservices, messaging, software design, design patterns, sociotechnical

Id: p1Nl2k9ZZf0

Length: 54min 58sec (3298 seconds)

Published: Fri Oct 02 2020