A practical introduction to DDD, CQRS & Event Sourcing - Dennis Doomen - KanDDDinsky 2019

[Music] last session before lunch I hope you'll survive I had a lot of fun yesterday evening and maybe a bit too much fun but um it was great DDD cqs event sourcing yeah so all I'm going to try to talk a little bit about how these things are solutions or tools to problems and maybe you don't even have that problem so I'm trying to come up with like an example like a pragmatic approach to try to show you like how these things work together to solve problems but also that you don't necessarily need to use them I've talked a lot about these topics over the last years this is more like a starting point I also like it to be interactive since it's the last session before lunch and everybody started yeah this is me I'm always trying to learn new things I like to be challenged I love that not at work but at least here at the conference that's my twitter handler and I'm always trying to find new stuff about tools architecture people because that's a big part of a job so let's start with oh yeah yeah some stuff I work on not really a modeling exercise this is always very difficult to come up with some some example that really makes sense I don't know if I will be succeeding in that bill at least of all try so I recently got a mortgage and I was trying to figure out what do you need for mortgage and what kind of part what kind of concepts are part of that so given this domain of a mortgage application I think it's not the correct term like you should probably trust us you you apply for mortgage and there's a whole bunch of documents you need to provide it's the page slip it's you're proved who is the original owner of the house maybe you need to show some some pay slips from the last year or you know like yearly stuff some certifications maybe life insurance all the stuff that tells the bank that is all okay that you're going to get that mortgage especially I don't know if it's Germany but the Netherlands prices are huge houses are actually way too expensive these days and there's usually somebody involved called a loan officer not necessarily a girl could also be a guy and they're supposed to help you of course they get paid for that to try to understand if this mortgage is actually going to work for you they also advise you are the different models that you have etc so how would you model this like yeah I mean I can you can talk about concept this is what I used to do I looked at this stuff and I say hey I have a mortgage application let's create something in UML anybody still can read you mouth so ancient art it's a lost art I would say yeah this is what we used to call a class diagram but I have a mortgage application and then I came up with something like a legal document because yeah I'm a developer I need to I need to come up with something that makes sense and the mortgage application has a collection of these legal documents and every legal document has a signature and the signature has unknown time stamp 1 was it signed at that particular document maybe a sequence I don't know if it really important and then a reference to a loan officer makes sense this is what we used to do like 10 years 20 years ago this how I learned that a university well I didn't do university but something in between this explains by the way everything so yeah I felt like this this could actually work would you would mold it like that yeah like yeah but yeah but that's how you start because how would you do differently without actually understanding the domain thoroughly and that's that's that's kind of the point because did I mention any business rules no I didn't mention any business rules so this is the only thing you can you only know these things you have a couple of concepts and you can come up with properties if you're a database developer this is probably the only thing you look at like attributes columns and tables and stuff but I don't know anything here so let's add a business rule all these documents they need to be have means they need to be signed off before the document can before the application can be approved that's a business rule makes sense so the point being is already like you can't really model something if you don't understand the business the rules and what they sometimes call the invariants that apply here so I have a business rule would I use a database like maybe a foreign key constraint so I have something in between and I'm trying to really trying to think as a database developer with tables and foreign key constraints and unique constraints that's the way we used to do that so yeah I have a I have a relationship here between what is called proof and a flag and I use it just a foreign key constraint so you can actually never remove a signature after it has been added to it it's just a database will perform even at is that a good model the things make sense mmm-hmm no no no because we don't do your database anymore I used to work in Oracle environment where all the developers put all the business rules and feel sequel well cool yeah if Cena anybody seem to feel sequel business rules try to create unit test for that you can't yeah you can but they will be brittle and you know and reliable they will fail and you have to apply you know I don't even want to go there hurts really much that's one way of doing it and then you put something like a transaction around it a transaction boundary so to prevent people from concurrently updating this construct and this is a way that a lot of people try to do so yeah like I think it can work which is solve it functionally that's also a way I mean with developers we're trying to solve the problem technically we want the system to be transactional inconsistent you want to wanted want to prevent the system from failing but maybe if you talk to a product owner yeah you can do that you can actually talk with people as a developer and come up with a functional scenario that you did that we allows you to solve the problem without building any code for it in fact if you look at the legal document in the middle there's a sign method but there's no there's nothing to remove it actually even the relationship is broken for some reason see that's what you get the PD UML but you're basically saying like you can no you cannot remove the second year when the signature set you cannot remove it so it will still be valid does it work like that in real life now probably not but yeah that's elites it's an approach you can take and a real life is the situation much more complicated but you can solve a lot of problems when you talk to a product owner you may otherwise she may be solving a problem that doesn't really exist you know or are you going to try to identify the invariance and this is where we enter the world of domain driven design it's the mistake I made in the past I've made a mistake many times is to try to just take the concept create classes you know object-oriented programming at the attributes and I'm done now but you need to understand the invariants so I took a different approach I kind of set like you know the mortgage application is of course is the really the important entity here and the relationship between the legal document and the person that signs it encapsulate that in a separate thing in a separate class it's called an entity layer it's called proof and now there's terms in there like by the way use the ubiquitous language obviously because yeah that's the language of the business I talked with the loan officer I talked with the people that are talking with the loan officer that try to you know get this application to the system but yeah that you end up with these terms this this proof object protects the signatures why because it's part of an aggregate so in DDD I mean aggregate is an overloaded term you've seen the thing on the wall with all the different answers domain-driven design defines aggregate in a really specific way and it's a transactional boundary it's a couple of entities that are protected by the entity that's the entry point which is in this case the aggregate route that's what they call it I mean we can have a full debate about what aggregate means but in this case this is what the terminology does it protects the end you cannot actually update and I use optimistic and currency that's why there's a version on the mortgage application of version property it protects the signatures and it just has a reference to legal document and a reference to a loan officer and this is difficult because you're actually changing your domain the way you model your entity is based on the invariances system has to protect and if you ever read the the book by former non and there's a couple of PDFs that predate that book he also talks about if the system needs to protect the environment like it should never go wrong you should never be able to add more signature so you should never be able to have an order which values more than ten thousand you should never ever happen then the system needs to protected using aggregates that protect that but he also says if it's if the system can allow temporarily to violate that invariant and it may eventually fix it up then don't you don't need to encapsulate in invariance because the problem with with these these aggregates is they're also like a concurrency how you say that they can cross onto content to contention if your aggregate is too big because you want to protect all your other invariants all your business rules and the same object the aggregate is mean if it's updated or touched by lots of different users concurrently you certainly have all these people running into an optimistic and currency problem and there's ways to fix that we'll talk about that in a second or a couple of minutes so you they found foreigner also tell you to make them small because the smaller the aggregate the last chance is that multiple users multiple systems are going to be affecting the same aggregate make sense this is difficult this whole thing is also called the bound contact so in this case we have a couple of things that live in the same world usually these are the things that the loan officer deals with there might be also a system on the side of the mortgage provider that has different concept it also has documents and representations made at MIT these may be different entities with different properties and they protect different invariants they live in a different domain so even though we have if you look at the much bigger scale you may have proved an illegal document a loan officer they may have a different representation in their system or even maybe lives all the same system but they still sit a different subsystem that's what bound of contacts kind of identifying the differences in the domain between different parties and trying to make sure the language within that boundary is consistent I kept it really simple you're not to confuse everybody too much but yeah this is this is your model variant so the next time you're trying to change or trying to convert a requirement about concepts into a domain into an implementational model try to think of the invariance because they change the way you look at this stuff now this is the modeling part how do we build this how do we architect this so a more requirements because everything should be driven by requirements given reading should be fast and collaboration is low in other words there's lots of readers but there's only a couple of people that work on the same thing at the same time because typically a loan officer works alone for a particular client right would you use a credit actor I would use a credit actor yeah it could be I mean it solves the problem you know and I use a relational database and maybe you have a couple of materialized fuse to make it fast they can't work there's no reason why this not this is a problem as I said yeah we want the reads to be fast and there's not a lot of people working on the same thing so the chance is that you're trying to update the same entity from queries pretty low so yeah I know materialized field allows you to build really fast queries especially if you're good database so it's perfectly fine to do that or maybe in no sequel solution with some fast searching who would use this there's no wrong answer that's the point here I'm not saying anything like this is the truth at this the best way that's not wrong this works as well it's a bit more difficult to deploy although you know with containers everything changes so much is much easier to make the complicated deployments but in this case yeah I mean why would I use a relational database because then I have to solve this object relational mismatch and if you have worked with and hibernate and tools like that and the framework it really tries to abstract that mismatch but it still becomes an issue especially if you if you reach the rights are starting to interfere and have a conflict of interest so that could be done or maybe acknowledge the fact that reads and writes are different things what is this put secure s yes again seek us of not again I didn't even explain it but in this model you actually acknowledging the fact that rights are governed or the code and the complexity that defines the structure of your domain is mostly defined by business rules as we talked about but reading is a completely different thing and maybe you want to acknowledge this difference and optimize your read size for reading and optimize your right side for writing so applying a business rules and then it may look like something like this your app sending commands commands commands are like things from your Baker's language apply for a mortgage register or some proof you know stuff like that from the biggest language and then you have maybe I don't know an HTTP API because we're all building single page applications with JavaScript these days a domain data access that writes this information in a document and then we have a query side which in this case uses a combination of an index like the most no sequel solution like rave and a mongrel you have indexes may be elastic search for really complicated searches who would use like something like that seek us is kind of for me the default that I'm using but it's mostly because yeah it's dangerous to say that because yeah you may actually over engineer your system that's a chance on that but I said like my current system I started with that because yeah I like the separation allows me to think about one problem without having to understand the other problem because as soon as the system becomes bigger chances are that these two worlds are going to be conflicting tracks acknowledging the fact that a separate makes sense which you don't have to it's a choice that's really important these are all choices and they come with pros and cons well the right side captures the business processes obviously commands use your business language yeah I typically venture consistent that's one of the problems by the way with no Seco solutions the indexes are always running a little bit behind the documents that's where the speed is coming from but let's add another requirement changes have to be audited we're talking about the mortgage system we're talking about something like people put their lives-- in it I mean if I don't know my wife always makes fun of like she only stays with me because we have a mortgage because there's so much money involved I hope it's not really too overt so you probably want to track really meticulously what is happening who applied what proof was added what proof was removed when was the signature set who sent the signature so given this requirement what kind of system will be built what kind of architecture will we use any offense sourcing no sorry I'm just building something like an extra table here or like a document and all the trill I mean any database support something like that a relational database have changed tracking most know Seco solutions have something like it changes feed that you can subscribe to that's enough if that's the only requirement why would I go further than that I mean that's the whole point of being an architect is trying to balance all these requirements in a function on a non-functional one but also the people that you work with the culture of the company the skill level you know can you maintain all this you try to balance all these different factors and come up with an architecture that works and that's that answer and it doesn't mean you can can't change in the future but yeah this is all I need this was the requirement make sense all right another one many folks works on the same document concurrently so now we have the extra situation of course it had to be fast but you know on the inside we discovered that it's actually pretty common for a lot of people to be involved in this mortgage application I initially didn't know that I thought it's just a loan officer and works alone types of stuff and it's it and in the terminal in the office of the the I don't know a loan broker or something I don't know what you call that but eventually what happened is that over time we discovered it's a lot more people in the other offices all evolved they do checks they verify they scan proves the cross-reference them with external systems and additional signatures so it becomes a much more elaborate process so the requirements change I've already built the system now what now I need to support that so now maybe it's time if an sourcing it should we that's cool of course event sourcing who you can hire people because you as a company use it but it comes with a cost and I'm not going to talk too much about the costs but it's just like the fact butts how what do I look like well the same model I mean seek us and events are two completely orthogonal concepts but they really go well hand-in-hand that is just the fact I mean where the difference is this is what we had but instead of storing the domain into I don't know a noshiko database or relational database we actually store a history of what happened functionally in that domain typically called events and quite often what you see it's more like a convention the events I have the same name as the command so they're written in the business language within the past tense so a mortgage application was approved a mortgage application was so I applied for a mortgage actually all of this is stored in there that's pretty cool because it's a great unit for unit testing I don't know if anybody's practicing TDD but for me a unit is not necessarily class it's one of the mistakes I made in the past but this is really cool because you can actually spin up the system and you can even create because this event store is a really stupid thing is just something in memory you could create tests that execute an HTTP API you know send a command apply for a mortgage and then verify on the other side that the events were emitted from the domain the right ones and nothing else it's one of these vendors that Greg Young always used you can do that it's quite nice I've seen is being used in production systems quite well yeah it a bit bigger but you probably built up some plumbing you know some infrastructure to make those tests readable but it's perfectly fine to do that cool thing is you can also replay those events into a new domain let's say the domain really changes drastically you can take those old events and those events are functional they really try to capture what happened in the past you can replay that to build a video structure or comfortin however to be able to do that you do have to understand and the domain thoroughly you really have to work with a product owner and product owners will love that to understand what happens in a system is not just a developer thing anymore but that's really cool because you come to talk about I mean that's why events tone and also works really well with that because he fans storming tries to capture all these things that happen in the real domain the real business trying to change that into events on the posted events the offense sourcing works quite well with that I'm not saying it's like a one-to-one mapping but quite often it can be a one-to-one mapping however don't make the mistakes as I did like these events should capture business intent they should not be like properties just like title change or something that's way too small may find grant cool thing is you can also look at the state in the past you can actually look at the history and replay your entire system until point in time and then see what the state was a dozen what happened with this mortgage application what was the state on the 1st of January 2019 that's something you can do you don't have to it kind of comes for free nothing comes for free but it's something that's part of that and alt ability definitely comes for free because that's the whole point the events store will contain an entire history of everything that happens to the system make sense one of the dishes van and this comes from an former colleague of mine he says like yeah but if you look at the system like that it's quite often more difficult to understand the entities and their relationships because we defend source I mean if you used to build a crud system you might have seen those classes with properties and if you go through the property to relate a child the the or Ram will dynamically load with and +1 queries which were usually really slow all the related object you could you could really Traverse to the domain with event source and you can't do that anymore every an aggregate the the thing that protects all these little entities is stored as one stream of events and there's no relationships other than maybe a functional relationship and it makes it more a bit difficult if you look in the code and the code is supposed to be documentation to understand what happens in that sis but we have a reach side as well because this event thing yeah it's just a list of events and maybe it's the stored as JSON objects you can't really query on that give me all the signatures of this loan officer related to like for a particular time period what did this person sign for because we found something you know something suspicious that we want to look at so you need the right side sorry the right else the left actually the left side which is the right side as well and what you generally see is that there's something called a projector and as different terminologies for that terms for that but the projectors the thing that takes a couple of events and creates a projection so something that you can also call the view that contains the information in a format that makes sense for that particular query Nate that's a way to do it and what you use for that that could be relational database but it can also thing else and again this is really great for unit testing because you have another boundary and I love boundaries because I can build this whole thing I could even use an in-memory ray from the B database if unit on that space passing a couple of events because the contract between the read side and right side are the events this is what you actually expose so you can pass in a couple of events in your unit test and then do the HTTP query and verify the results correct and don't met you can do that with Owen and HP turneth core I don't know if there's any crud fluent in Java I have not still with her tiny exact but you can actually do that without touching a network stack which is cool because you have a nice boundary it's much bigger than a simple class and all the details about how this is stored in the database that's just an implementation detail and that's also why these projectors should be autonomous as possible so if one page needs information and another page needs other information create two different projections for that that's probably best so you can also rebuild them when you need that if the if you need to if the data changes of the former that you need for a page changes between releases you can rebuild it that's also quite nice of course there's lots of lots of panes that you can run into but I won't be talking about iron you can of course scale this whole thing especially if those if the if the read side becomes asynchronously it eventually catches up with the domain you can scale this out really well because you don't need relationships in your database anymore you just create multiple projection they can even use their own storage mechanisms you really want to do that but does this apply to the entire system should we apply event sourcing as an architecture style on a very high level is it like if I'm building a new system I should make a choice correct versus if I'm sourcing for cqs or not versus were and/or seekers is this something that I should make it that level no it's not a top-level architecture graduate Elling everybody since day one it's an implementation it's more like an architecture style you can also say do any different architectures per boundary yeah I have an example a drafting domain where we draft up policy documents we may have a domain that's more about executing a policy which is which has different characteristics and maybe there's a search domain that is just about displaying information or really being able to make like keyword search on lots large sets of data every part might need a different architecture for instance the drafting domain could work with a simple correct kind of architecture because you don't need any of this complexity there's not a lot of people working in parallel so all these things I showed you earlier all these specific requirements you should evaluate those requirements against the different parts of your system maybe the policy policy the policy execution domain does need all this complexity that we showed you and then we use event sourcing and seek us where as a search domain here is just I don't know elasticsearch or simple Lucene index yeah some indexing based architecture that's perfectly fine and if you is anybody doing micro services or being pushed in that direction as the ultimate solution to all your problems in the future yeah every surface could have a different domain sometimes the domain does not match to a single service that's possible but they all need to have different characteristics and based on those characteristics the non function on the functional requirement choose an architecture style and of course these are three examples don't take them for granted that can be add as one as well and the slides will be on the Internet and maybe you want to communicate between that because that's one of the the mistakes or mistakes something that I see is that the events inside this policy execution domain and the events from event sourcing since they are written or described in the you biggest language in the language of the business it sounds like hey that's a really cool way of integrating all my different domains and that makes sense I've seen a lot of people do that even worse the introduced Kafka or something like that and and everything works for defense but the problem is it's an implementation detail you know this whole thing of encapsulation and one of those principle object-oriented principles also applies here you don't expose the internal details of your system outside your bounded context yeah maybe you use web hooks to expose more coarse-grained defense or something like that that's actually there yeah that's a really nice way of doing it depends a bit on the platform you're working on but that's happening a lot I mean that's why we have GI PC now as a really fast protocol because all these serves need to exchange data but we're not exposing events and using a bus for that that's perfectly fine but publish something coarse-grained something you control not events it might be perfect by the way it's nice solution to project those fine great events inside your domain into more coarse-grained defense that's possible with projection techniques but you do it on purpose you control the schema Aquarion exercise because we have this domain list of proofing documents which state mortgage number and last loan orders that I signed it so we have this remote domain now we modeled it using event sort and we build it using event sourcing so now we can't really query it so how would you query that anybody wants to participate was lunch day well you can do it in different ways you could have two projectors one that projects a list of the mortgages by the proof the proofing documents for the mortgage and one that has a list of projectors a loan officer sorry so you have two of them and they both write through some kind of Christ or you see on the low at the bottom the load the loan officer actually does load officers ok and proving documents and this subscribe to the event stores listen to all the things that happened in a domain and we have two nice lists and you can then join those theives tables that's a way of doing it and it works quite well ok unless at some point you discover that the list of proofing documents become so big compared to the number of loan officers there's only a couple of them you want to somehow independently scale the way you persist this data in your system maybe you want to build them up in an independent manner like those two projections become asynchronous they decide themselves on versions of the code base two when you redeploy the system using blue deployment that there's a new version being deployed that it needs to rebuild those the table and then certainly if you start joining information you're actually joining information that live that kind of represents different points in time so that's kind of a risky thing I've done it myself because it sounded like Reina D especially because if one of one of those tables really big and the complexity in the projector is high people tend to try to reuse it because yeah we don't want to maintain another projector that's virtually the same again as everything in our job it's a it's a trade-off alternatively you could say I'm building a dedicated projector and that's the most purest approach so I'm building something that listens to the events from both the mortgage application and the loan officer know everything that happens there and the signatures and builds up something that completely matches the structure which is the proving document projection and it already contains everything preformed at exactly the way the UI is expecting it if you make it the dominant autonomous you can even decide to use different storage why do you need even a database for that maybe you just do it in memory or maybe you have pre-generated Jason that you can fit in your HTTP API you can all do that if you're a ton of us yeah you have the flexibility to make decisions on that every projector could potentially have its own storage mechanism and that's a completely felt a thing you could even do caching but everything is there and you have the flexibility to make it as fast as possible which comes with cqs the fact that you are decoupling goes to worlds you can optimize for what you want to do it's just like if you write code it's optimized for readability not for readability right yeah there's one issue with with with this approach especially the a because what you would you know if everything is asynchronous it's possible that the data that you query for is still so if you have if you build a system in a UI where you've just approved a document so you prove the mortgage application they've write at the same time your UI will refresh the list it's possible that this approval stage is not visible yet because it's asynchronous that's kind of comes with the territory you don't have to again you can make some of these projects synchronous if it makes sense but making everything synchronous means essentially I click on a button to approve the document and on all my projectors that are synchronous have to run before this click continues and if your system is really big that can take a while you may have like seconds of delay and people are spoiled these days I expect my websites to be really fast so again there's a trade-off to be right there if you make it the synchronous you need to deal with that and there's different tricks to solve that you can simulate this behavior like if the document was approved and the command was sent into the domain and domain accepted that there was no exception then the UI can just assume that it's correct and you know fix up the results from the query side with the updated state you kind of simulate that other things is like you can solve it functionally yeah the textbook example is over buying a book at Amazon by the time you buy it everything seems to be fine you think you paid but it's still possible that you're not getting that book immediately because it was out of stock right at the moment they're not going to do not a person pessimistic look on the venturi system inventory system there's different ways of doing it you can also use etags and it becomes more complicated with load balancers the guys from the event store team they have a lot of experience with that especially John here yeah but these are challenges that you need to solve at some point more examples yeah you have a new version and it requires a change in the projections what do you do what options do you have either the domain side hasn't changed with the read side has changed so you can do a couple of things let's say you have a load balance you can do something like a fully automatic out of place Bluegreen deployment others work version one of the application is available version two is deployed side by side it has done the projections it's a completely independent deployment of the product they may share those two events tours you can do that if you want to but in this case I'm doing like no the new version if you started you actually run it you deploy and run it may be automatically in terraform AWS assure it will return five or threes and since there's a load balancer in between it will try to redirect traffic it will discover that the new environment is not yet ready redirect everything to the old environment then in the meantime you start to copy over all these events which is just the full history of everything ever happened into the other event store and project them into the new structure you can do that per project oh by the way it's not like a full architectural solution when this is done when all this work is done then the new version will tell the old system now you need to become offline which will start to return on five or threes and then generally what happens like you know if this this take it took a couple of hours to copy over the data at the point the old system is offline there might be a bit of a delta in between you copy over the remainder and then the new system becomes available you can completely automate that with the fan sourcing it's pretty well pretty easy to do that our options is like an in-place upgrade you essentially just have a projector and the projector then completely owns the schema and that's why no sequel solutions are so nice you don't have schema and you have documents versions both and it just decommissions versions one of that particular projection and version 2 is just projected from there so essentially you deploy a new version the new product version supports the old schema and the new schema you build up the new schema and after that is done you just make the switchover that's it options choices you have you trade-offs to make but it doesn't for some downtime especially if it takes a while to rebuild unless you really make the code backwards compatible so that old queries go to the old projection bad so as I said like your domain is completely encapsulating the business rules and terminology of your client what if that terminology changes that's quite common right you've chose the wrong term you use something a bit too technical so instead of a customer's customer was created they actually want to call the customers registered or something like that so you have to evolve the event schema let's say you have h to become out API that invokes a command handler that's kind of a convention that you see in those Secours based architectures it loads a customer from the database which means it's loading the history of that particular customer from the event store there's an event customer created event and that one didn't really work well that was a developer that thought yeah you can use create and remember somebody actually saying you should never use words like create and delete and update because these are technical terms crud they don't capture anything from the business I didn't create an address I moved somewhere I bought a house and I physically you know moved there I might make a mistake in my address so I want to fix up the address or correct it but I'm not just updating because updating doesn't see anything so there's a converter that will run on the fly that's one of the ways of doing that and it may you know take that event split it up it might even merge multiple events because over time you also figure out that your granularity was not completely right it didn't completely fake a match it was too technical or it was way too coarse-grained you make you make decisions and that's what this quote changes over time it can run as part of migration so if this becomes really like a performance burden you can always do this as part of this a great process that I just shared and it can change the identity maybe your the the functional key of an object changes over time you use the started met with Active Directory user names and then you moved into like an open ID Connect scenario you want to into Goulet or something else but then at the end the comforter just produces a new event a customer's enrolled in our system which sounds much more businesslike how it and the rest works just exactly as it used to work because the rest of the events are unaffected that's a way of doing it not really that exciting so we have 10 minutes left yeah what else yeah there's a book in the projection happens I mean I produce lots of bugs rebuilding is slow can also happen you cannot build make sure that you build fast autonomous projectiles and I already touch a couple of this like you can you can have projectors that are optimized by using a different storage technique as I mentioned can be HTML can be no sequel database can be a memory I mean if every projector just subscribes to these events store and receives all the events that happened it can just build this stuff on the fly maybe it's perfectly fine when the application starts you can use raw sequel you can use an iPhone 8 whatever works actually using an over a Mounds weird since you've already updated or you've designed your projection to be to be optimized for what you career for but there's lots of advantage because you still have to process events you have to load to record from database update it I've actually seen I have a blog post about that using an oral Ram which has a unit to work maybe you know this concept can be really fast because you reduce the number of updates to the database but it's not one solution that fits everything choose the right technique for the right type of projection and maybe if you forget half of this talk I think the the gist of it used to right tool for the right job and only for that job and if another job needs a different tool use a different tool make sense but you can do cool stuff you can do caching strategies you can say because you know the intricacies of that projector you can do partial partially the work in memory some in a database you have lots of options there and that really gives you the strength of event sourcing instead of all the pain points that people highlight so often stream by stream is also nice one here you can also say like typically projector is kind of a like a projection on the events but if there's a direct correlation between the objects your projection like a mortgage application and the way it's supposed to look in the projection you can also say I'm going to load the entire document from the event store and project that separately instead of doing it event by event that's a nice optimization technique I saw a couple of guys during the project that I work but now that's a nice solution now what if you have like four years of data every building is still slow well you can do stuff like you can archive all the events event store you have like a graph project that attracts all the dependence between the documents there's events there document was created a couple of other events the document was closed in that point the graph to project the nodes that is closed tracks all the dependencies and then if all the documents related in this graph are done you can mark it as an archiving or you can archive the the collect the document do that any event store itself that concept itself is also an action that the system needs to it needs to maintain then you have a projector with active projections and that can want to actually clean up some projection there it's a pretty elaborate solution but it works we used to call this tombstoning and then an archiving projector that actually marks all those all those events in events doors archivable so you're kind of saying like we know this concept we know that if all documents related to each other had a mortgage application with all the relative related proofing documents have been finalized we don't care you start to optimize by marking a part of the event store as archivable which means the next time you need to rebuild a new version you can skip hope a lot of the data that's a way of to solve that you can go further you can even delete all these events not going to show the whole thing I just showed a final picture you're basically saying I'm going to create a snapshot of that document put it in a leucine database and I'm physically deleted history again depends on what the requirements are can you actually delete history from your fans tour because it's from an audit ability back to their practice perspective this may be wrong but it's an option to do what else I think yeah capture the original name of a loan officer that's one example that you can use there will be lots of examples where you want to change the information you captured in the past you want to rich the information there's lots of different solutions and have a picture of that maybe you look up something that runs like you have a projector and it also subscribes to information about loan officer creates a little bit of a lookup so that you can actually look at the loan offices information from the past maybe there's a legal reason and the loan officer was got married and changed its law his or her last name you can actually track that you can also do this on the offense side by converting this but it becomes a bit more complicated and difficult to reason about but it's really cool because everything is a boundary and it's also really well testable it's really cool which brings me to the final slide what if you run into something that I didn't mention and you will then I would say ping me or email me yeah itself or plug it but yeah there's so many scenarios that you can run into it's a really cool architecture style offense sourcing comes with pros and cons I blocked about it that published a little presentation about that we have for the folks from events though here they probably have seen everything already because you know if you build the library and people will actually use your library in ways you never conceived so if you build the library you work with your clients you've seen everything this is the story we have five minutes left for questions if any has questions questions in that case I thank you for your time and hope you enjoy the rest of the conference [Applause] [Music] you [Music]

Channel: KanDDDinsky

Views: 5,994

Keywords: KanDDDinsky, DDD, KDDDconf

Id: r26BuahD8aM

Length: 44min 16sec (2656 seconds)

Published: Wed Dec 18 2019