 So hello everyone Today I wanted to talk about two main topics the first one is no SQL a second one is domain-driven design And then I want to bring those two concepts together and explain how I think they can enhance your applications and make them better So there's this story about building the tall of Babel and in this story in the beginning They all spoke the same language and they build a really impressive tower like look at this tower. It's really impressive but They got really braggy because if people build something very impressive they will get braggy So they were punished and the language was taken away and then the tower never got finished so in our projects we Often don't start with the same language We maybe start with the same human language So even if not all the people involved in the project have the same native tongue They will probably switch to English or something, but we all speak a different jargon So you may have someone in your project who's like dealing with databases for example Then this person uses words like tables for example And then you have a programmer and she will probably talk about classes and about variables and stuff like that And even those two worlds are not very close together And then we have a domain expert in our example because space is awesome We choose space shuttles and astronauts. So this person really knows a lot about space shuttles and astronauts So this person if someone tells them there are tables going on then this person probably doesn't know What this means even though they are very familiar with the application So Eric Evans came up with this idea of domain-driven design So he wrote a really good book about it And he says that his main goal is that everyone finds an ubiquitous language That means that this language is understood by every single person involved in the project no matter what their role is if they are Programmer a domain expert or yeah a database person In this language and a lot of projects I see that people try to evolve this language from the programming stuff, but Eric Evans suggests that you take the domain language because this is the problem You are trying to solve and therefore it should be at the core of your discussions So domain-driven design has two Building blocks it is built on so without them. You can't do it. The first one is iterative development I won't talk about that too much because most of us know that and probably do that if you have questions about that come to me later So I will skip over that the other Important thing is that you have a close relationship between your developers and your domain experts because if you want to develop a Language that everyone understands then you have to talk to each other if you don't talk to each other then You can't develop a language So hi, my name is Lucas. I don't come from a place with such beautiful beaches I come from a cold place called Germany And in particular I come from a city, you know as Cologne And there's a big myth going on about German people and about our language that our language is like built from very long words And actually that's the lie so Cologne is how we call Cologne in Germany and as you see it's much shorter than Cologne So this is an obvious lie if you take one thing away from this talk, please let it be this So as a second example in the background you see this quite impressive impressive church and in German it's called a dome and in English. It's called a cathedral. So you see this is all a big lie But I don't want to lie to you. So this bridge you see on the right side is the Hohen-Sollern-Berke So maybe there's some truth in that Okay, so I work for a company called Arangudibi GmbH, which means like Arangudibi Inc. maybe So we work on something called Arangudibi and Arangudibi is a NoSQL database, which is open source It's on GitHub and it's a lot of fun working on an open source project for money so one question that this raises is what is NoSQL and I think a lot of people understand different things when they hear the word NoSQL so I want to Yeah, first confuse you a little bit more and then try to explain what I think NoSQL means So if you look at this there is something called SQL and then everything that's not SQL is obviously no SQL Right, so if you have a chair a chair is definitely no SQL Maybe it can even scale so and People try to confuse you even more so they say the no doesn't mean no because it would be too obvious So it means now not only so this makes it even more confusing because now even parts of this SQL thing are part of Not no SQL so yeah, nobody really knows what is going on anymore, but let's try to analyze what what this means so What is no SQL? It's not SQL obviously like this is probably the only thing we can say about it And this is not even true anymore So the question is what is SQL and SQL is a relational algebra and This raises the question what is an relational algebra and it's obviously an algebra and relations so What what is a relation? So? This is a relation It's a set of tuples So in this case we have two tuples one is Alice some date and a number and the other one is Bob Some date and a number and we can't really say what this means But because what is this number at the end this second one could be a birth date It could be anything But what is this number? We don't know so we came up with a quite good idea And how to represent this in a more natural way and this is the table so you can give it Header line and you can explain what those things mean so in the case of name and birthday This is quite clear So the name is the name and the birthday is the birthday But why the hell is the city a number because cities normally are like words like current so This is a topic called joins which we will get to in a in a few minutes But first let's say okay, we represent those as tables because We also like adopted that into our language if we talk about Our that database we talk about tables and we drop tables and stuff like that. We even flip tables So we have one problem and this is a huge disconnect We have a domain world And in this domain world we say that Alice owns a spaceship, right? so This might be a diagram that someone draws that that wants to explain to you what this What the domain is about like they would say like here? This is Alice and this is a spaceship and they are they are like connected to each other And we draw it with an arrow and then there is this database person and says ha of course then I will have three tables and Every person that doesn't know anything about sql will probably now be confused And this is the disconnect this talk is about So but let's first dive into this left side into this domain side So Eric Evans sees six main types of domain objects And the first one is an entity and an entity has is identified by an identity So it yeah, it is something so it yeah It's if you change something about it It will still still be the same thing a good example for that is a person So if a person gets married and changes changes his or her last name then it will still be the same person at least in the database and Therefore we have to make this state mutable and This is different for a value object because a value object is only identified by its value so For example a street is a value object a Street has a street number and house number a street number I think and If you change something about those two things then they are not the same thing anymore So they are immutable as soon as you change it. It's not the same thing anymore And this is quite important And then we have services and services are things that do things and they are just identified by what they do So for example a service that sends mail to people Would be identified by it sends mail to people And it's hopefully stateless. I see a lot of services that are not but hopefully they are So if you do the same thing twice with a service it should produce the same output twice Okay, and then there are three more I will skip over them a little like we have factories in ruby. We call them builders because Java's probably But we still have them. So there's something that Produces other domain objects Then we have a repository and a repository is basically a thing that stores other things So you can imagine it as an a big array for example You where can add things remove things search for things and and stuff like that And the important thing is because we are talking about the domain We are not talking about how this is implemented at all We just say like you can put astronauts into this repository how it is implemented is not relevant and in a lot of cases it is implemented by By being backed by a database and then we have aggregates and Aggregates are a connection of a domain model plus one or more entities So for example a person with the address they live in and aggregates are Yeah, give No, Eric Evans suggests us to do something special with aggregates and this is Denormalization and this is possible because those value objects you connect your object with are Immutable so you can copy them as many times as you want because if one of them changes You don't have to change all of them that have the same value because if some person moves to another Another house then not all people that live in this house change Switch the houses to Not necessarily at least so we can denormalize this stuff and in SQL this is kind of an anti-pattern And the reason for that is that we cannot put the tuples into tuples in an SQL database So the idea that some people had was let us let's lift those restrictions Let's say like okay now we can put tuples into tuples Also, let's allow tuples with arbitrary attributes where you can just say like okay This person has a name and this person doesn't have a name, which makes a lot of sense I guess so in this world We can now put our value objects into our domain Objects we can call this embedding So if we have a space shuttle and the space shuttle has some parts Then we can just embed those parts in the space shuttle and If your database is able to do this kind of thing that is probably a document store So this is one kind of a no SQL database So it's a place where you can every document has its own structure and the structure can even be nested So in our example, we now would have three documents We had we would have Alice and the space shuttle and we would have a third mysterious document Which has some two IDs in it, which is like the join document basically and This is again like it's closer to what we explain to people because we don't have this those mysterious tables going on But we still have this problem of connecting two things and we have to create something especially for Explaining what we are what we want to do here Also joins Like I heard a lot about joins in one talk today And I kind of like like a flashback because in the past life. I did a lot of SQL joints I did like social network analysis at university and I did a lot of joints a lot of joints And a lot of them were recursive joints and if you don't know what that means don't look it up. It it's bad. Don't do it So we had this long SQL queries in our code Because yeah, we had didn't have something cool like arrow. It was just like long strings like Build together And they had comments beneath them and they were all like I have no idea what's going on here like every single one So joints can get really bad really quick like in the beginning They seem like really fluffy and nice, but as soon as they get bigger. They are kind of scary so there's a different way to Model relationships between things and this is a graph. So we have Alice and As the person that drew the domain before we would draw like an arrow between those two things There's an ownership between those things. So Alice owns the spaceship. This is the way we would draw that and If you can do that kind of thing in your database, then it's probably a graph database There are a lot of different definitions of graph databases. I don't want to get into those I think the main the most important thing is you have Some way of storing graphs in your database and you have some way of naturally querying those graphs More is up to discussion. I guess So in this in this graph database, we could now express this this arrow directly So then there's this we had we had this spatial that Had consists of parts and we have this relationship now it would be nice if we could combine those two kinds of things and The idea behind the idea on how to do that is simple we just say that Alice and the space shuttle are both documents and In those with those documents we can do all those things that I described before like embedding stuff and The second trick is that the edges between them are also Documents so again, we can do all those things that I just talked about So for example, if we would want to say that Alice owns the spaceship since 1978 for example Then we could put that into the edge because it's a natural way of expressing that and if we want to know all outgoing edges That have that have been there since 1978. We know which spaceships she owned from that period on So if your database can do that then it is a multi-model database It called it's called like that because it combines two models of database into one database You could also combine different database together But most multi-model databases put those two things together. Maybe also a key value in the store, which I won't get into so I talked about this disconnect between the the domain world and this world of tables and I think that a lot of us we don't see this disconnect anymore because we're really deep into this entire world of SQL statements and Stuff like that But you have to think about that someone in your team has to translate between those worlds and either this is your developer Who does this in his or her head? but someone has to do the translation and in a translation always it's always the case that information gets lost So I think it's important that we see this disconnect and be aware of it And in the case of a multi-model Database this disconnect is much smaller because this is much closer to the thing that we could draw on our piece of paper When we talk to our domain expert or product owner or our customer because this is basically what they would draw if you would ask them Hey, could you like say that Alice owns this spaceship? so the procedure I suggest is First explain graphs to this person like the domain expert or product owner and Say like this is how you draw a graph and this won't take long like I've done this multiple times And it's not a problem. I tried to explain joins and I did not succeed so well so This is a very short task and then there's a very long task and this is learning about the domain So you talk up with a domain expert and ask Ask this person Yeah, what what is this? What is this problem about where what words exist in this in this world? and from that you can then build a common language and you can draw on a piece of paper the graphs that belong to this language and to this problem and Then you have a shared understanding and this is extremely important because Now you build one model that everyone in the team understands like every single person in the in the in your Company understands the same thing and if you read the excellent book the design of everyday things This is also very cool because if a customer comes to this website you have built and all of you had the same model in their head Then this model will also reflect in your product and it will also get into the head of your customer So it will be extremely nice for usability and user experience so One important thing because it sounds like big design upfront. You have to evolve this model Don't just draw a piece of paper and this is like the absolute truth You have to evolve it. This is the reason why iterative development is one of the like basis of this methodology So thank you for listening. I'm moon gloom on github and moonbin labs on Twitter And if you want to check out a multimodal database go to a rango db.org Thank you