Getting modules right with Domain-driven Design by Michael Plöd @ Spring I/O 2022

[Music] foreign [Applause] [Music] I would say let's get started uh thank you all for showing up in such huge numbers I'm impressed isn't it good to be back here in Barcelona as I said yesterday already it's nice um so give me a quick hands who was in the talk of me and Oliver yesterday just raise your hands ah okay quite a few folks for those who weren't there don't worry um I have included the most important messages which I have sent out there in this slide tag as well so uh you won't get lost no worries all will be good um so I'm today I'm or yesterday we talked about modularization some general ideas and I mean we all heard that at University when we learn programming and so on and so forth sometimes we forget about some of those principles fair enough there is so much new stuff pumping into our brains all the time that's a good thing but when we talk about modularity a question that I get very often is how do I identify those boundaries I mean the concepts are cool but how do I actually do it and that's what we want to do today and there is a thing called domain driven design something that is not very new at all old stuff 19 years old crazy isn't it and um but the with a very active community and that Community always produces new ideas how to improve the work and so on and what I try to tell you or explain to you in this talk today is I would say the current status in 2022 and there's a lot of new stuff a lot of open source stuff on GitHub under Creative Commons licenses and so on I'll show you all that stuff in this talk just a few words about myself I'm Michael I work for a company called innocu which is basically a Consulting software delivery company I would consider myself to be a member of the DDD Community I'm also a part of that organization here on GitHub and I like doing conference talks quite a bit so here I am separation of concerns yeah is an idea where we divide a complex systems into a bunch of responsibilities yeah something you probably all heard about those of you who were in The Talk yesterday heard quite a bit about that but I think that's something most of you have already heard and modularity is a specialization of of separation of concerns with a key focus on stuff like information hiding loose coupling High cohesion and all these good old design principles now how do I how do we achieve that one idea for doing that is domain driven design so what we are usually pretty good at especially when we look at separation of concerns it's a separation into technical concerns yeah like layered architecture onion architecture clean architecture hexagonal architecture on a technical horizontal level we are pretty good at that this idea here published 19 years ago in this phenomenal phenomenal book but also hard to read book by Eric Evans is an idea for or contains ideas for modularization on a vertical level on a vertical slicing and there are I would say two key modularization Concepts in domain driven design one is the boundary context the other one is the Aggregate and it also emphasizes that we need to do design domain modeling in an iterative fashion I mean who comes up with a property sign for a complex system that's what DDT does address in the first run is there someone of you who does that ah good for you great congrats so most of us aren't capable of doing that so and in the DDT space we talk about modularity on a first hand in a construct called bounded context I would call that a rather coarse grain module usually when you work with microservice architectures or a specialization of that like stuff like self-contained systems and you usually cut the deployment units along boundary context and please don't mix these Concepts up the boundary context is the domain boundary a microservice is not is a deployment boundary the boundary of a deployment unit something that you deploy independently don't mix this up if you take a look at the idea of modulus what Oliver dropbomb is talking about quite a bit yeah that's basically a big deployment boundary which can contain a bunch of boundary contexts so you never Implement something as a boundary context you model a boundary context a boundary context is basically a boundary around the domain module and in that thing we have a finer grained option for granularity those are the Aggregates and this talk aims to explain to you how to model these things Yeah so basically we start off with boundary context and now the first tint when you leave this call this call I I'm still stuck in the remote but that was a good one now when you leave this talk here oh god um you may want to check out this organization on GitHub it's called dddcrew github.com DDD crew under this organization uh the the active part of the domain room design Community I I would say there are 10 to 20 contributors yeah they are publishing work and everything there is Creative Commons so for instance this visualization so we have published a a description DDD starter modeling process a lot of people ask how do I get started check this out and that's a good idea good resource also contains mirror templates so if you want to do modeling on Miro you can download board backups for templates and stuff like that good stuff there and I want to do this talk along this DDD starter modeling process we won't touch point on anything there so in this talk we will not talk about understanding business models and user needs Pro tip to you as developers please do that try to understand why your organization and how your organization is earning money with the software you write I think it will lead to very good and sensible design decisions good idea we don't have time for that I'd love to talk an hour about that as well um we also won't talk about make or buy decisions strategic thinking and organizational aspects aligning teams that's not what we're going to do but we will Chomp head first yeah into this discovery part now in this talk now would repair brandolini a very smart Kyle from Kai from bologna in Italy uh who is the inventor of a method called event storming which we will check out in this talk once said it's not the expert's knowledge of the domain experts that goes into production it's the mostly implicit assumptions in your brains as developers about a certain domain that goes into production yeah usually we are why do projects fail usually we're pretty good at technical things yeah I mean of course you're all using Springs or we're all good on the tech side yeah perfect but projects very often failed due to a mismatch of assumptions and stuff like that yeah and that's a very small quote and very often we are faced with this situation I told God we all have a shared understanding really let's check this out one method yeah and this the main expert knowledge is totally essential for domain driven design yeah so you need to talk to your business people for finding good vertical module boundaries that's the first thing you should take away yeah and sometimes you can say oh I've got a bunch of requirements Engineers yeah and they do that for me some of you have kids I'm pretty sure and at a at the birthday party for the kids sometimes in Germany we have a game called Silent post so we line up one kid another kid another kid another kid and we whisper a story Into the ear of one of the kids and the kids are supposed to whisper the story further further and further and after the fifth kid everyone loves what utter nonsense is coming out this happens in software as well but no one is laughing there yeah no one could receive that to be funny yeah so what you want to have is that the last kid really chats to the first kid I'm sorry for those who have to work with safe yeah because in safe you have a very big distance sometimes yeah now we need direct collaboration but how do we do that yeah what could possibly go wrong yeah let's check this out and I'm going to be super sarcastic now I don't want to offend any developers here so we have this hotel room here yeah that was one in Switzerland I think how would usual business folks name these things here it has something like window trolley TV chair desk painting now let's imagine we implement this room as a code base or do we very often see in code bases and I'm being really evil now like that yeah I see class names like transparency Factory decorator impulse entertainment provide a Singleton work enablement device uh rollable stuff container or rest provider or something like that yeah and sometimes the language even leaks to the business and the business starts talking that language as well yeah that's a very nice source of a lot of evil out there yeah now what we want to have in DDD is we want to achieve a ubiquitous language a shared language that we speak together which becomes the basis yeah for the domain model in that modules yeah I want to see that language in drawings I want to see it in the documentation and I want to see that language in the code so that I have a class or a module called TV and not entertainment provider Singleton I mean that sounds really smart yeah I mean you you can you can say okay then we need to implement the entertainment provider single and everyone else in the meeting is like oh that's a smart person here seriously yeah now one way to facilitate that is a method called event storming please raise your hand who has done some event storming already next year I want to see more hands here that's a great Workshop so basically you get together a bunch of folks this room would be super cool for an event stomach because we have a very long wall in the back over there yeah a very long one and you need many sticky notes and many pens and stuff like that and what you start with you explore the domain and you think about domain events that can happen yeah so stuff like application corrected in-depth validation done loan granted loan not granted signed contract answered and not um rest template initialized or something like that we want to focus on business events and we want to collect them in a brainstorming fashion after that we sort them in an order so that we can tell a story this is not technical at all everyone can participate in those workshops yeah everyone can participate I think that's a very easy thing yeah and um I've even seen blind persons participating you know just put someone next to them and and then you write the sticky notes and put them on the wall where they see them fit that works that's good yeah and this can ignite discussions and there you will see a bunch of misunderstandings because they are explicitly on the wall good stuff and after that we try to identify so-called pivotal events events that are really important yeah so for instance for searching and his amazing team yeah props to everyone involved here in this conference yeah ticket purchased yeah speaker slot confirmed those are more important events than um session abstract checked out for instance or if you configure a new laptop yeah Ram added hard disk edit processor chosen screen size chosen all good stuff but laptop purchased that's a really important thing I mean you can configure as many of your dream MacBooks as you want as long as you don't buy them it's totally uninteresting for apple and it basically costs some money yeah so you try to identify them and maybe you also see showcase some parallel streams over there yeah and take a look at that at those events what do you think are some pivotal events there so we have an application filled out application submitted application form validated for mandatory Fields pre-scoring green pre-scoring red application rejected any ideas someone application submitted absolutely I would say yeah those here those are good candidates for such pivotal events we'll come back to them they'll be important later on yeah and then we go into a decomposition and especially based on that event storming knowledge that we have gathered gathered there yeah so we can group things along many concerns yeah we can group stuff by shape color text size yeah now what's the wrong thing we don't know we need to find out we need to talk to other peoples and discard the ones that make absolutely no sense yeah so heuristic here there is a very high chance that those pivotal events sit at the boundary of a module yeah so because they are important maybe they leave the boundary of a module yeah think about drawing an image the Mona Lisa for instance in the Louvre everyone knows the Mona Lisa and do you think it was drawn in the first place as a perfect one no someone sketched out the Contours yeah I see a bunch of folks with tattoos in the in the crowd yeah when you go when you do a tattoo yeah you also sketch some lines and so on you make a draft and then you finalize these things yeah and that's what we do here with the pivotal events they are an indicator yeah maybe let's go for that let's check this out stuff like that yeah and then after we've done that we check out the swim Lanes we start thinking hey maybe those are good good candidates for boundaries so we move towards them those are not the perfect boundaries that's a starting point for further discussions for further refinements yeah and then we move to the bounded context by definition the boundary context is the boundary for a domain model expressed in a consistent language tailored around a specific need that definition sounds really smart doesn't it but what does it mean let's depict it I'm pretty sure some of you left the call left the call again the talk yesterday maybe I should start a soon call us to be in my used habitat um now left the talk yesterday and and thought what did he mean with that let's go into that test that one injury every module is a boundary obviously isn't it it should be yeah um and within that boundary we want to be able to learn and master some domain complexity we want to conduct experiments and learn about the domain yeah and we want to deliver high value software within that boundary it's a boundary for a model and now model what does the domain room design World think about a model we don't think about data here we think about Behavior like business rules decisions policies yeah so there's a big difference between the classic object-oriented design which focuses on nouns first and then attributes very often we build a data model with that here we focus on verbs first think about the event storming stuff and then we think about rules Behavior that's expressed in a consistent language a language has terminology definitions and meaning now let me ask you a question to to get an example for that what's a tomato is it a fruit or a vegetable what do you think fruit fruit yeah that's what botanics say yeah Botanical science says tomato is a fruit however in the context of cooking in the context mind that of cooking a tomato is often treated as a vegetable who wants a tomato in a fruit salad no one yeah very strange yeah now think about U.S customs used Customs had import tariffs on vegetables what did people do they imported a lot of tomatoes until the U.S customs said we don't care what science says I mean who cares about science anyways these days yeah we don't care about that we Define the Tomato as a vegetable another context who who knows the time management technique pomodoro some raised hands here yeah in this context the Tomato represents a unit of 25 minutes of uninterrupted work yeah and now let's go back way back to the time where theater pieces were done at markets at marketplaces now in this context what was a tomato there that was flying to the stage negative feedback those are all linguistic contexts and that's what I want to achieve with that and then there's this last thing in this definition purpose I want to bind that language those rules and this specific model to a given purpose now the boundary context is not about building a botanics use Customs cooking time management feedback tomato how do we do that very often under the dry principle don't we yeah so you know that example from yesterday let me quickly recap that those of you haven't been in the talk yesterday we just go quickly over that to give a hook point to the ones who were in The Talk yeah so Sergi did some room planning handle payments sold tickets that involved you as visitors to the conference we can group those concerns don't repeat yourself we know that principle we love it another principle we are very often built a boundary around the model like that yeah the batch printing ticket selling event management customer that can do everything perfect thing absolutely reusable well maybe some parts let's revisit this definition while this is a boundary to a certain degree yeah is it a model hmm we didn't talk about rules yet it's more a data model isn't it has it does it have a consistent language not so much and is it tailored around a specific purpose hell no definitely not yeah this has no purpose at all and the language is totally generic there maybe that's a better idea so tie things to a purpose we use explicit terminology some domain room design folks even call themselves domain linguists because they take care about these details now you can also you have a ton of terminology on your event storming wall it's written down there you just need to read it yeah you can also find misconceptions unsharpness um abbreviations and stuff like that gives you the chance to to ask questions hey what's the difference between an application form a contract proposal and a contract tell me ah okay maybe that's an indicator huh and then yeah when you have identified the first candidates for those founder contacts yeah based on that so let me go back to that slide quickly yeah so for instance this one here scoring rule cluster here maybe that's an indicator of merging things again yeah so okay we have here two different pivot two pivotal events main scoring green red pre-scoring green red it even contains the term scoring maybe we want to define a boundary context for this part and this part that this is the same thing yeah or also those rejections yeah what do we do that is a rejection the same thing as a decision maybe a rejection is actually a decision so those are valuable discussions that we can have there and the next thing that we can do is we can see how Loosely coupled is that stuff now I think we talked this drives you so far a lot towards cohesion yeah but how about the coupling the loose coupling we need to verify that and again here the DDD crew helps you um a guy called Nicktoon who's amazing make sure to follow Nick on Twitter and check out his blog post on medium he publishes a lot of good stuff he brought into place this technique called the main message flow modeling so we have some boundary context candidates and then we can check out what messages need to go between them you can go ahead and say okay let's work in a synchronous way working a lot with queries and commands like get requests post requests put requests and stuff like that you can model event-driven architectures with that and what you can visualize in a way there how the coupling is between those if you have a high degree of communication bandwidth yeah on a coupling side between these things you may have an indicator that you may want to revisit yeah the the boundary context you have identifies and no one wants a death star context that covers to everything that's coupled that's bound to everything because then yeah we we don't have this loose coupling idea here and there with this technique you can visualize coupling and as some of you may already see this is a mirror graphic there is also a mirror template for that so if you want to do that grab the template start a mirror and you're good to go yeah for instance here is also an example so and you can tell stories on that and I like this storytelling idea here so what can we say Okay an applicant yeah over there ah an applicant fills an application in the context application entry and check they submit the application in application entry and check application entry and check fires and event application submitted yeah scoring reacts on that and sooner or later fires an event pre-score in green then we ask for some documents hey please prove what you have added in the other application do you really earn 5000 Euros a month possible prove it yeah and so on so you can walk through that with the domain experts and in parallel you already get a bunch of candidates maybe for restful HTTP apis for events that you want to publish through Kafka or whatever what you want to do yeah you'll really get some indications for API design there as well for the module and this is not technical API design that's an API design which contains domain stuff which exposes capabilities yeah some of you heard me ranting about this get set hell yeah in the Ides yesterday yeah and the same goes with the restful HTTP apis how many apis haven't we seen get put post delete yeah crud apis I always tell my customers it would be more honest if you had the database credentials to the consumers directly yeah you save some latency with the restful HTTP API there yeah if you do that yeah it may also give you an indication for hypermedia usage so when can we offer submitting the application when the application is complete when everything is in place then we can display the submit button can indicate that here as well so but in a way that is not too technical so I've seen a bunch of domain experts who have never written a single line of code who were able to contribute on this level and understand this that's a good thing when you achieve that now let's go further into the definition part away that gives you a checkpoint is then the boundary context design canvas again posted on the DDD crew GitHub site available as various templates PDF HTML my row whatever yeah and this helps you in asking questions about the module so what's the purpose what terminology is in here roughly which rules do we have in it which communication goes into that module what communication goes out of that module this helps you in asking questions and in the end after you've done that you also have a very decent piece of communication of documentation for your module as well yeah so you can fill this out yeah the the domain message slow example which I've shown you before can look like that in a uh in a boundary context canvas and now think about cohesion you can run a next check on your modularity maybe you can dissect certain swim Lanes where you have a strict separation in terms of inbound communication language rules outbound communication if you identify that you may have a good candidate for splitting this context up into two contexts yeah so that you can also play some games on that yeah with questions yeah so we split this up into an application entry context and an application check context and so that's very nice stuff now so far we've done that and we have our bonded context candidates those are candidates for big modules in a modolithic application or a well-designed monolith I don't consider a monolith to be a bad thing per se yeah so if you have a very nice modular monolith those are your candidates there those are also candidates for microservices self-contained systems so core screen modules now let's dig into them and check out the aggregates yeah this is everything from here on yeah is already moving heavily into code now yeah this is a movement where we really get to implement things and everything from here on is inside of a bounded context so finer grain modules within a microservice within a module or a vertical slice of a monolithic monolith or something like that yeah now there are a bunch of patterns in the Tactical design world yeah in the Tactical domain term design world um I won't go into detail over all of them but I want to quickly talk about a bunch of patterns entities value objects and Aggregates because they are the important ones in terms of modularity it is represent Core Business objects with behavior that have a constant identity and their own life cycle and a quick note here your jpa entity is not a domain entity not a DDT entity even if some folks claim that the jpa entity is a data model it represents usually a table in a database some ideas in jpa have been inspired by that but this is about domain Behavior yeah and not about database separation of concerns what we want to model here is domain concerns and not database concerns the same goes for the value object yeah they derived their their identity from their values which they have so let's say I sell this presenter for 100 euros I won't because I need it um I don't care with which hundred euros you pay me that presenter with I just want 100 euros and they also don't have their own life cycle so usually when I say okay it I I I put a new price tag on it 80 Euros I removed the old price tag 100 I put a new one on that value objects are always immutable yeah um they are also supposed to cons contain business logic in here so usually when we model in a boundary context like that we end up with rather big object graphs yeah they tend to be some a little bit error-prone sometimes yeah we have haven't we all seen that yet you changed something at one end of your code base and at a totally different end of the code base boom a bug pops up and you wonder whoa how could that happen maybe propagate it a little bit and those Aggregates help you in grouping those entities and value objects together yeah and there are some special things each aggregate um contains the so-called root entity which is a special thing first of all it's the only allowed entry point and reference point to the aggregate think about loose coupling usually I put my Aggregates into a package on a code level package and there is only one class with a public visibility that's the root entity everything else all other entities all other value objects are packaged private so everything from the outside can only access the root entity we limit coupling points with that yeah information hiding yeah the next thing the root entity is responsible for the life cycle of the complete aggregate so it contains the life cycle and the third thing it should act as a facade like the facade design pattern it should offer inside a boundary context for that context some higher valuable business logic some business capabilities within that boundary context Pro tip never have direct references between your aggregates never they shouldn't know each other so who know who who has read about this principle of corner sense maybe in the refactoring world so yeah Connor sense means Connor sense is a principle in software engineering that says that two components classes or whatever are constant when you need to change both so that the complete system is able to work indicator for a high degree of coupling I don't want my Aggregates to be constant usually I want to be able to change them independently of each other and thereby we say okay don't build direct references between them no now they usually encapsulate the main Concepts by grouping invariants those are business rules that need to run together in a consistent fashion they contain Behavior yeah now you may wonder how do I now go ahead and identify Aggregates what are good candidates for identifying aggregate boundaries there is another type of events I mean you can use eventually for that there is a type called design level event Stone which is a little bit more complex than the one which I've shown you a little bit bigger yeah let me quickly guide you through this so usually you have a starting point now we have this application submitted which was a pivotal event we do something against some external systems and then we have this pre-scoring performed red and green so we're in the scoring bounded context of our big example where we want to score a credit application now the first question you ask the domain experts you want to talk to your domain experts with that what kind of business rules are there where we can determine if pre-scoring was performed red and green tell me the rules what's there and then they start explaining yeah well there's a rule if there's more than 120 points it's green if there is a no-go criteria it's red and so on and you write down all of those rules on yellow cards heuristic when your domain experts laugh at you and tell you hey it's totally impossible to write down all the business rules for that boundary context your boundary context is probably too big yeah it's too core screen maybe you want to split this up yeah but you write down all the rules and then you ask the domain experts hey how would you group those rules are there any ways to group these rules which rules have to run together in a consistent fashion and so on the one hand we can go for points no-go criteria and determination of a scoring result another perspective can be yeah we have the determination of a scoring result but no we we have something that scores the real estate financing something that scores the monthly cash flow the applicants or some credit agency results yeah now what's the right grouping here everything is right every grouping is right Alan holup a very smart guy from the agile Community a guy whom I really appreciate once said the key to an incremental architecture is to build on a framework that can accommodate change that framework is the domain by modeling the domain you can more easily handle changes to the domain now what we want to get is the perspective on the domain from the domain experts now from which perspective do they look at this scoring stuff because from that perspective they will also always give us new feature requests they don't come out of nothing your domain experts and your business folks they're not sitting in their office and talking in their daily stand-up oh how can we torture our developers today no they don't wake up like that yeah no the the new requests the changes that they do they come from a certain perspective and I want to have this perspective in code yeah so let's go for that yeah these groups they are get great our domain experts say that's the grouping that we have from my own experience this is the biggest biggest thing that you can do in terms of maintainable code you can't do as much of clean code practices and whatever as much as you want when this stuff doesn't match the perspective of the domain experts every new feature requests will be a wrestling yeah I've seen that countless times happening and now mind the difference please in classical object oriented analysis and design ooad yeah there is a we start I I still remember when I was at University we had a book that said okay first of all look for nouns those are your classes then look for attributes and after that look for the methods what have we built with that very very often data models and not domain models from that perspective we are very often see classes and modules private attribute private attribute private attribute and then comes the shortcut from the Gates of Hell generate public Getters and set it and don't even get me started with lombok yeah [Music] um yeah this is an endemic domain model then never all the behavior is in some services with really ugly hard to read code yeah and DDD starts from a different perspective we start with behavior first yeah I haven't talked about data at all yet no we we thought about how do we group the rules how do we derive model boundaries from that and so on and what this does basically this grouping of the rules that we have there are aggregate boundaries yeah they are good candidates for Aggregates and then yeah this is then a full picture I won't go into a lot of detail here because I I don't have uh the time for that I could talk three days about that stuff no problem um you can then go ahead and think which commands do we need for those rules what data do those rules need so I derived the data demand from the rules and which events do they publish quick hint to the German speaking folks here there is a talk of Me on YouTube I know there are many Germans at that conference in German the ghost that talks alone one hour about this thing yeah so um check this out that's really good stuff and let me quickly go back to another thing here you remember this um ubiquitous language idea yeah let me go back to one slide yeah to this one here you remember this and it also said then I wanna see that language in the code let me quickly give you a quick hint which just popped out in my head question what can you do code wise when you're at that stage of a design level event stomach do you have any ideas the idea also contains 2DS not DDD but tdd I mean you can start writing unit tests for each of those rules now when you write those unit tests try to reflect the language on these cards in the test methods when you have successfully grouped your rules when you have decided yeah for which grouping you go for which Aggregates you regroup your unit tests and a very nice thing I I sometimes do that with customers and I show The Domain experts the code of the unit tests just plain unit testing no Behavior driven cucumber whatever stuff just the unit test when your domain event experts are able to read the tests for these you're doing a pretty good job in terms of ubiquitous language and do not underestimate the motivating character this has on business folks sometimes business folks are scared of I.T yeah because they hear all our slang kubernetes k-native spring Boots Spring data whatever yeah oh what's that what kind of language do they talk this gets you in a good conversation in a meaningful conversation and when they see oh I went go home to the families and they say hey I read code and I understood that they they feel yeah we hear these digital Natives and so on yeah or a Karma account yeah they feel like they've become 10 more digital and yeah I'm I'm choking a bit here but this is super motivating for many folks and this leads to a better collaboration between developers and business folks and that's what we want to have here and then yeah let me quickly move here those blue cards those commands they are the apis of your Aggregates they are the public methods of the aggregate not get set get set get set blah no this is a meaningful API that we have there which contains business stuff I like this approach however um I don't wanna want this to be a plain uh marketing session here for DDD let me quickly talk about some challenges I'll remove the I'll make that black up doesn't work um so first challenge this whole domain room design thing is tailored at complex stuff when you don't have complexity this is a total Overkill don't do it yeah yeah it's not a silver bullet a good friend of mine yogmada once wrote on Twitter a good developer is like a werewolf afraid of silver bullets and that's true this is not a silver bullet this aims at complex stuff and not trivial stuff which you can Implement with Ruby on Rails or whatever yeah and um I can do that at a spring conference yeah um but I'm a big Ruby on race fan I have to admit yeah and don't boom me and throw me off the stage here yeah um and also all these workshops you will need to exercise them and especially this design level events I mean that's not trivial so maybe you want to add a facilitator to that who stoned that quite a few things who helps you with the method but make sure that you get educated on the method you can do that on our on your own maybe you start off with something super trivial hey let's event Storm the Red um the purchase of a plane ticket or reservation of a seat in a cinema trivial stuff so that you get fluent with that and be prepared to make mistakes domain room design is about continuous learning and continuous learning involves making mistakes and that's also the reason why this DTD starter modeling process has so many iteration errors arrows you need to iterate your first drafts will not be the perfect thing and make sure that your management has the right expectation on that this is an iterative process that you want to do again again again and again you may want to do that in areas that are differentiating for your business and not in totally generic stuff because this is also expensive yeah all right that's it from my side um so who's interested can check out my DDD book I also do DDD trainings and Consulting if you're interested in that um it's always a pleasure to be at Spring IO I think that's my fourth or fifth time at the conference always nice to be in Barcelona so we have some minutes for some questions but I'll also be around until the mid afternoon so you can hook me hit me up at the uh somewhere in the whole room and thanks a lot for your interest thanks for having me thank you

Channel: Spring I/O

Views: 36,970

Keywords:

Id: Q_0XW46IlHY

Length: 47min 4sec (2824 seconds)

Published: Mon Oct 03 2022