Practical DDD: Bounded Contexts + Events = Microservices

thank you very much Suzanne and koukin for having me here I'm extremely excited Q Khan is like one of my favorite conferences if I can't be here I try to watch the videos I love the architecture tracks and it's it's really awesome for me to be here so thank you so much and I'm just curious who here is her defense of his bus or you sense of his buzz Oh a few hints so for those of you don't know in service bus it's it's a messaging platform a software for dotnet that helps enables event of an architecture and it's built on top of existing queuing technologies like RabbitMQ as your service bus and so on so a little a little bit about like I mean for me even driven architecture and domain driven design are like too like awesome things and when you put those two awesome things together you can get really cool services that are autonomous and and to me the whole deal of trying to have small services is so they could be autonomous so you can you can scale so they can be reliable and so on so for me combining the domain driven design discipline and the event-driven architecture as a technology kind of gives you the best of both worlds so before I started particular software several years ago I worked for this company and the core domain of this company was sending regulatory notices when homeowners defaulted on their mortgage payments and they did this on behalf of banks and mortgage companies so I joined the company about 2010 business was okay but 2010 the software couldn't keep up with the load you can understand like why because in 2010 that's when the real estate meltdown happened and the the core business was like to send all these regulatory notices and and so the software couldn't keep up with the load and that's kind of how I started getting into in architecture to see how to scale and that kind of led me on a journey of entervan architecture so what I wanted to talk about is like my family and I we buy iPhone cases because I am the iPhone killer of the family my my kids presented me a I phones off cell phone case for Christmas it's true I I still have it but if we look at trying to model this page we see a lot of things we see pictures name description prize and so on so if we wanted to model this as in our in our software so we kind of tend to have a model for it we this you know this is years and years of practice and we try to look at all the data that goes together and we come up with this model but the trouble is what is what is product and the definition of what a product is it could depend on who you ask so for a person in sales it's the thing that you know is marketable that that sells so for them the important thing is how can they market it for a person that's in inventory it's a thing whether you have or you don't have and that's their concern and for a team that's in shipping it's the thing that goes in a box that goes from one place to the other so depending on who you know is is on the team so different teams tend to use slightly different language to describe the same thing so language becomes important and when you try to kind of fit all of this in the same model it becomes cumbersome it becomes complex and unwieldy and you have to deal with duplications and contradictions now let's say you're buying a MacBook Air you're you know wondering about the the weight of the laptop so for the sales team it's like it's a it's a big thing and they want to try to market that as the lightest laptop or whatever right Apple is very good when it comes to branding now for the the shipping team it's like how much does this weigh now when you have a model and in this model where you have like one attribute called weight or something right the the team in sales could use that same value and the team that's in shipping could say okay I see there's already a attribute for weight I'm just going to use this but what's going to happen is like you might have some weird use cases where like the value of the weight appears differently because the shipping team did some updates now you're gonna start having like weird behavior on some use cases so your system is like could could act very contradictory and these sort of things are kind of hard to debug so one way to get rid of that contradiction is like having explicit fields like you could call it display weight shipping weight and whatever but now what you ended up doing is you slightly bloated your model and not only that the team the domain team they are not calling this as display weight or you know shipping weight or something to them it's just wait so by introducing these different terms in your code what you've lost the language of the domain so now there's going to be a difference when you try to communicate this concept with your domain experts you're now going to have to owe this shipping weight means it's this etc so a lot of you know translations in your head and so it becomes hard to communicate this as well so therefore unified models are are not the way to go and so domain German design helps helps us to understand this and kind of has this concept called bounded context so who here knows about bounded context a lot of hands awesome so by having by understanding that you don't have to have one model to describe everything by understanding that you're going to have some different spaces so I I tend to think of a bounded context as a safe space so a team or you know has the space and in the space the models that live in that space they can evolve freely and it uses the language of the domain the things in this model the the models in this space are logically consistent and moreover they they tend to carry the language of whatever the domain experts call so you could have you know so the the sales context can have a model for product and that can have weight and that could be completely different from the model in the shipping context which can also have weight and they don't contract with each other or there's no duplication so this allows us to have clarity in your model and also gives you freedom for the team that's working within the the context there's this clarity in the language and as logical consistency in your models but for teams that are working outside of this context they are not dependent on the models or they're not dependent on on on your schema or something to make the change in their models they're they're completely and entirely independent so you can evolve things differently and together so to me like that's the that's a huge advantage of bounded context and how they provide clarity and freedom so the question is how do you then find this bounded context so there's a lot of stuff how do you identify the context and that's the tricky part so so this like several ways and and to me like this this is really that the tricky or the hard part and I use some ways as a guideline so one of the things that I do is I ask myself do I need to have transactional consistency when I try to update you know a couple of fields together for example would I ever need to update the product description and the the availability in the same transaction probably never so if that's the case that's a clear indication that those two things does not belong in that same context so I use that as one heuristic the other so yeah so do we need transactional consistency for updating the two fields if not then we don't have to the other thing is you could split according to the departments or or teams because if the teams have a natural boundaries or like you know rules and business behavior that they are trying to each a comp accomplished then that might be also a good start and you could start there and see how it goes and of course things are going to evolve and in the boundaries are not just like fixed lines they it's going to change based on conversations that you have with domain experts so you might find by having a conversation a concept that is not like well defined in your model or you might find that you know that doesn't quite work well together and so you might move that to a different context so these are some of the things that you're going to learn by having conversations the whole idea is like as you learn new things about your domain about the behavior about the rules you try to take that and then see how you can kind of factor or refactor your your existing models to fit that behavior so in this case you've got three contexts sales inventory and shipping so in in each of these different contexts you can have a model for product which is all different and you can have the same attributes and it doesn't matter and so by having this you're you're using the language of the domain and the domain people can also understand when you refer to your model as a whatever property you can say what should I do when the weight changes and you are using the same term weight as the same same term that they know and understands there's no communication problem so that's why it's important to use to try to use the language of the domain in your code so the other way is you can think about looking at the business processes that that you know that the business has so looking at one of the things that domain driven design like you know really really pushes is look at the behavior the the interesting part of the business is in the behavior if we can capture the behavior of the system in our code then our code is going to be more aligned with the business so if the whole idea is for us to write software that's well aligned to the business if we can design our code in such a way then when they come up with the new requirement we can like go along with those changes to to add more features and so on so so the changes and our models you know we we just can't get there by like having one model but it evolves and as as rules change as business requirements change we just keep learning from the domain and try to refactor our models so in this in this case it's a business process so for example Amazon gives you $70 off if you buy the prime card so obviously there are some business rules that involve like you buying a prime card and it involves like something in the shipping context and you know in the pricing context so now you can see that there's a lot of participants so you can kind of start to ask yourself like if you wanted to have transactional consistency what things need to be together so you can start to to form your models and then you can see where it might fit and so on so splitting the boundaries is a is a talk by itself and my company has given me this link you can access this this is Judy's advanced distributed design course where he talks about finding boundaries this is like one one of the talks of his course that you can have access to so which goes into like larger more detail so just to get a quick check we're at a place now we've clearly identified unified models are not great because having one model to rule them all is a bad idea and we clearly understand that we need to have different contexts and in by having different context models can live in the context and evolve freely and so on but what's the point of having all these contexts the the if we don't communicate between the context so in order to have cohesive behavior for your system to be an actual system these context needs to communicate so to me that's where like even driven architecture comes in because you want to have this communication mechanism in such a way it reduces complexity its loosely coupled so you can you can you can evolve it in you can scale it etc so to me that's where messages and events come in so if we look at messages you can classify them as commands or events so these are the two main category of messages that you can use to communicate between bounded contexts so if you take events events is is a is a message that conveys something of significance has happened in the business and it's used to communicate like the state change from one bounded context to the other so commands on the other hand are did convey intent and their commands can feel that's the huge difference between like if you think about events and commands so events are something that get published so multiple subscribers are going to receive it versus a command is usually sent to one particular service or context or something so typically you want to use events as a communication mechanism between bounded contexts you can use commands as a way to decouple or you know have loosely coupled communication style within the bounded context so so the one thing about commands is that it can fail so have you guys as everyone watched 300 in this room so when when when Xerxes sends his messenger to Sparta to Leonidas and say you shall bend your knee to circuses you know it didn't go so well so if you think about if you think about bounded context they are two separate things and they don't tell each other what to do so you can think about bounded context as like isolated things and they they do communicate but using events so I want to take example of a business process let's take just two just to kind of like walk through how we would do this with domain-driven design and and have this sort of communication using events so the requirement is when an aircraft type has changed the the aircraft company wants to notify the passengers saying like hey your your you have a new booking proposal and the passenger has the rights to either accept it or cancel it so if we were to model it and this is like an example like Norwegian sent me very kindly said like hey sorry we cancelled your flight to Rome bla bla here's your new new flight if you want it then you can take it otherwise you can get your money back so a business process if you look at it it can be triggered by an event from one bounded context to the other so the the thing about here is so you've got the flight planning context saying that hey this aircraft flight has changed so the booking context can now receive that event and then go and act on whatever it needs to do the key word here is when so when the domain experts or the people in the business starts starts to use the language when and then start describing something there's usually event that that follows that you can get out of so the the thing to understand here is we said that messages you know help you design your systems to be loosely coupled so the whole point is we don't want to be coupled however we do have to be careful in how we design these schemas because when you send messages over from one context to the other context you are going to be sharing the schema so it becomes really important what you put in those events and what you put in those messages so you could put a lot of information from one bounded context in that event and now you are definitely coupled via the event so what happens when you there's about this flight planning bounded context changes the schema of the event how is that going to affect this booking context so you have to ask yourself and be very very intentional about the data that is being shared from one bounded context to the other just because we use events and messages doesn't automatically give you like you know Nirvana and happiness we still need to pay attention to our you know what we put in the messages and how we design the schema so the other thing is the business processes there could be multiple messages that takes part in the same process so the booking context receives the aircraft type has changed event but then internally might need to do a lot of things which might involve sending messages we need to rebook this flight and we need to notify this customer and and you know what happens when the customer said no I don't want this go ahead and cancel this booking so there's a lot of events that are going to participate in that same process so when you have a lot of messages that are participating in the same process you might have to have steep involved because based on the state like if the customer cancelled then you don't need to send the customer or rebooking like an email or whatever because they cancelled it so so based on the state you are going to take certain decisions different decisions so it's important how we manage the state and that's where we have this pattern called Saugus and it can come in handy so about the word saga there's a lot of contention about the word saga pattern in like the community whether it really should be called a saga pattern or the process manager pattern I'm going to leave that debate for a different a different talk or but basically the saga pattern allows you allows where like multiple messages can take part in the same in the same business process we can't have a key remember who said it but friends don't let friends do distributed transactions and and we can't have very very long transactions these are long-running processes so it's impossible to do that so the saga patent allows you to when a message comes in so you do you take whatever action you need to within that small scope of that action you finish the action and then you remember some state of what that happened during that part of the process when the next message comes in you can rehydrate the state and see okay this is how you know my business process is at this moment so based on the state I might need to take a different action or send a different message and so on so so the saga pattern is is very useful and the the important part is it allows you to take compensating actions because you can have a very long transaction spanning all these messages you are going to have to take compensating actions when messages may not arrive because in a messaging event-driven world you have to accept that you're not going to have messages arrive so you have to ask yourself what do I need to do how long do I need to wait and so you have all these constraints and so you have to have state so this pattern is useful I can get into the details of it some more because that it's it's it's it's going to be you know a different talk and I think I there's a whole different talk on sagas and how you can use sagas to work with evolving or changing requirements so so we said that ok events and messages are important and we need to come up we need to identify you know what events or messages are involved in this business process so how do we go about that and that's where this this technique called event storming Berto Brandolini came up with it several years ago and it's a fantastic collaborative technique so the way it works is you just put long sheet of paper on the walls literally and then you collaborate with your domain experts this is the thing that makes this work is you have to have the right people in the room and so you bring your domain experts your architects whoever is a key stakeholder off that process off that system you bring that person into the room and then you you start you start you start with putting up events so you talk to them and you as a first step you put like whatever events that you think are part of the process and you put them on the wall and then you have conversations and as you have conversations then you're going to identify the constraints so so your goal here is to try to find out as much information about the domain about the constraints about the pain points and try to model that in in in a visual collaborative way and when I first did this it was it seemed very chaotic at first because like you know you have business people in the room trying to wonder like what am I even doing here like you guys are the programmers and architects like why am I here but then like once they start like you know putting up stuff on the wall you can use this process to to get discovery on an existing system as well and so when I what I saw was like the people like started adding flows and how things work in terms of events and and then the business manager he was like in this scenario we shouldn't be doing like whatever the action that the programmer said the software was doing and the program it was like no no that's how the software behaves and he was like well it shouldn't behave like that well but that's the kind of conversations that you want to have sticky notes are cheap and writing code is is you know is expensive and as an example I worked in a previous place where I worked we try to automate this process to make it easier for this person and there was a lot of manual work and a lot of emails that come and and we had to streamline this process so one developer was assigned and there was a guy in New York who did the UX design and and whatever so it took a month and we came up with the software and then gave it to the lady who's supposed to work with it and she just said this is unusable I can't use this unfortunately nobody had you know taking the time to ask her like you know whether this is usable or you know she would have told us a long time ago and saved us like a whole month of development work so collaboration is is super important and having all the right people in the room when you're making these decisions is important again sticky notes are cheap you can throw them away but writing code in design time like you know it takes a lot of a lot of cost so if we were to take event storming as an example and try to apply to the example that we were trying to do so we would first try to in a wall try to identify like all of the events that are part of this process so aircraft type has changed is an event and we you know we might need to know that the booked flight was changed because we want to we want to try to get a new booking so when that whenever that happens we want to publish an event saying that that thing you know has changed so if customer is not happy and cancels it you want to have an event for that so you try to kind of identify all of the events that happened in this process so now you can mean sometimes it's easy and you can tell like oh okay these events might belong in the flight planning context and these events might belong in the booking context so sometimes it's you can tell but but either way you have all these events on a timeline from left to right and you do this as a first step so once you have your events you then ask yourself okay what triggers this event or when more importantly when this event occurred what actions do we need to take so then we might have commands so so then you start like putting up commands next to your events and so in this case when the aircraft type was changed mine is rebook and so that publishes an event and when that book flight was changed we need to notify the customer and we might have to wait I don't know few days whatever the rule is and then and then publish events so the the thing about the thing about like these commands is because we know the commands can fail and we can ask ourselves what do we need to do if the if we can't rebook the flight in that that question is not something we as architects or programmers can answer that is something that the business knows or the domain expert knows so they are the ones with the constraints but they're not you know we have to ask the right questions and and knowing that these commands can fail will help us ask these constraints questions and try to model that in our code so so we we come up with this now once we have this model writing code is is much simpler you have an event you're gonna have whatever a handler that needs to get you know invoked when that event happens in this case when the aircraft type was changed we need to find all the relevant routes and stuff and and we need to rebook the flight so we send a message to rebook the flight and and you know in the inside the repo King thing we look at the routes and come up with whatever you know rebooking is and then we we publish an advance saying this flight you know this thing was rebooked and and now we can have like the saga thing I talked about where you you're going to have you know multiple messages you know you need to keep track of you know how much time passed and if the booking was cancelled or whether the cancellation period elapsed so for that you have a saga that implements and and does whatever it needs to do so writing code is much simpler once you kind of know and model like these things along with your domain experts but as we all know naming things is hard and it's one of the hard hard problems of computer science so when we name these events we are so accustomed to crud type things like you know we tend to call customer was created customer was updated customer was deleted I mean let's if you just think back for a second who deletes customers like you are deleted like we don't do that so we I mean we might say you know the the customer was like deactivated or or whatever the right term is but we don't delete customers right so and this is where yes naming is hard and it's it's much easier when when somebody comes up with the name and you look at you look at the name and go oh yeah that makes sense and that's a much better name but coming up with names is hard and one thing that I strive to do I used to do before is like you know yes we're using events and we're using the past tense to name these events so we want to say you know PDF document was generated so yes it conforms to how events should be named it's in the past tense it's a thing it's significance important has happened but what is PDF document generated mean to the domain expert that that's just a pure technical term for us that doesn't mean anything to the the business domain expert so it might be that the letter was shipped or certified mail was sent or something that has a very very significant meaning in the domain so you want to try to catch those names and that language in your code so so yes naming is hard and in this is where again the collaboration and the communication that you have with your business people and the domain experts are important so let's go back and take a real look at the requirement the requirement was passenger gets notified with a new booking proposal the world was new booking proposal and yet I had originally called it rebook flight I mean we're not rebooking flight we are just you know dealing with with proposals we're trying to propose a booking so again it wasn't the booked flight was changed it was that rebooking was proposed so you kind of take this knowledge that you learned from your domain experts and go and modify your existing models and that is something that you're going to have to do so these are things that you're going to learn every day and you know and that's okay and you need to take that knowledge and apply it towards your model so that's how your code is going to use the same language that the domain users use and you get all the benefits of domain driven design or of trying to write software that aligns with your business so it doesn't happen like right away like your I think it was George box who said all models are wrong but some are useful so when we first design something it's going to be not perfect it's not going to be correct even sometimes and that's okay that's completely okay we just need to take our knowledge of what we learn and try to apply to our models so we need to have a very healthy obsession with language and this is why because once you start using the language of the domain then you know everybody can understand your code and if you leave and another person comes in and that's fine they can still communicate with the domain experts so the that I used to do was I used to like I used to name my handlers as like whatever the event name was in this in this case aircraft type was changed I would call my event handler aircraft type was change handler well handler is just an implementation detail you don't need that and aircraft type was changed that doesn't tell you anything about what's going on in the handler so take a look at what your code is actually doing when that event has been received and call it the appropriate name so in this case that handler was trying to propose a new rebooking so you can yeah you can have sometimes long class names but it's readable it's it's much more understandable so ditch the handler but use the right domain language in your class names and your handler code everywhere so the same thing with the saga name like it wasn't it wasn't a booking change policy that saga was clearly dealing with just the grace period what should I do if if you know if the customer doesn't cancel within a certain period of time so you give your give your handlers and sagas like proper names so having this sort of like questioning yourself is this right or like in your code reviews and peer reviews that you do you know like have have somebody you know have checked for language and and do these things so the other thing is messages are immutable and when you use some things like resharper it's going to generate like properties with gets and sets if messages are immutable they don't change you can't change an event these are schemas published by one bounded context so the other bounded context that receives it it can't change it so why should we have setters in you know when we try to describe the schema messages so you don't need setters so you can get rid of them also look for some concepts in your domain that are immutable for example like it's a different example but like maybe you're dealing with accounting and that's your domain and in this accounting you can only like you know add stuff you can't like go and update it so if that's the thing in your domain don't let your code go and you know make it updatable like make that domain decision whatever that was immutable where the business domain expert said no you cannot do this take that concept and then make your code in such a way that that you can't change that aspect inside your code so one of the other important things about domain driven design is this whole notion of being aligned with the business so if we if we let's say if we want to modify this requirement and say that we don't want to really send notification to every economy class passenger we only want to do this for platinum or first-class passengers because you know when an aircraft type is changed that's the that's who it matters most because some people like based on the aircraft type might lose like flat business seats and go to angled business seats and they might have paid a lot of money so we want to make sure we keep them happy so you know so we don't want to do this for everybody so say you have a requirement like that now you're in sort of a little dilemma because you have the booking context and it's trying to work with the aircraft type has changed but it needs data from the loyalty context which knows whether the customer is preferred or platinum or you know so the booking context doesn't have that data so how does the booking context go and get those data from loyalty so we in order to fulfill this business requirement we need to make sure we get this data and you know once we get the loyalty status then this booking thing can make a decision on whether you know needs to send notification or so on right the trouble with this is yes you can you can call rest calls or like you can have some communication but what happens here is if whatever reason loyalty context isn't available you are stuck you can't proceed you have resources that are stuck and waiting in the booking context that cannot make decisions unless you have the data so how do you get rid of this dependency because this is the thing that is going to prevent you from being reliable and scalable so temporal coupling is where you have a dependency on time where one service or one component cannot complete its operation until the other party is done with work so in order to get rid of this temporal coupling what you can do is you can use events and you you have the two contexts the loyalty the loyalty context can publish events whenever a customer was like promoted to gold or platinum now booking context can simply receive these events and when it's receiving the events can store it into its own database of like you know this customer is gold or this customer is platinum now when the flight car and the flight planning context is is publishing this aircraft type has changed event then for the proposing rebooking component it can simply look at the data that it has to make that decision so it doesn't have to go back to the loyalty now the advantage with this model is that flight planning and loyalty and booking they can all be scaled differently and they don't have to be up all the time to make these decisions however the question is like what if this customer was promoted to gold event happened and inside the the promotion information we have that customer but maybe you know the customer was like I don't know D promoted or lost the status and in this context you have them as platinum customers so what happens when there's this data stillness and and so we can answer that question but we can ask the domain experts how do we want to handle that case and it might be okay you know for for a day or so when that might be completely acceptable with the business but we as programmers and architects and designers can make that choice however by making this explicit in our design we can ask the right questions and therefore we can we can choose the right answers a lot of the times when we have like race conditions or requirements that look like race conditions it really means that there is something in the domain that we haven't really teased out there there's a policy or requirement and we just haven't had the right answers so we just have to keep digging for for those information and this sort of design makes that very very explicit so in this model deployments sort of become easier so when you have like a version 1.0 and you want to upgrade it to a version 1.1 you don't even have to stop it you can just bring up a new module and kind of see how this works if everything works you can you can you can stop the other other service or other component but this also gives you a nice way where if the business wants to say like okay we want to try out like a new policy so we we want to try this only for platinum customers or or something where the behavior is different you could try it and let business know how things are working if that's how they want to proceed then they can stop the old behavior so you can kind of have two behaviors running at the same time and evaluate and how things go and take decisions so you are giving more flexibility to the business to to do things like this and so of course when you can always stop once the business is ready or you know once you're happy with your deployment you can stay up it in one but we all know that sometimes deployments don't go so well so if what happens if this fails now the good thing with working with events and messages is that like when this message goes to your second version 1.1 and it fails it isn't lost it's it's transferred to those Eric you so what happens is now you can take a look and see why it failed and so this this notion a lot of the queuing systems have this ability to poison messages because you can have like some kind of transient error handling built in where you know for some operations like database deadlocks or some things the exception will tell you hey please retry this operation and in those cases a temporary or a transient retried you a quick retry would work but in some cases like it doesn't matter if you have like you know an old reference exception or something in your code it's not if it doesn't work the fifth time it's not going to work the hundredth time so so the queuing mechanisms have this way so they you're not trying to do your SQL systems so they take that message in and they poison it so that message gets moved to the Eric you so now you can debug and then figure out and in the meanwhile you can stop this bad endpoint and all of the messages will flow to your original endpoint and then you can you can even take the messages that are in this era queue and play it back to the original endpoints so all of your stuff gets gets processed so this this sort of thing gives you reliability and also scalability because now if you have a lot of load and if you want to bring up five instances you can do that so in a system like this monitoring becomes very important when you have broken down your system into small pieces it's not like where you had this big monolith where if something fails everything is going to stop everybody's going to know from the database admin to every one so it's it that was like I suppose one good thing of having a monolith is where like you know you know when things failed immediately but in in in a system like this where you've taken the time to design small parts you can have a really small part failing where everything else is working so messages might be getting piled up in this IQ so if you're not looking you don't want to get a call from a customer and says like hey what happened to this thing or you might have an SLA where you're supposed to fulfill whatever the operation is within within a certain time so monitoring becomes super super important and you can have different you can look out for different metrics like queue length how much time are you taking to process each message and so there's a there's a lot of things that you can look out for that you need to monitor so if if if you you know if you want to take away like a few things from the stock first and foremost I think the communication the collaboration that you have with the domain experts is key because that's where all of the good stuff comes in and that's where like like we we want to build the right thing we just don't want to build any software but we want to build the right thing so bye-bye event storming and having this sort of like collaborative way of talking to people we can ensure that and also recognizing that like our models are not perfect and that's okay we need to just evolve we need to take the understanding from the domain and apply it in some of the information is going to be like a hallway conversation and and that's okay and you you are going to get some information from that you might know you might find out that the event that you called you know was was not a right name and so you take that information and you go refactor so it's all about refactoring with an obsession for domain language again the key here is our our whole idea here is like want to try and model the behavior of the business and that's where all the complexity lies so if by having conversations and we modeled this behavior were in a much better shape and again like lastly to to communicate sorry okay there we go so use events as a way to communicate between bounded context so messaging as a technology gives you a lot of this freedom and autonomy and so if you are writing really small services that are autonomous that can you know scale on its own to me you are in the land of micro services so so that's why I feel like when you combine the discipline of domain driven design and then use a technology like messaging to to to communicate between bounded context you kind of naturally land up in a land of micro services so if you wanted to learn more about DDD does Eric Evans book the blue book and if you start I suggest you start with part four strategic design I think Eric himself mentioned that if you were to rewrite the book I think he would have started with part four so it might be a good idea to start with part four and there are two DDD very very specific conferences once in Denver in September and the other one is in Europe in Amsterdam that one I think there are like even sourcing days beginning ddd or foundation days and so on so so both these conferences are fantastic places to go to learn more about ddd and also there's a ebook that's available for free published by DD new york and it's on lean pub comm slash ddd 15 first 15 years it's been 15 years since Eric wrote the DDD book so so these are all great resources so thank you so much I hope I was able to share some information about why I like DDD an event of an architecture thank you [Applause]

Channel: InfoQ

Views: 24,476

Rating: 4.8687391 out of 5

Keywords: Domain Driven Design, DDD, Microservices, Deployment, Monitoring, Software Architecture, SOA, Enterprise Architecture, Methodologies, Messaging, InfoQ, QCon, QCon New York, Transcripts

Id: Ab5-ebHja3o

Length: 51min 24sec (3084 seconds)

Published: Tue Oct 01 2019