The DDD Starter Modelling Process - Maxime Sanglan-Charlier - DDD Europe 2022

hello everyone thanks for coming to my talk um thanks also to uh DDD Europe for inviting me of course um I never thought I would be on that stage one day but here I am that's that's pretty cool um yeah so um Eric Evan's book has been released um like almost 20 years ago now and um DDD has continued to gain popularity uh since then and I see uh many more teams that want to get into DDD which is a pretty good thing actually so what do people do when they want to know a bit more about this DDD thing everyone is talking about well that's easy they just opened their favorite search engine and type in the main driven design and that's the kind of result them I have so um we can see uh books of course but also architecture diagrams or uml diagrams and if you see the themes on top there I don't know if you can see them correctly but you can see things like bounded context application layer microservices or even Java so that's a lot of of different things and and it gets even worse when you start reading blog articles blog posts and the the list of strange words keep on growing and you have a bunch of different things here so this can seem a bit confusing maybe and quite intimidating maybe and perhaps discouraging right um one might feel a bit of editism here as well if you need to know all those stuff before getting into DDD well maybe that's the time to start uh studying all this and come back in 10 years or maybe well you can also read books Erica wants one obviously but there are others Scott meets Nicktoon the ones from Von Vernon Scott blashian and the one from vladder conanav which has been released quite recently um but all those books are quite heavy uh and as Thomas just said for example for the torment design book for America events you must read it five times so it requires a lot of time and people actually don't have maybe the necessary time or energy to read them all and um last but not least you need to be able to read in English and I'm looking at you my fellow French speakers uh that's that's not uh that's not that's not quite easy so in short it would be nice if there was a way to get into DDD that was uh maybe the more easy and uh based on this uh observation several initiatives um as as emerged recently in which I have the chance to to help um and the aim of those initiatives is to uh make DDD a bit easier together to get into so the first uh initiative I will talk about is the virtual DD virtual DDD is a platform when that organizes uh regularly free online events um there's conferences talks discussions workshops a lot of different tools and everything is recorded and it's available on the virtualdd.com website so yeah give it a try there's a lot of incredible content okay of course the the main topic is the domain driven design but well all the subject covers are quite broad so it's more about design in general so yeah please go to this website and the other one is the domain driven design crew which is a GitHub organization that has been created by Nicktoon and where you can find a lot of Open Source resources about DDD you will find articles Workshop descriptions pictures templates canvases a lot of different things those those things are pretty easy actionable tool that will let you start easily with a domain driven design so my name is maximson I'm a Belgian consultant facilitator and trainer living in France I'm quite into domain driven design architecture and I'm also an early adopter of even storming you can find me on Twitter on this handle uh and I'm also organizing a conference which is called New crafts in Paris I'm part of the virtual DDD team and a contributor on the DDD crew GitHub repositories and I'm also the founder co-founder of the software Crafters community in North the city where I live in France so um we are going to talk about the DDD starter modeling process which you of course can find on DDD crew GitHub history this will be the topic of my talk today so how this DDD starter modeling process looks like here it is so on this image the first thing you can read it's that it's a guide and not a rigid procedure and this is not the new Silver Bullet neither so all these steps here are optional and their usefulness will depends on the context that could be the complexity or the scope or whatever so DDD recommends a an iterative and continuous design process so do this guide of course all the steps are based on the set of tools and practices that that must be done in a collaborative way and that's very important so quite often this wheel requires on the one hand people that know what to do like domain experts business analysts product owners and on the other hand people who know how to do it like developers Architects but testers qas ux and UI people as well um if you uh look at this picture you can notice that there are maybe several main areas and um the uh correspond to the main the main different phases of this of this process of this guide and um Eduardo Da Silva which is here uh in the conference uh also uh has a talk where he gives those section uh different uh names so here they are the first one is align and understand the single and strategic architecture then we have strategy and organization design and then tactical architecture the link of the talk of Eduardo will be in the references slide and I will upload the slides so we will be able to to see it uh quick aside before we going back to the thick of it um yeah this is all the tools and practices I'm going to talk about are mostly described in this great book which I can't recommend you enough to read visual collaboration tools as its names indicates is a set of visual collaboration tools so joao and and Kenny asked several facilitators to contribute to this book and they actually provided with a description of their practice or Workshop description and tips and tricks on how to use it and get the most out of it yeah so that that's a pretty interesting books with a lot of interesting stuff and it can be found on lean Pub as though you can see the the link and the funds raised actually donated to Association whose goal is to bring more diversity to Tech so so please buy it and and read it that's a gold mine so back to their starter modeling process the first step of this process is understand so determining the architecture of a product or a platform is not done by rushing headlong into the the code first you need an understanding of the business domain and this understanding must be shared by all the stakeholders and this requires a good understanding of the company's business model so well are we trying to understand in this phase we want a 10 000 feed view actually and focus on the business model who are the target users what are they they needs what are the the value propositions of the of the products everyone really needs to be aligned with the business goal every decision that will be May must be aligned with this business uh Vision so that's very very important and I unfortunately I see many many teams many development teams that are not participating at such uh workshops and it's really sad because it gives a lot of meaning to the team teams are aware of the impacts their development will have and um who it will serve so it's it's much more motivating than just developing feature without knowing actually the impact they will have or the for the problems they are trying to solve so here you can use uh tools like the business model canvas it's a very simple tool to use it allows you to visualize to whom and how the company actually generates value and it's uh then much more easier to ensure that the problems you are trying to solve contribute to the success of the company and that the decision will make actually have a positive impact on the business and on the end users you can also use different tools like the product vision board which is kind of like the business model canvas but maybe more focused on one product and of course you can do some impact mappings here when you focus on the main objective and and try to find out the different impacts um yeah so that's uh a lot of different tools that you can use on this phase Second Step discover this one is very very crucial because most of the next step of this process will be based on the result of this this discovery phase so here we will focus on discovering the business domain and we will dig into the domain and then we'll be done once again collaboratively and Visually with domain experts we are not looking for Perfection as at this stage we just want a share the understanding of the domain so you will have the opportunity to to ask anything you want about the domain and everyone should be aligned then on the same level of understanding so it will also be the perfect time to start building a common vocabulary and Thomas already mentioned uh that with the ubiquitous language building a glossary of domain terms and those domain terms will be discovered along along the workshops you'll be doing during this this discovery phase and having common vocabulary will improve uh the quality of the communication between all the stakeholders and having a good communication will increase the changes of success good communication is a success factor so this is this is really uh important to get into this vocabulary and share all this vocabulary and this vocabulary will be of course based on domain terms that domain experts will be will be using mainly so the collaborative aspect here is uh crucial and so we will ensure that the dissemination of information and knowledge will be done through the whole team and that that's the very very important we'll have this opportunity to build a common ground and also has the knowledge is often spread into different heads actually it will be the perfect time to bring back the pieces of the puzzle all together I had this uh Workshop once that was the railway uh French company and um we were doing a workshop and the goal was to maybe try to imagine what would be um the best way to increase the quality of or the accuracy of information displayed to the user in Railway stations so what a program and then so we started with trains actually the the the trains were the main actors and uh they were explaining me that trains were going on sensors uh that were placed on on Railway and the train that was going above the sensor was saying well I'm this trained I'm training number one two three and I'm here so that's great so we have the uh the right information and then we can adapt the information display on the screen about the delays or whatever but there was another kind of train and those trains were saying when they were batting all above the sensor and they were saying like well I'm a train and that's it I'm just passing by and I'm a trainer and I won't give you my number so there was this this whole system here involved where they had this huge calculation of trying to find out what was the chances of this train to be actually and at the end of the process you had one or two choices saying well this must be this strain based on when we know but we're not sure or one not 100 sure so I asked people in the room well can we dig into that part and and no one was knowing so this this important domain so we had like a hole in the uh in the process so uh and even there were a lot of people during this this Workshop but we had that hole in the right in the middle with an important stuff so it's it's really important to have a lot of people available uh and and domain experts from from different areas of the domain so you can put back the pixel the the pieces of the puzzle back together so um it's um it's not really the number of person that is important right here but maybe the quality of the person and bring bring curious people and uh have a diversity of of uh people meaning that people from different backgrounds uh and experience might bring some some New Perspective and and ask different questions like newcomers for example they don't know anything about the domain so they will ask a simple question and that's great actually this reminds me of the story when I was at a client's Place doing a workshop and they were building an accounting tool and one of the domain experts said to me well we are just handling this this type of accounting because there's two type of accounting and we are dealing just with that one so I said well great just let's describe those two kind of accounting so it will uh we will put it in in this glossary of uh domain terms that we'll be using throughout the whole uh cycle life cycle of the product so she gave me the the both the descriptions and then I heard someone in the back saying well I've been hired like five years ago and that's the first time I understand the difference between the two the great that that's uh that sounds funny but it's great actually because we align everyone at the same level of understanding and this person was here uh from five years now and and uh he he won't dare asking that that simple question so having someone that is playing this role of asking the simple question I do like that when I'm playing the status role uh during Workshop because I don't know anything about new domain so I will ask simple question and and it's important to bring those questions to the table as well so everyone will be uh sure to understand every uh single uh stuff so um yeah so what do we use here so my first choice for this face is even storming well you might say he's a bit biased because he said he's an only adapter that's true but I do love this tool it's very very powerful um and it's totally adapted to uh this discovery phase when you want to get into a new a new domain so it has been invented by Alberto brandolini who's there for the pre-conference workshops in the conference as well so feel free to ask him some questions about being storming it comes with three flavors and the big picture even storming flavor is the right one to uh the perfect option for this discovery phase so this is uh quite difficult to read this but this is an example of what can be achieved with even storming in a small amount of time so we spend like I don't know five or six two hour sessions to uh map out the whole landscape of a car renting platform for a a client so you can see there there are mainly orange stickies which are the events and that's why it's called even storming by the way um and uh what isn't even actually it's a it's something that that happened uh that usually the business care about and it reads from left to right and it's on the timeline but you can put other stuff on your even storming and Alberto actually is used to say even storming is my pizza you can put everything on top of it except pineapples and database tables of course so that's the complete quote um yeah so you can see there are other stuff like the the um the fuchsia diamonds there those are the um hot spots and hotspots is a very efficient way to visualize places where you well still have questions maybe um the first thing you will do when you will be doing even storming is to is to model the happy path and about of course this phase the the rush to the goal actually and you can even put the uh the latest sticky stand that the latest event that should happen the one that that uh make your customer happy or uh your where your company is earning money for example and then you can put all the remaining stickies in between that that's a way to do uh even storming so you will rush to goal but uh you will maybe stumble upon places where things might go wrong of course um or edge cases to deal with this is the perfect place but to put some some hot spots as reminders of places where you still need to dig into uh the domain so it's very uh a useful uh thing to to put but you can put uh other things we cannot see that on this picture but when you will read the style maybe you will see that there's a lot of gray boxes above uh the stickies and that's where actually we are putting the definitions of the domain term we stumble upon during the workshop so all the definition of the terms are there including acronism that everyone is using and believe me in France they have this disease where they use acronymism for everything so uh you have a lot of acronyms that are defined here cool thing about the DDD starter modeling process is that it doesn't enforce you to use one single tool per step so you have a lot of options and my number one tool for this discovery phase is even storming as I said but there's a lot of others you can use and if your team is more familiar with domain story thing let's say well please continue to use that tool because it's it's uh it's it's it serves also to to discover a business domain quite efficiently and all those tools can be complementary as well example mapping works pretty great with even storming for example example for example mapping you will focus on the business rules and you will try to find out examples that help you to validate those those rules and those are this is a gold mine for the development team because they can start even to uh write some tests and and do some some code so you can you could jump directly from the discovery phase uh if you have enough information to the code phase remember all the steps are optional so um yeah so by the way there will be a lot of Hands-On uh doing the conference you'll be doing a business model oriented stuff with zofia it will be doing user story mapping with trond Stefan Lena will be here for domain scheduling there's a lot of other two so uh yeah please register to those uh different uh Hands-On during the conference if you hear tomorrow and and Friday to practice those uh pretty efficient tools next step is to decompose phase so we now have a great understanding of the domain and now it will be the time to break down this domain into smaller parts so um why do we want to do that because we want the subdomain to emerge it is important for several reasons because this will reduce the necessary cognitive load to allow us to think about subparts of the domain independently and this gives team more autonomy as they can work independently of on isot isolated parts of the of the domain and this phase actually brings bring together the things that change together so we will add some more cohesion uh to uh to to the the knowledge and and the resulting cut will shape our architecture what we can do here uh as I said the the outcome of the discovery phase so even storming for for instance will help us to identify those those subdomains whether it comes from an even storming or domain style storytelling it doesn't matter you can do that uh with with both Workshop in this example we can see the result of the same Workshop done by two different groups in the same company so this is something I often recommend is to let the the workshop be done by several groups and and see how what are the the outcomes of the the two groups as you can see here there are some some stuff that are similar but are some some differences and that's where it's getting quite interesting because it brings a lot of a lot of interesting testification and then we can maybe converge towards a consensus the exercise here uh we asked to uh to the participants was to highlight the subdomains by circling the events that were going together and they were trying also to give this area a name so to do that we will use this whole set of design heuristics but we will also use all the visual element that comes for free with the even storming like people relevance actors systems so whatever and you will be of course held by the domain experts during this this Workshop also because they will bring some some even more clues to achieve this decomposition um the next phase is the connect phase and the outcome of the previous phase you must consider it as a first version called it a draft so uh we are at the steps of hypothesis uh these are no more than bets of the on the future so it's necessary to validate those subdomains even if it means that we might be wrong at the first place and that's not a problem because we can go back I'm not sure we can see that on this picture but there are gray rows in the background of this picture that that shows that this process is quite iterative and so if you need to go back to a previous uh step to uh dig more into a certain point of parts of the domain then you can do that that that's uh that's very very frequent uh stuff to to do the design is is we we will learn about the the domain along all the steps so everything is iterative so in this phase we will try to to focus on connecting the different subdomains by identifying their interaction and their dependencies and it's very important to validate the relevance of these divisions and see how if it leads if it leads to a Loosely coupled architecture and properly dividing up your domain is very important but you need to look closely uh to the interaction between these different parts actually and you need to limit the coupling because it would bring accidental complexity to your system so what can we use here we can use this pretty useful tool the domain message flow modeling which is a tool that you can find on DDD crew of course and the ID is to take a business use case and see how the subdomains are solicited to make it happen actually so in this example we can see all the subdomains that are are interacted with each other to fulfill the placing an online order scenario so we have this this customer who is placing another through the website website is placing an order on the sales subdomain which will emit an event or the place that is interesting for other stuff and so on and so on you're modding the flow quite easily so um you will gain really some more knowledge about the domain during all the steps uh because you all all the different tools will bring you another perspective a new uh new insights and for um yeah this example actually is the fully detailed view of the domain message for modeling I recommend not to do that first maybe just try to First identify the messages and then maybe try to find out the data and then the message type that that is more suitable so here are examples of uh domain message for meringue I've made with my my clients and one of the strengths of this tool is quite it's really pretty straightforward sorry so if you want to discuss different options you just have to copy paste one of the the option and then change the stuff and start having interesting discussion about the diff differences and the trade-offs of the the two options another tool that has already been mentioned by Thomas during his talk is the context mapping so it's very Visual and here we won't focus on on messages that are exchanged between subdomains but we are looking for dependencies and there's a list of patterns that are available to help you to characterize this these dependencies and describe the way things are coupled and once again as soon as it's visualized it's easy to put spot issues or design issues or whatever you can use those to uh model our your current architecture or Legacy systems because you will visualize uh things that are too much coupled maybe and things where you can improve your your your system that that's pretty pretty cool so um the the list of patterns there the cheat sheet has been done by Michael plot who is doing a talk right now about context mapping on the other room and it's of course available on DDD crew GitHub repository um the next phase uh strategize here we will classify all the subdomains we discovered what does that mean so time and people are located to a product development are often limited we know that so it's therefore very essential to identify the parts of the domain where you need to focus on so where you will have the most impact on the business and on the end users and by performing this analysis you get a better idea of where to focus and obviously would be on your core subdomains because that that's uh where you need to put the focus on do you need to pay attention you need to bring seniority to the teams because of their strategic impact so this phase is really important but um that's not something that teams know sometimes I go to companies where people are spending a lot of time and effort on things that are not core to the business so they are maybe focusing on on stuff that are less important there than their core domains so this phase will obviously avoid you to to fall into that trap and when this exercise is done actually you are able to make decisions on which part of the domain you should develop internally or maybe buy and replace by third-party tools as well because that's not part of your core domain you can use this simple very simple tool it's a Nicktoons core domain chart which is also available where on DDD crew of course as the other other tools mainly so here we will place all of the the subdomains on this graph and we have to access on the horizontal axis we will try to answer the question does this subdomains give me a competitive Advantage for example and on the vertical axis we will gauge the complexity uh of the of the subdomain so this will allow us to have a clear view of what to focus on where to pay particular attention those are the core uh domains of course and on DDD crew actually uh Nick is also explaining how he uses this tool for different purposes as Imagining the solution in the the situation in medium or long term for example when you are in a competitive business you have something that maybe bring you a competitive Advantage but uh this chances are quite high that your competitors will catch up pretty soon with the same thing so you need to think about your next core domain and so you can use this simple tool maybe to to anticipate this situation uh and and try to find out what will be the focus uh next next years or in two years for example one of my clients they wanted to rebuild the the whole platform it was a huge Legacy platform 15 years old platform so we first identified the subdomains and we use the core domain chart to uh to find out where what were the core domains and we found out actually that they were the the actual architecture the old architecture was not really aligned with business objectives anymore and they were focusing on things that were not core to the domain anymore so um we use this tool to show how things needed to uh evolve uh as them so they would be aligned with the business objective so you can see things that are moving from core to supporting code domain and supporting below can go up into the the core domain so it was pretty useful and as soon as of course just you visualize stuff it's easy to uh to discuss in the organizing phase we will focus on teams so during the connect phase we said that it was very very important to identify the dependencies in the interaction between all the subdomains in a technical point of view but it's equally important to do that from a team perspective so um you know sometimes teams are not able to deliver as much work as they would like to because they are dependent on the work of the of all the teams so the teams that must like I don't know synchronize for every single changes with everyone are not pretty efficient so um it's um this phase aims at at spotting those those problems ensure that the teams have a reduced uh connective load also uh it often happens that the single team has to deal with too much different parts of the domain and they it leads to context switching which is a really really bad thing so um also a high work in progress is maybe also potentially a sign that your team has too many responsibilities here you can use Steam topologies and team topology comes to uh two types of shapes so first the type of shapes is the type of team and then you have the type of communication and then you can quickly visualize the team that maybe collaborate too much with others and then we can address the problem easily and you can also use context map again because context map it's a really powerful tool because it's a social technical tune tool because it makes it possible to characterize the T the type of interaction between the teams as well you can just focus on team interaction and without having to think about also the the technical relationship between subdomain so that is very very cool so you can spot maybe the the the high coupling between teams or dependencies between team and and as soon as it's visualized you can try to find out a way out so uh that's an example I've done with one of my clients and what we actually highlighted is the in uncomfortable uh situation of this team in the middle and the product team they were developing the the main product of the company the one that was bringing money to the company and there were Downstream from a lot of different uh other teams meaning that the impacts from the outside all the changes from the outside were impacting them actually so they were not spending their time to develop new feature or do back fixing or whatever no they were just coping with the trying to fix the things that were not working anymore because of the changings of the of the of the outside so uh they knew they knew that the situation was not really really cool so with this map we were able to visualize exactly what were the problems and and and discuss about it with the managers for example so um one once again when whenever something is visualized it's easy to to discuss about it and to spot the issues and try to to solve them right in the Define phase we will gather all the information we collected during the previous phases but we will also gain you insight to help us to validate your our choices so we will clearly identify the roles and the responsibilities of the boundaries and we will ensure that we have validated everything that needs to be validated so at this stage as as at the others it's not uncommon to question certain points um this is why this approach once again is iterative you can go back to a previous steps to revalidate certain things and then come back to that one so at this point where we are going to ask ourselves new questions will we bring us A New Perspective and new insights once again and one of the key point of this phase it's that we will also document the architecture which is uh always good to have some documentation and yeah so we can use this bounded context canvas which is also available on DDD crew of course and as you can see first thing to fill in is the name and the description and believe me it's not as easy as it looks uh just giving a name can bring you some design smell let's say uh if you see names that contains manager or something well you might be uh pay attention and maybe uh try to find out a better website manager that means a lot of different things so you don't have the right intent or purpose uh with this name and that's that goes the same for the description if you see thing well my boundary is doing this and that and that well maybe that's too much responsibility so yeah only giving your boundary a name and a description will give you some interesting uh information so um you you um you can this this is a canvas you can you can change uh however you want so uh I often use a simplified version of it with my clients uh there are a couple of interesting articles uh Kenny uh wrote one where he described how he uh used the scan bus and change the canvas to uh put all the example mapping result Workshop in it and Nick also have a an article saying how to use swim Lanes maybe to add some more readability to this uh to this canvas so on the DDD crew GitHub repositor you can find this filled in example of the bounded contacts on canvas so you can have a look on what it looked like so here we have the advertising campaign Runner uh Bonnet context that is described so this can start advertising campaign apply rules and stuff like that so you can see here that a lot of different things from this canvas comes from other workshops you've done before so strategy clarification it's the core domain chart that will provide you information about what your domain is a core domain supporting sub domain whatever the inbound and outbound communication that's the information you can have from your domain message for modeling Workshop as well here you can see you have a website that can start a campaign post campaign and whatever you have also a mobile app that is able to do some queries so that that's all the stuff you will discover during your domain message for modeling during the connect phase of this guide you can also have a lot of information coming from your even storming or from the discovery phase like the ubiquitous language Thomas already mentioned here you have a way when you can collect all those terms the the domain terms and pay attention that this campaign rule definitely Edition here only applies to this bounded context that means that a word can have different meanings based on the concepts it will be used and I often use the the book example for me what is a book A book is an author a title type of Novel maybe a number of pages that's it almost well but from the point of view of a printer who is uh the the the company that will print all the books what is a book they do not care about all this what they care about is the paper that will be used how many tons of paper they will have to to buy the type of of book how many books do I need to print where do I need to send them or ship them and and make package and stuff like that so and and it's it and it goes also for the other context uh uh like the librarian uh well what is a book for them that's the place on the shelves that's the number of items in stock the number of items I need to book again or the number of items I need to return back that's a lot of different things so the book here the definition of the book will change depending on the context where it will be used and that's very important because this canvas gives you a boundary uh on this meaning of the company rule in this in this example once again when you have everything displayed here it's quite easy to reason about and that's why we imagine a workshop with Nick where we provided a lot of different Bonnet context canvas that were filled up and participants had to spot design issues just at looking at them and and and well they they are discovering a lot of design design issues or questions they might have about about this just looking at it so this is uh this is a very very uh cool to visualize uh everything once again you can also do some C4 diagrams which is a Simon Brown's C4 diagrams it gives you also a lot of interesting information and perspective and it documents also your architecture which is quite cool so on the left side it was with with the with another client where we did that so right in the middle that's the description of the platform and then above you see all the different actors that are interacting with this platform and you you specify all the use cases of those different actors and then just below normally you have enough space to put all your external systems that are interact with this platform but as you can see there there were a lot of external services to deal with and on the Right View that's the container view it's it's as if you were zooming into the platform and looking under the hood what kind of stuff do I need to deploy to make this uh a whole mess work so yeah so that's also a pretty good way to visualize stuff and dependencies at this stage the latest uh stage obviously the circle would not be complete without the code so uh yeah here we will Implement what we defined in the previous phases we will make choices on the Tactical patterns to apply what style of architecture for this particular bonded context what patterns to choose all this all these choices will of course depend on nature and the level or complexity of your bounded context and of course as I said before you need to focus particularly on your core domains this is where the Tactical patterns pay off so maybe if you're working on your core domain you will try to uh maybe use a different style of architecture like hexagonal architecture or onion or whatever that will ensure that your domain is quite protected because it needs to be so to wrap it up the did the starter modeling process is a guide and not a rigid methodology it's iterative and there's a lot of different tools that you can use during all those steps so choose the one your team will be the more comfortable with so all these steps are optional as I said you can jump for example from an even storming an example mapping directly to the code do some code probe and go back and forth collecting some more information or I don't know if you're a startup and you have only one team of course you will not spend time on the organizing phase obviously so um this this this this uh guide this process ends at designing a social technical architecture uh one that cares about Technical and team boundaries that's very uh important and the start of the modeling process is actually the perfect starting point of your DDD uh story uh you will be having perfect EDD mindset to get into more advanced DDD and you will be well prepared to read those famous books that you need five to read five times as Thomas said to understand and intricas so yeah it really remain put you in the right mindset to to get into more advanced stuff after all so uh last but not least you must collaborate to get the most out of all the workshop uh you'll be doing there is uh this process so thank you very much for your attention thank you Maxim thank you thanks

Channel: Domain-Driven Design Europe

Views: 18,628

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

Id: qeir72soorI

Length: 48min 26sec (2906 seconds)

Published: Wed Feb 01 2023