Domain-Driven Frontend with Francesco Strazzullo

so hello everyone and welcome to another virtual ddd where whatever time it is time zone it is for you so today with us uh is marco from uh the organizers and today we're gonna discuss about ddd in the front end and we have francesco with us he will give a 30 minute presentation and afterwards we're going to openly discuss it within zoom so everyone who's watching from youtube please feel free to chat away uh everyone's muted until that time and um well francesco welcome uh maybe a small introduction before you start and then we can go okay um uh this evening i will going to talk about domain-driven front-end and how or if you want how to implement some of the domain-driven design technique in a front-end application and uh okay i can start because i have also some code to show so i'm really really curious about what you think about it uh okay i can share my screen in a moment okay you should see my slides okay perfect so let's have this talk uh called the domain-driven front-end and uh but before starting talking about the domain driven design the front end i need to talk a little bit about myself to explain to you why i'm making this talk um i am francesco sturzullo i'm from italy and my code name is uh strats is my it's the way that everyone is uh calling me from when i was a children when i was a child and currently i'm a partner a developer and flowing flowing it's a remote a full remote company in italy this is a software delivery company and uh you can see my twitter handle uh on the slide and this is the only oh sorry i need to move this stuff okay it's the only social network that i used to talk about code and uh high tea in general i use facebook to talk about italian politics so i don't think that you want to talk with me on facebook okay so let's start i started working in javascript in a front-end application in 2009 and before that i worked for six or seven years as a java developer okay i worked in the java enterprise ecosystem at the time and so i always uh floated between these two works you know in the last 10 years i become a better front-end developer a javascript developer but in the meantime i continue to study back-end technologies and of course i studied the two main ddd books uh the blue one and the red one about how to implement domain driven design well fast forward in 2015 this is a a screen for a famous talk for the front-end ecosystem it is a live react auto reloading with time travel at react europe 2015 by dan avrov then this is the talk that into the asset redux to the front-end world and if you don't know about redux it was a very very cool stuff at the time but it was basic it was a framework based on events and red users and immutable events uh and so on so after a while i started using redux in production but after a while i just thought about okay we are talking about redux but the main concepts are the same of event sourcing of course there are differences okay we don't have a database we don't have a log of events because it's everything on the front end but the main idea it's quite similar that the state of the application can only be changed by an event and the events are immutable object that's drive through the application well fast forward again to present day and today uh microphone tents are a very very hot stuff in the front-end world okay we are using the same pattern of the microservices also to the front-end application creating micro frontends that communicate each other with a various kind of integration and ever driven architecture as you can see i showed to you two different architectural frameworks that are bounded to ddd concepts so i you know discovered that front-end and ddd communities don't talk to each other too much uh there is any talk about ddd in the front-end uh conferences i can assure you because i i made a lot of talk about javascript in conferences and i never listened to a talk about ddd but also if you go to bdd conferences there are not so much talk talk about frontend okay the dddd literature is about back-end development okay so why i'm here i'm here to solve this problem i want to start talking about dtd to frontenders and vice versa okay i made a similar talk to a front-end community and right now i'm doing uh this talk to a ddd community so i'm trying to merge these two words little by little okay uh but this is my point what this talk will be about uh i will try to implement in a very very simple demo project the right part of the chart that you see in this slide the tactical part of ddd i will talk about entities value objects services aggregates and domain events with a very very simple application uh i don't think that everything from that bdd can be translated as is to the front and world because i think that of course the domain it's equally important on the backhand and uh on the front end but the front end is a quite particular ecosystem because sometimes you need to uh work with user inputs it is not so easy to adapt everything from the ddd uh for example we will see um an implementation of an invariant in my code that is quite different from the implementation that you can do in a back-end application so the code is coming uh all the code that i can i will show it's uh available on github you can see the link in the slide github.com flowing is slash ddd frontend but before i start i have a little disclaimer for this talk i use javascript application i decided to not use typescript and i did it for two main reasons the first one is that all this stuff all the stuff that you will see is a basis that were on a true story about a refactoring process that my team and i made on a real world application my application will be in react okay because i i don't want to get mad but um the real application one was made in backbone yes a very very old javascript framework but the concept are still the same but apart from the historical version of my problem i decided to use javascript also for another um for another reason um i want to show to you that is entirely possible to work with domain driven design also without types also in the dynamic language and what i what i mean is that it's quite easy to introduce introduce some ddd techniques in any code base you don't need types or classes or whatever you want you just need some plain old javascript to do that so code time okay let's show the code before showing the code i would like to show the outcome of the application okay it's a very very simple list of employees uh imagine that i am a manager and i can just click here to decide who to promote to i don't know tech leads in my company okay uh the lease is always random we have a random data generator but this is the simple use case that i want to show you okay okay let's start with the basic code so i have a classic react application and my react application use an employee's repository oh sorry an employee's repository to load the data so i just call the list method i wait for the return of the data and then i just put the employees on the on the state this is all uh um react jargon okay it's just a way to make a request at the beginning of the life cycle of the component and then to put the data in the state when the data arrive from the server okay and then i just print my employees on the dom with the app content component okay it's not important for for the talk it's just okay print a list with a ul alive for i don't care when i click on the promote when i click on the heart icon what i do is that i update my local state so on my front end and then i call the employee repository to promote my employee to the server okay so i want to show you my employee repository it's not a real repository it's just uh fake data there is no server involved in any case but what i show to you is that usually front-end developers don't call this kind of uh objects repository they call for example apis they call employees or apis but if you look at the what they do they are actually repositories because a repository i keep notes on the right is just an object with a purpose to store a retrieve entities its form should be independent from the data source and it is what i did here in the in this repository this is just a dummy repository it does not do anything but it's for it's promise based and it's uh independent from the from the data source when i will implement with the real repository with rest api for example i will not change anything about my component and this is the entire point of repository then i want to uh let you think about another stuff when you work with front-end you work with jsons okay usually from a restful api well uh usually if your rest api are well built json are entities because an entity is an object defined primarily by its identity that can change over time and the json is actually an object defined primarily by its identity that can change over time what i mean with this first very very stupid example is that frontenders are using some ddd techniques every day but they don't talk the same language of the backenders it may seem same seem a stupid example but when i in a team after i start to call my objects like the ddd counterpart on the back end people start talking each other uh more frequently so let's go over like i said this is i'm simulating a refactoring process so now i will simulate um a more complicated example okay so as you can see here now the application remain the same but sometimes i get an error i get an error when because when i want to promote someone i need to check the peer review the review received from that particular employee if the reviews that that employee received from their peers it's less than free oh sorry less than four then i just stop the the execution then if i have more than three reviews i calculate the average and if my average is less than seven i cannot promote the employee uh okay this is simple and another simple example but imagine that you have a very very complex application full of this kind of boundaries and every boundary is written in the component itself this stuff it's completely untestable and it's not related to the ui at all it's uh it's a domain problem the funny stuff is that on the front on the back end application usually this stuff is well written outside controllers uh if you work with spring outside the rest controller but it's put in the right place okay or at least uh not in the controller itself but on the front end usually this kind of controls are made directly in the ui so as a team we started to take all this problem for our client and the first thing that we did was to add a service so i removed as you can see the business logic from the from the ui from the app and i put everything in an object called employee service the employee service uh i just moved the code from the code from the application to the service he just do the exact same thing okay the list method is just a wrap around employees repository and the promote method just called the review repository to get the reviews and that make the same exactly controls and everything is correct it invokes the employee repository there is an anti-pattern here about repository if you if you see the promote method needs to know obviously about the employees but also about the set employee method from react this is a first step okay and we added a similar problem in backbone this their their service needed to know about a bit stuff about the ui because it's the first implementation okay but if you're looking at this code from an ipoint and an eye level point of view you can see this is actually a service like a ddd where a service is an object that orchestrates a step required to fulfill the comments imposed by the client uh in standard ddd uh there are three different kind of system services domain application infrastructure however i find that most of the time this classification loses some of it in its importance in the front-end application okay it's uh it's blurry in a front-end where the application and the infrastructure comes together okay uh it's hard to separate in my opinion application from architecture infrastructure sorry so we have a first step okay we created a service it's not perfect it's not a perfect solution but still and now i can test my code in an isolated environment okay i just needed to mock the employee repository uh notice that uh my employee service actually depends directly on the employee repository i voluntarily did not implement a dependency injection mechanism to make the code more readable for this case okay i know that is a bad smell but in the uh in a real world application i will create factories to inject dependency inside okay so i can mock easily uh employees repository when i test employee service but like i said it was just the first step our first step was to move everything up from the ui and to start talking about services that uses a repository to make operations well the next step is to introduce the aggregates okay let's start from the app.js and as you can see this time i will i separate i completely separated the service from react set employees because i just depend on proper mode sorry i just depend on to promote parameter okay then i have the result and the mag assault has a type attribute that can give me the type of error that i received from my service for example if my result type is not enough reviews then i just print a window alert i know it's likely to use windows it's just for the sake of the example okay be kind if my result type is ranking too low then i print another window alert otherwise i extract the employee from the result and i do the uh react magic i just write a new state from my application but the state comes from my service the service use uh an employee aggregate factory to create uh an aggregate and to promote them then if the result type is okay there are no errors then i sync my state with the server with a repository so let's take a look at the aggregate the aggregate contains a bit of javascript jargon because i i need to make the object immutable in order to use it as a real aggregate okay the problem with javascript is that if you create a simple object the object is by default immutable okay what i want to do with the promote method that i will show in a moment is that anybody can change the promote attribute apart from the aggregate itself okay so i need to create a little uh freeze cloning objects and something like that it may seems a little harder to read for non-javascript developer but after a while it makes sense so let's take a look at the promote method of the aggregate i just put the same code as before inside the aggregate but this time i returned an object and not just throwing an error this is what i talked about you'll be about before this is what i call is called usually an invariant okay in an aggregate a rule that should be never be broken but while probably in java i will use you know tornuero in a front-end application i will i will suggest to not use an error because if you throw an error it's very very dire to catch to understand what happens on the front end because you want to gracefully show the error to the user usually uh you know on a mac end application it's uh it could be simpler because i throw an error and i convert that error in a bad request uh response on the front end it could be a little trickier to manage error so if my invariants are passed then i create a copy of my aggregate setting the promoted to true so i change the state of my aggregate and then i return it so in this way i completely isolated my domain in a regregate and i can test the promote uh method in isolation well it's uh it's not enough because as part of this uh um [Music] refactoring process also the back end has made some uh you know uh ddd implementation and on the back end we were using uh an even driven architecture okay so we said okay why don't we create a specular event river architecture on the front end so we can have homomorphic events on the front end and on the back end so the last step is to add an event bus to the mix okay the only difference between this example and the first and the previous one is that now i have an event bus using the inside my my service and then i pass the and then i create events in the aggregate i release these events and for each events i just publish on the island bus the island bus it's quite simple okay i have a map of event types i have a list of subscribers i have just a simple subscribe uh method and i have a publish method that invoke all the subscribers right now i just have one subscriber that just print a console log but in a in the real application we use the subscriber to connect different part of the front-end application and also to send some of these events uh as i remember correctly was the events marked with online it was an online property in the events send these events to the back end with a socket the back end get the data from the socket updated state and then ascend an event to the client and the client updated states the the aggregate now just take also uh an events you create an events array and when i promote this uh employee i just push an event inside my array when i release the events i clone the events i clear up my events and return the clone of the events outside everything is immutable from the outside and that's it uh i you can see the test of my aggregates so uh i don't want to read about it because it's okay it's what you just see in the code but what i want to show you this it's completely testable outside of react but also outside of the browser this is very very important because i can use the same exactly aggregate also on a node environment i quickly i could take an a ddd object from a dd object from node.js for example and putting that on the browser or vice versa i can take my employee aggregate that came from a browser application and put it on an old js application it will work uh in any case in the same way so okay my demo it's concluded so i will just complete my talk now so why should you care about implementing ddd in the front end or to know that it's possible to do to do that well first thing first ddd helps team work together using the same language we know the importance of ubiquitous language in a team okay to talk about to talk using the same words and vocabulary of the domain experts but uh if you work with the same uh using ddd also on the front end your backend team and your front-end team can talk together using the same language about repository entities value objects and aggregates on the other hand front-end application are becoming more and more complex by the day and we all know that uh ddd help teams to tackle complexity in general so i think that it's time for frontenders to um start using dbd techniques but i also think that sometimes backhanders that are expert in ddd should start to introduce to help their team to introduce these topics in the front-end work because in the end simplicity and i think that my code it's quite simple in a way if you know javascript simplicity is the ultimate sophistication it's not so easy to create a simple architecture and ddd can help you to achieve that okay uh this is a first for me so if you're interested in the domain driven design from the front end i am preparing with vascoperta a new workshop about domain driven frontend it's in a waiting list so i have not a date i will not have a so much content i'm creating it so if you're interested just add to the waiting list and cocktail me we can talk about the contents of the workshop if you want uh i'm also writing a book with a is uh i'm it's the first book published by alaska perth as an editor and uh the book is called decision making for software developer teams uh it is a book where i'm trying to write how to help developer teams to make mindful decisions about frameworks languages or architectures i prepared a special discount code for virtual ddd it's just the link in the slide i can send in as a comment in the youtube or here in the chat if you want and thank you my talk is finished in half an hour well i'm perfectly on time yeah thank you very much francesco yes thanks everyone's allowed to mute themselves now so let's open the dialogue right so marco i think you want to start and then feel free everyone to join in and everyone from youtube please feel free to ask questions yeah so uh yeah i'd like to take it away with the first observation which is something very painful i feel and that's the assumption that front end and domain are different things so uh somehow there's the assumption that um the domain is part of the back-end team or the back-end software and um this is something i've seen all over the place right you go to any kind of conference or you you go to any company and it's always the back-end developers who think about edd and in front-end it's very rare sometimes there are approaches but there's usually a cultural rift in between front-end design because it has something to do with design and user experience and and the domain rules itself when there really shouldn't be because it's all the domain the domain is not localized in front or back end right the domain is something that exists outside of the solution we provide and then we build a solution so however we separate our bounded contexts um that's that's all part of a solution design and of course the domain is also in the front end because if there is behavior if there's language in the front end um that is not separate from the domain and neither should the solution be so uh now open question to everybody does anybody have experience or experimented with um having the front end or behavior in the front end being designed as a bounded context or integrating it into other bonded contexts and making a front-end part of another bonded context what's your approach there or your take on it i have this discussion with kenny for years not sure yet um yeah what's francesco's take on the time uh my takes on taking this problem uh i think that micro front ends are born to solve this problem uh to see uh the back end and the front end as an unit for solving one bounded context i have to say uh that today 2021 yes okay it's right here the 2021 it's not so easy to build uh a micro front-end application there are there is not so much literature about that so it's more it's i think i find it a little experimental yet um but when for example there is a book that is uh out in the winter about micro frontends from luca medzalier and uh i think that in a couple of years we will have a lot of more tools and use cases about microphone tense and then you can solve this problem telling that okay i have a separate volume context in the in the back end i have a specular application on the front um interesting yeah so using micro front-ends basically as a solution as an architectural solution uh to getting the front-end design into the bounded context of a specific area without separating front and back end yeah that i like that um yeah i've experimented with two or three different things over the years and um i figured that depending on there's there's one it depends right we we chatted about this in the live chat on the side but there's one big it depends here and that is if the user journey is very similar to the domain behavior then the the uis or the front ends probably should be part of the bar of the respective bonus context right if you take something like a trivial thing like nothing is trivial in domain driven design but if you take a simpler domain like cinema reservations or so and you have you want to reserve reserve a seat or you want to pay your ticket and those are different bonded contexts right um having the respective user interfaces of that respective part just be part of the bonded context so that one team can build a cohesive model for for the business logic that has to be um working with multiple users at the same time and also providing with user experience for the singular user um that's that makes sense on the other hand if your user journey is very different if you're only touching the back and south of the domain slightly now i'm making the same mistake if you're only touching the domain slightly but your user experience is very different that's for example if you if you if you do shift planning a domain i've been working in for many years and if you are if you are planning that tomorrow you do the early shift and the day after the late shift there's immensely big domains behind that with laws written and with with optimizations for different stakeholders that the user does not care about at all but still there's a touching there you need to send a command in and something has to be evaluated so in those cases the user journey would be its own um its own bounded context right and then it has nothing to do with front end or back end you can build the whole application inside a front end or a web server or you can build it with 1000 micro services separating between micro front ends and micro backends and whatever you want that's an architecture decision that doesn't really matter um exactly uh i have a i have a point of this there is also another pattern that is used in the front end this is quite the opposite of microphone it's called back end for front-end i think that is using twitter if i remember correctly and in your example what you what you do is that okay your particular use case it's uh uh very tells a very different story from the your bounded context okay because it's not a business uh rule it's a user journey rule okay it's a it could be quite different okay it's still a business rule but yeah yeah okay but you know it's a different one from a different country a different one context okay so what you can do there is to create a specific uh backend for that specific front-end and that specific frontal use all your domain as a you know as a port to your domain and then you create a new domain object uh for your front end okay so it's it's another it's another way of thinking okay i create small applications um uh separated yeah but separated uh really separated one application could be a mobile app one application could be a desktop browser they're really separate not not in the microservices way that is you can see still them as one they're completely separate and then you have a backhand that talks the same domain language of your front end because i have different bounded context this is cool when you have very very um specific and complex interaction with the user yes yes i totally agree uh another solution for the same problem could be graphql for example because it lets you to manipulate objects on the front-end side directly making queries and these queries can come from uh different bounded contexts you can expose all your domain in a graphql endpoint they came from all over the world and then you can let the front end to manipulate these data as they want yeah so here's uh here's the the tricky thing that i think this is discussion where christina is also heading so i'm i'm doing it that way in a sense that from a model perspective the front end is a different consistent language right so you speak a different language to your customers then probably how you would solve the specific complexity just what you see the problem there is that you want to have teams as close to your customer as possible and that's harder to solve in that architecture and it's something i i struggle with as well right because that customer journey then you have really that front-end team that's close to the customer but your bounded contacts teams if there are multiple teams so if it's one team i'm in that situation now it's fine but as soon as you scale out and you need to split somewhere you're splitting unbounded context and you're saying well this this bounded context for uh business complexity let's put on one team on it and the customer journey team on the customer journey bounded context and now the other team isn't as close to the real customer anymore it depends if you're or how your organization is structured right so that that that other bounded contacts could be your users could be the business itself so then i'm okay with it but uh if the users are still your customers in the customer journey then that that i think serves a problem it might be yeah anything defense of course sorry i think there's a false dichotomy i mean um i did the same right in the example before but there's always this understanding that front end and domain are different things and um they're not different they're not different i mean if you have two bounded contacts and those two bounded contacts have a different language the one bounded contest context focuses on some part of the domain the other bounded context focus on another part and still there is interaction going on so you need some kind of translation right this pattern exists already in ddd now imagine that one bounded context has its own user interface right there represent communication with with a customer and the other bounded context doesn't that's fine one bounded context could be a pure user journey and then interacting with the other bounded contacts other bounded contact contacts could build some kind of composite ui that aggregate information from other bounded context even so front end or back end are orthogonal concepts to domain and context yeah that's not the dichotomy here it feels like one and in our culture it still is and that's a problem i think so if you go to this is what francesco said in the beginning if you go to conferences um or if you talk to two front-end teams right they either talk about front-end design and do javascript and react and vgs and whatever or you talk about java and net in the back-end and building domain models but that is a false dichotomy those things shouldn't be mutually exclusive or even related it's you build a bounded context and whatever is in your solution model is part of your solution model sometimes that's pure business logic and semantics and only rules sometimes that is feeling icons sounds smells whatever some bounded contexts aren't even software but part of a physical solution system right building and a door and whatever so this is it gets philosophical at some point of course but i wouldn't i wouldn't separate between front and back and um in ddd i would specify what are we trying to solve with this bounded context are we trying to better the user journey well then the front end part of the software is definitely part of our bounded context yeah and that was not my my thing it was more about teams right you want your teams i think christina you want to pitch in uh because i think that's what usually our discussion is about right putting your team as close to the well user of your system as possible yeah so why why should some people be need more near to the customer as other how many back-end developers did you see they didn't even know about the customers or they are building huge graphics for the sake of uh we can build it yeah this is the biggest mistake a team can do yeah i think a great rephrasal there would be not close to the customer but close to the stakeholders is what bounded context developers should be so if my stakeholders are or if some of my stakeholders are the end users or the customers then i should be close to them if i'm a bounded context developer somewhere in and now let's say for a second argument the back end i'm building some rule engine that gets used by other bounded contacts then i need to talk to those people but not to the end user right so whoever the stakeholders behind the solution model are those are the stakeholders the developers of abandoned context should talk to yeah so a perfect example here in the cinema domain as you said right is you're exposing someone who could reserve a ticket for a seat and they can choose the seating but the way you allocate that it's really a business model right the the the business themselves are more concerned with how can i optimize people with the money i make for a certain thing so that's the purpose and the model of one and and exposing that to your customer you're more concerned with how can i give people the correct feeling of choosing seat which is two different purposes but the same same goal i'm sorry francisco yo it's the same goal you you cannot just allocate and the big have the biggest best allocation method if the customers are unhappy or yeah but then that one model has two stakeholders one it's the users but also the business revenue for example i i agree with you it's completely a team problem an organizational problem okay i think that the conway's law is all over the place when we are talking about the stuff and i can make you an example when i facilitate some you know evan storming or something like that where i need to extract a model from a business the conversation change dramatically if you put in the conversation also an ux designer on a ux researcher that makes talks about users and not just about domain experts because domain expert can't see all the uh they can't see all the domain problem all the business problems but they can see how this problem are perceived by the end user uh if you put somebody that is a i don't know like a user representative okay in in the mix your discussion changed completely and and you see that uh sometimes the bounded context start to merge into okay we are talking about the same stuff uh the users are an integrating part of our domain model and things start going differently okay it's more easier to use than the same model in the front end when there is there is no user experience person in the mix uh you know they are like in the bubble they are talking about their business about their models but not about this how these models can be used by the people outside um i think this is a part of the problem that we are trying to solve here you you are talking about sharing models between the front and the back end um so i i don't know if there's if i if i glanced over it or so but um is there any solution when you have let's say let's say you have a javascript front-end right you build everything in javascript and maybe react and if you also build something with node.js and javascript in the back end of course that would be an easy thing then you can actually share the model but if you have a back-end in java or dot-net or or any other language or maybe even a different paradigm you build something in haskell um and then your front-end is react and vue.js and or any of those javascript libraries how would you synchronize your mental model if you really want to speak the same language oh great question okay i can give you two example something that i did uh i did not do a synchronized backhanded front-end but uh to synchronize a web application a front-end application and a mobile application okay so we have a similar problem okay it's not a back-end but we have different languages okay because you have javascript and you have java kotlin on an android application okay in one case we've wrapped the javascript application in java with longer rhino there is a java javascript compiler in uh interpreter sorry in java so we keep the same stuff that the the android application downloaded the same javascript from the cdn in another case uh we wrote uh two different teams and they wrote the same unit text test to keep the model aligned they work together on unit tests and the way when they were okay this is the test that we need to pass okay thank you and the two teams were going to convert the test in the language but to convert the test is easier okay they're converting the code because you just need to read it and then uh when all the tests are green they are okay with that uh two different way of doing the same stuff that i witnessed so you're basically doing transpiling or manual transpiling so there's keeping the models in sync yeah i mean that's that's the it depends decision many people have to do anyway right um or we think about do it manually or automate stuff so so you would say this is either a short kernel conformist relationship between the two models of obama's context in that case or was this within about context or between bounded context in my case it was exactly in the same bounded context okay and then we yeah yeah it was exactly the same model okay because you know you have a mobile application and the front-end application they were doing actually the same stuff okay as a model point of view yeah yeah christina just provided a great example in chat saying in the last company they had one set of bdd tests i assume was cucumber or something like that and then they were implemented and executed by the api at first and then by the app afterwards so synchronizing the behavior by test by building everything test driven and having a language that gets transpiled or translated into into both programming that's also really good way so yeah we had some tests for for uh for the app only if we had some things which were not really business rules but uh get it nicer or make it you cannot go in the api back and forth and you can do this in the website of course it's a different behavior but most of the basic tests are for every story every new discussion we had this question okay which are the business rules which are our constraints and these were one set of tests without including any words like the font size or front-end stuff or back and stuff but the pure behavior yeah this was great and i think that's what i try to do one of my key heuristics in dvd is always remove technical wording like create read update delete back-end front-end you might end up with a bounded contacts it's just purely front-end code right but that's the solution detail don't call it website please call it what it is call it like blah blah blah journey or call it what it is what you're trying to solve and not the ticket reservation my question control question was always which customer would say the viewport should be this yeah good question um yeah i've worked a few years with roman saxey on uh on front ends and we've built a net software right so um going into functional program with f-sharp over a while we found fable which is kind of like a babel for f-sharp so it transpiles into javascript and we actually started building our front-end and our back-end in f-sharp so we could actually share the model it wasn't just like a transpiling where we then continued building stuff in javascript but you could actually write one code and use it on both sides and that felt really great but we figured something was really off and that is i mean it is obvious if you think about it but it caught us by surprise at some point uh you have business rules and those business rules should be met in the front and the back right so assuming that you are in the same context or in a similar context the same behavior but validation in the front end is different than validation in a context where multiple users are involved i'm keeping to getting the english word for that competitive no yeah well i'll figure it out later but yeah so if you have rules on the back end where multiple users are involved now the rules to change or they are slightly different or they are only encompassing the the rules from the front end but also adding more rules so really starting to compartmentalize your business logic into smaller and smaller aggregations or functions basically that could be composed that was kind of the the way where we where we went to in the end language-wise so building smaller and smaller aggregates when you are still thinking object-oriented or building composable smaller functions to really build the same language that is usable front and back and no matter where you are and everything is written in the same language it's kind of a beautiful state to be in but of course it's completely coupled to a specific framework and a specific language that you can use so it's very very specific use case but after that i realized every language that does not build a javascript transpiler is losing a lot of opportunity so finding or building your own really good javascript transpiler that builds i don't know react components or so to make you able to just describe your business behavior in your own language and then have it also work on the website or in the front end or just use node yeah just use javascript in the back end yeah yeah so i think i think one thing uh sorry francisco before you continue and there was something in youtube and i think one thing to make it clear is a bounded context can contain front-end technology or back-end technology or both yeah i mean both all three are are solutions and accidental complexity anyway so uh because we got this question going into isn't kodak coding on behalf of enforcing ddd ideas by creating a back end to serve the domain implemented in the front end few instead of letting the front end use different end points but yeah that's really some as you said before marco a different well that's how i see it that's a technology choice that ddd doesn't have anything to say per se yeah right yeah i totally agree yeah so sorry francesco i wanted to uh yeah just answer something in youtube just a word of warning about transpiling to javascript or on transpilers in general because uh as a front-end i can i can say that it gives it gives you a false uh state of serenity uh an example uh for example if we work in typescript okay the typescript is really allowed by frontenders today because they say okay i have why wow i have types in javascript okay in the in reality that code is completely run a real time so for example if you create your perfect model that came from a json and that that json it's broken from the server your application will break uh constantly and the sad thing is that if you think that your model is perfect because you designed by with types you completely forgot about data validation from the jsons i can say that from a real world because i made the same mistake and i see this mistake you know around the code that i saw in uh in the last couple of years so this this triggers two things for me i mean you're totally right um this is a big big problem um and kenny was hinting at that in the beginning of the chat saying uh ports and adapters also could belong to the front end right so having the same mental model to orthogonally separate your infrastructure from your business behavior domain behavior also holds true in the front end so when you get a json message and the json could be broken right but in your domain model in your front end your domain model needs a specific type with a specific format and specific data in valid states you need to have a mapper something like a repository that can actually take those jsons and make them either valid value objects or or not and um yeah this is when we were working with fable so the f sharp babel transpiler um that's something that worked really well because of the elmer's architecture there was a model view update pattern and the only inner output of the whole architecture on the front end is messages so you get messages when you start loading your application and it's basically a react component which has all the amish architecture inside them so you have a functional domain driven application in the front end that is encapsulated in a react component and behind that you can have an api that is doing mapping between that and the rest of the application at the front end or the backend servers right so it's an abstraction the the domain model doesn't know where it's living it doesn't know if it's running in a test back-end server or in a real website or in a headless browser in a c-sharp application it doesn't know that it doesn't need to know all it knows is hey these are my messages and there can never be messages in a legal state because you wouldn't allow them to go into your model you need to filter that before you put them into the domain because there is no domain user as christina would say there is no stakeholder who would actually talk about broken null values in an object that's not how business people think or or users think sometimes they do but those are broken people yes so a question here let's say uh this is for you francisco as well so something i've been struggling with right so like aggregate goes into consistency it can be done in front and right which is fine uh but but let's say you have one bounded context you have a front end and a back end let's call it like that as a solution right uh because you want something to happen i don't know you choose for that way you need to keep the front end and the back end language in sync because that's what we want in dde right that's what you were just talking about transplanting but you also have then sometimes duplication of business constraints right constraints that happen in your in in the dd objects in your let's call it back end right where you have uh like a grids that that that uh persist state to to the back end and but then that same rule needs to come back in the front end so that's yeah that's a lot of keeping things in sync right how do you do how do you cope with that how do you deal with that uh what are your heuristics yeah but they are not really in sync because when you are talking about a front-end application you're always talking about mono user application like marco said before it's you and your user on the other hand when you're talking on the back end you're talking with the multitude of data so in a real world case scenario they are very similar but not equal so they are not duplicated okay they are different in one sense of the same model if you want because doesn't that make them separate bounded context anyway because they're non-consistent yeah so i'm just kidding right because i say they're nuanced models for me that's two separate models so they are talking about the same stuff but from different point of view and they are using the same language but the point is that when you are writing your model the fact that the application where you are going to run it is mono user usually have some kind of uh like say uh uh some differences in real code okay so you have you know like marco said probably you have your model splitted in smaller smaller models because you need to give feedback to the user on every single input for example imagine that you are you are validating an order okay a classic dtd problem on the back end you probably will uh validate the entire um order on the front end before validating the entire model also on the front and you probably had made a lot of smaller validation while the user is using the creating the model uh another point for example when you are talking about evander event architecture for front-end and back-end analystic that i can give you is that the number of type of events not that not the number of events but the types of events is 10 times bigger on a front-end application because yeah because uh for example uh i make an example okay on the on on the back end you have order created okay you have order created also on the front end but before that sometimes you also have a lot of smaller events also local okay they are not uh bounded to the model but they are just bounded to the ui that is for example a wizard or are depending of the ui you're creating this simple differences can you give an example of those events uh for example a header created for the order okay you don't save the other but you are created it in the ui and you need to go next so uh they are not model events so you don't send them to the server like i showed you before but if you want to make your ui move with events you have a lot of more events okay so okay sorry sorry i didn't want to interrupt you i'm just i'm getting nervous here um so there's there's a distinction between domain events of course and ui events right so you have button clicked or header created or mouse moved or anything like that as long as it's not a semantic meaning to the domain but just to control your application i'm totally with you those events don't matter for the domain model but if it's something that the domain cares about let's say you create a header for an order not like a ui header but you really create there's a letter and there's a name and you create that letter that header that's a domain event it doesn't matter if you actually send it to the back end or the front end or whatever but if your bounded context is purely in the front end and your bounded context is about creating the order and doing everything and then the communicating external event would be order or shopping cart has been ordered or something then of course you have domain events more in the in that front-end part than in the back end um but it's still domain events and and still i want to i would like to get away from this dichotomy saying there's a front end and the domain those are domain events and your bounded context just happens to be purely in the front end yeah uh i agree with you what i was trying to say is that if you have the header created event okay it's a domain event and and you need to validate these events with an aggregate or invariant okay the same code probably you will have the same code in the back end but why because you need to validate the order as a whole for example because you have a one post as a rest api okay you can have a technical uh pound okay that you a vertical gate that you have to solve at a point okay if you have for example a post rest api to create the the big order okay uh you will have to uh validate the entire order on the back end yeah this is what i was trying to say sometimes you have uh asynchronous yeah so that's the problem with with having web front-end technology it's sent to the customer so they can manipulate it and put it themselves in a uh in a state in a how do you call it again in a state illegal state one in an illegal state so front-end is manipulative yeah right the back end so yeah but that's that's exactly the thing that i talked about before when we said we have validation logic right there is a domain behavior in the front end yeah it's no context that is this customer facing and there is also behavior that is similar that is uh in the fulfillment area of the in the fulfillment boundary context and if there is the exact same business rule it's not sufficient to just check it in one context and then just trust in the other but it has nothing to do with front or back end but if you just think about if you role play your domain right if i go into your office and say hey kenny somebody ordered this and you're not checking anything you're just saying great let's just send it to the customer like no that's not how your business would operate what you would do is if i give you an order you would check if that order makes sense and if all the if the customer is we present pretends to be and and then fulfill the order but you don't care about the details of how this order came to be that's part of the other bounded context so you can have shared behavior and that's what francesco said right you need to somehow transpile your behavior or you need to do checks or like christina's team did do some kind of bdd test driven development so you have the exact behavior on both on both sides but even if the front end part or as i would call it the customer facing bounded context even if that messes up your business still doesn't suffer because your bounded contacts that does fulfillment still has a sanity check based on the same behavior and yeah christina was just writing the front that is easier hackable right because everybody can just open browser hit f12 start editing stuff and you know that that's the same thing as if you have a bank with open doors if you know that's the case you need to find ways to protect your business anyway so yeah do a double check before you fulfill the order that's a domain driven sensible thing to do that's from analyzing the business behavior without talking about technology in any way and then usually it becomes javascript in the front end and java in the backend or something like that but but yeah is it done so so going into that again to my point if you look at bounded con abounded context and consistent language i'm using in my front end i'm using a a a type a type right for instance in this case order and in the back end i'm using that order but it's a different order from a model perspective it's a different language so if it's ambiguous isn't it two different bounded contexts yeah this is where it becomes really nitpicky so this is where i was screaming it depends i'm i'm nitpicky now yeah that's that's what the pattern says right the pattern says a consistent language yeah without a model for a purpose i have a philosophical answer for that um so it's it's two or three steps um the first thing is of course as long as you have the exact same behavior guaranteed right if you have a transpiler like fable that's one model so it's one bounded contacts and you don't need to separate if you do a transpiling by hand then the behavior could be slightly different but conceptually it's the same i would still call this a bounded context because it's one mental model and the team that is building it understands we have solution parts in our server system that is running for multiple users and we have part of the solution in the user facing front end but we are building this one mental model and an order looks like this and behaves like this then there could be technical bugs right your javascript could fail for different reasons than your java code and that's a technical background that's fine it's still one mental model with different implementations underneath but there's one model but i told you how it gets yeah now it gets interesting because that was the question right is it easy for onboarding and i think if you look at both codes and you talk about the same shared mind model marco i agree with that so i like that approach right if i look at both codes they relate you just need to keep them in sync yeah but now comes a challenge but now comes it depends part because now you have two different code bases with one idea behind it one mental model and for now your organization ensures it's always clean coupled the same it's one mental model but imagine now your team consists of three people who are really fit in javascript and react and three people who are really fit in delphi and building the back end system so and the team grows and grows and separates over time locally or time zone or whatever pandemic and then different cultures your teams separate and then your bounded context split in the front and back end that could happen all of a sudden it becomes two different mental models using the same language a little bit right now but already having different understanding of what it means so in the front of the behavior could change because the order in the front end is mutable right and in the back end at some point they say no no an order is immutable because you just have to fulfill it so all of a sudden it grows on all of a sudden but it grows over time into different uh different behaviors and this is something where where team topologies or even bounded context mapping uh become a temporal thing every model you build is always temporarily correct right now it's one mental model but as soon as you have enough reason to split it into two mental models make it two bonded contexts if the actual behavior or the actual thing changes it is not the same bond of context anymore yeah and i think again we're we're coming back to the point that if we split we shouldn't split on back and front and we should split on the model so we need to yeah yeah we need to burn these backhand in front and that's what we're saying right but that's that's usually the anti-pattern that we're in just because it's easily splittable in because they're sort of like two models but they're not and you split them on the models we should talk about the models and not again about front-end and back-end teams so we should remove that from our language and keep and that's one thing that dvd keeps saying right if your model changes be mindful of it yeah the the biggest problem here is when you say we who do you mean the wii is really hard if you mean we the the the nine people here in the chat all ddd are facilities uh you know fans of ddd um right that's that's totally easy we can change our mindset just by wanting it to because we understand i don't know i've seen it about 100 different domains or so and the biggest problem is not that the domain experts don't understand it might be the same model the biggest problem is what francesco was hinting at at the beginning in the companies that produce software you usually have a culture of this is our design team they do design and they make html grade or css or whatever people use today and and this is our domain team they understand code and build the back end and if that's your company culture it's really hard to change that up from the bottom up from understanding oh we should be one team well we're not so taking the reality into account this is where the temporal nature of bounded context mapping is so important right your team structure right now is very different from what you think makes the most sense for your customer and everyone who has power to change that should push into the direction of let the design of the software be driven by the domain which is kind of in the name so actually starting to to make more cohesive teams to have cross-functionalities to yeah thanks christina welcome to silos right to get rid of the silos you you've built just because you think that graphic designers and programmers shouldn't share a room um which is completely the opposite of what's true in my opinion i mean i'm not proclaiming i know the truth here but in my opinion that's that's not the important distinction so um yeah end of rand took it out so is that how you see it as well francisco do you have anything uh yeah i i completely agree uh the point is that we can't solve it with code if you have a team problem it's impossible okay uh and i sometimes it's also okay if the true model drift because like christina said they can evolve differently okay it could happen it's also completely fine uh you only need to be aware if you become a different bounded context perhaps you start using a different language too because uh the front end is always user-faced never uh it's almost never business-faced okay because the the problem that you are solving at the problem of the users all the time and so with time what could happen is that they become two different bounded contexts uh but you know i think that you cannot solve uh everything sometimes you also need to let go okay uh there are different boundary contacts okay we will remap them uh if the code is top notch in any case i mean it's tested continuous delivery or whatever i can live with that but we need to remap the context because we need clarity because if i think that they are the same meaning but they are not we have a problem and i think and i think you make an important point uh i i try to teach people is usually we have the communication straight to the unit of deployment right so let's say you have a unit of deployment called the reservation system or something then we talk about the reservation system but we should shift our talking and and that that that leads to back end and front end again right because we're talking about technical solutions but we need to shift our communication to that of bounded context that that is our gateway and it doesn't matter if it's front end or back end but that's the way we should talk in and that's what ddd in my opinion is the big added thing right we talk about bounded context your backlog is is is also talking about the bounded context instead of what system should we change right your your user stories are i need to do this in that journey or i need to do this in that bounded context not i need to do this inside to use the story you will have implementation or that oh that means we need to touch upon this and this system but i think it starts there it's changing the communication towards models and bounded contexts instead of unit of deployments for front-end and back-end because then front-enders and back-enders talk in models instead of the technology they write them i think that that's a clear thing that that's my rant usually stop talking in units of deployment period it's the same issue it is the same issue with graphql because you don't talk you don't exactly you you make a huge api interface and say don't talk to me take from here what you want this is a total disconnect and everybody is frustrated and everybody's working twice because and similar and similar for the event cues christina right i dumped it on my event cube just take it go exactly it's the same i want to say a word about sorry marco i was uh go ahead okay um a word about graphql because it's quite interesting because graphql is born i think is facebook like one source of truth for for all the mobile application okay so i i think we are talking about 50 uh 50 front and different uh application and and and people use it when they have four developers okay in total so the point is that it's usually uh unuseful because uh you know just prepare me a dedicated endpoint to solve my problem but you know i need to talk with you i i don't want to talk with you that's what graphical trying to solve yeah yeah so that's that's what i agree it is it is not graphql's issue it is the people yeah yes we used software everywhere and never had never even thought about this solution until until one year later i heard everybody was writing about the afghan but it isn't cuffed well oh so that pattern didn't happen with microservices and that's the same it's the same the whole that's the whole point of starting with the model first right start to understand what are you actually solving for which stakeholders and the the way you separate your bounded context depends on what you're trying to optimize for right there is not a natural boundary like it's a design decision and if you separate your teams alongside a certain boundary and you understand in your model there is respective behavior between you either i'm telling you to do something or i'm asking you for information and you need to provide it within a certain amount of time or with a certain quality all of those things are part of our mental model of how we provide a good solution for the customer's problems and then we implement it and then graphql is a wonderful solution if you have a problem where this fits it's like with every tool if you have a tool that fits your problems nature or structure well that's a great tool if you try to chainsaw your hammer uh your nail out of the wall that might be overlooked or might be wrong so yeah and this is the this is the thing i always see and i try to mention in one of the talks i give is people choose one strategy yeah but it's never one strategy you can do you can do micro uh you can do microservices you can do serverless you can do strategic monoliths all at the same time yeah all at the same time you can do event driven you can do rest you can do graphql at the same time if you at the same time you can do outside in testing and inside out unit testing at the same time just choose when you pick one over the other because both have pros and you both have cons yeah and that's what i usually see the trade-off here is of course team maturity right if you have a mature team where everybody is high-level skilled thinking about the customer needs first understanding all the options and making sensible trade-offs and also understanding their own emotions in a psychological safe way to communicate and all that if all that is a given that's the best thing you can do you can really build the optimal system if you of course are in a company where you have time pressure everything needs to work last week and everything has to be of course highest quality and there are 15 000 different stakeholders and you can't communicate with them but then you still need to build something at some point being defensive and just building up some kind of graphql interface saying i put it on the event queue right those things are the natural follow-up of a broken company culture and not per se of a bad programming technology or something yeah question from the audience um so we get this question is being asked a lot and i got an answer from a classic dddd point of view right when ddd is too much for a project question mark so you model where you want to model a lot and where you don't right so you supportive and generic yeah how much would you use in your presentation what you just did francesco when would you when will it be too much to use this approach in and where how far would you go in what you just showed us in your code so when it's too much to to use it what would you use and what won't you use in certain situations uh i think it's uh too much you have just standard validation models okay for mobilization model or something like that uh when you don't have a complex ui a complex journey also because uh i think that it's easily to introduce later point in the application so uh my suggestion is to start simple because in javascript easy to make a mess okay it's uh it's very easy to lose control uh and i'm saying that from a javascript point of view okay uh so my suggestion is to if you choose a framework keep the framework in mind for a while see how it goes and then introduce some ddd after a while before before it's too late but not from the beginning uh because it could it could be get messy if your team is not uh ready to do that because like i said before they are two different worlds okay so if you introduce some ddd concept like aggregates in a team that only worked in react until the day before it could become hard okay so it depends on the sides of the problem you are solving the complexity of the problem and the maturity of your team this is the main pain point it is a very very mature javascript developer to start implementing this stuff yeah i think um this is one of kenny's sticks right having heuristic collection here that you can use so there is no best practice and there is no obvious perfect solution but one of the great heuristics i found in the past is if you have a front-end team that is completely not used to working with with back-end teams or with domain models in general is have one person from the adjacent bounded context um from the back-end team with already domain-driven experience be become part of the front-end team so cross-pollination of those ideas because i don't need to be able to write javascript to be able to guide you to separating your domain model in the front-end right that's one of the easiest parts is to look at something and asking smart questions to get people to see why this is not the obvious best choice and starting to separate technology from domain model that's already your risk in itself if i cannot read your domain model in your code yeah it doesn't matter which technology if i if i don't understand or relate to it if i know the domain and if i don't relate to it then okay something is up yeah um yeah i've had a little glimpse of that when i was looking at francesco's code before because yeah the domain model is pretty expressive but you use weasel words like repository or aggregate i was like why is the word repository popping up in the code that shouldn't be there because a customer repository is basically representing the customers right you could name it customers and have the language be more domain driven um oh yeah okay i never thought okay i do that on purpose and sometimes i enforce this code style because i want people to start thinking about repositories i i i usually call it customers and customers api when i want to talk about api okay so the service i talk about customers uh repository i call apis usually because it's an api uh this is an endless discussion i get a lot right well it's a repository why don't name it repository because i know what technical approach it is and then others would say well then it's polluting your domain language because then the next meeting you will be you will say it's a customer's repository and you don't want that with so yeah yeah i think that we know this is an interesting show but uh in this particular code i make it on purpose because i want to be clear what i'm talking about yeah that makes total sense and sometimes i also made it in a real project when i want to people to start talking about repositories because they need to start understanding the consequences of using a repository but usually i don't like it i prefer customers as a whole yeah the thing is right everything's a trade-off and i mean this is something that we always accumulate towards at the end of every virtual dvd meetup kind of everything's a trade-off and it depends on so many things so there is no obvious best way right calling a customer repository or customers both have great upsides and downsides um if you want to teach people and if specifically if you want to transform a group of front-end developers into domain-driven thinkers yeah calling it repository to make things explicit is great way to to make those concepts explicit in code um if you have a really mature ddd team you don't want to read a story like harry first name potter last name person walk action a long street infrastructure like that's not how the story flows right you want to read the pure business language to understand the the novel yeah yeah and and it's still something i would use naming is hard so i'll name it wrong first for quirky or let's just name it weird and then we can change it later probably if you if you decouple things correctly so it's naming it first repository and eventually in a week later you remove it i've done that yeah i've done that recently actually first you name it repository and really remove it in a review then someone reviewed it and said kenny why would you use repositories that's not fun and that's that's a really cool thing i've seen in the past is front-end teams are more prone to building transformable software anyway because technology in the front and changes way faster than in most back ends so building models renaming stuff to deeper insight those things have a hard time to get adopted in many back-end teams because people want to build a domain and it should work forever right and uh that's not how the world works but getting them into a transformative mindset where software is never a product it's always a changing process that is evolving um that's that's harder for back-end teams and actually this is where the front-end teams have have an easier time because they anyway need to change every few months because technology evolves yeah this is a thing that i learned as a front tender i was a java backend developer okay so right now i'm a completely different java developer i don't think too much about uh a lot of stuff i just go with the flow and some tests uh but this is stuff that you learn with javascript because javascript is always a mess you you learn to live dangerously so christina nodding yeah so you're always in a state of uh uh chaos so you're always on your toes so you're you're you're battling some of your biases yeah always keep the keep the chaos fear up cool okay i think uh well i don't think i have much to add or questions is there someone still from the audience i don't see any other questions well that's the that that's the one thing that popped up right is this type of approach easy for onboarding developers in the project uh it can be right idea independent of the background or the background of the developer that you are on boarding if they are if this is somebody that knows about tdd they are on board on day one if they are i know some junior developer that just saw some react code it could be different um it could be harder because you are you are working in a way that is different from what the framework tells you to do sometimes and it could be harder yeah and i think what christina says that it could make it easier because you tell the story and that's what i like so i usually when i onboard someone i start with the documentation i show some event storming some naming and domain concepts start popping up right and then we go to the code and then one on one it's there even though it's structured differently people start already seeing oh oh oh yeah yeah and that's that's actually the pure uh i think core of ddd is that you want that epiphany right i see the conversation i see that i see in your event storm documentation i see it and i see it in the code and i think then the onboarding would uh yeah it's really nice i guess yeah but this is true just if they can read the models in your language this is what i mean because uh a javascript developer a reactive developer okay a junior react developer is not a customer to read pure javascript file in that way so they don't focus on your story they will focus on the code they will focus on what the heck it's written down here why it's not in the react state for example uh and so you know your story just poof they are concentrating on the problem and not on the solution yeah i mean that's a cultural problem right that's always one of the hardest things when people really want to think in technology and you really want them to understand the model and helps finding a solution or proposing good solutions that's always a like a geometrical working forces and it takes a lot of time and patience to to get people from where they are to where they would be really helpful um but if the company the team in general is very domain driven then it is fairly let's not say easy but it's pain-free to get someone from the outside who thinks totally in technology and to say look all of your expertise is really wanted we need that we need to have a sanity check on our tech but this is a story and then you spend way more time with sticky notes and and spoken words than with actually looking at code i would not start looking at a domain model in code when i know that someone is focused on oh this is this pattern and this is the wrong api like stop thinking about that if someone is code focused don't show them code first start talking about the domain first and then slowly expose them to more and more code and then go back to the model so they see why they're doing everything and make transparent what you're doing right don't do it don't do it by accident tell them we're trying to teach you the domain before we go into technology because reasons yeah and that's why i love the ports and adapters as well because that decoupling of the two right really helps where i recently we were making a connection to cosmos db and i can say well here's your project which is an adapter site just go for it and of course experimentation and then we can just in one half hour we could just refactor that code that we didn't touch any other stuff so similar to the domain model where you can make these isolation right so here is your place just go and then later on we can easily more easily refactor because we made that decoupling strain so this is a much easier way than having a really big unbound on boundaries project right where you see no boundaries then it's more frightened for a junior to change something but if you really could decouple that you can really say well you want to take this bit and just implement it here and just go nuts try to solve it and then together you can refactor it because then they will learn you will learn you both learn bonus points okay well um oh one last question would a task-based ui exposed domain language and operations uh can you repeat please yes what a task-based ui exposed domain language in operations i don't know i i need to think about it quietly um [Music] no i can't get now i think i i'm also tired to answer the question now okay so i'd say um whoever asked that questions um go to francesco stratzello on twitter and yeah post that question publicly and then he'll get an answer once he's awake again he had his coffee in the morning yeah yeah i'm really sorry but i'm quite tired now to try to answer that now so before we wrap up could you share the github link of the code so i can share it on youtube as well and um well if there's no further questions in a moment i will try to yeah we yeah yeah got it so here we go sharing it on youtube uh thank you um perfect so that's a lot thanks a lot it was really i learned a lot again to think about this thanks for the rest who joined in thanks for the people on youtube and before we leave uh marco has a nice thing to share before we leave right something yes there will be an open space for domain driven designers in berlin on october 21st and 22nd um our former conference kandinsky which has been going on for four years now we posted due to the pandemic last year and this year we have 100 tickets i mean some of them have already been sold so if you want to join speed up um but we have 100 tickets it's in person only there will be no videos it's an open space so you build the agenda whatever you want to talk about workshop about we have a lot of rooms we have free sticky notes for everybody and it will be two days of collaboration the only condition is you have to be vaccinated or recovered because of health risks we don't want anybody who's just tested and we will be very rigorously with that but everyone is welcome to learn to collaborate and go to kandinsky.com we'll post the link in the chat and on the youtube as well christina here has the first ticket already so she's getting the prime spot first row and yeah happy to see everybody there yep great thanks and um see you there as well for our uh next virtual dvd so for everyone listening uh if you like francesco want to talk about a topic give a presentation uh just have a well whatever you want everything is open to share we can record it we cannot record it that's all to you but if you want to just talk with people uh on a topic on dvd please reach out to us and uh this was it for tonight thank you francisco for your time and for your effort perfect thank you for the great dialogue

Channel: Virtual Domain-Driven Design

Views: 284

Rating: 4.6923075 out of 5

Keywords:

Id: gX_Nx1vqeBQ

Length: 95min 55sec (5755 seconds)

Published: Tue Sep 21 2021