RedDot Ruby Conf 2014

DDD (Domain Driven Design) y NoSQL

Lucas Dohmen  · 




Extracto de la transcripción automática del vídeo realizada por YouTube.

so hello everyone today I want 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 Tower of Babel in 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 data bases for example

and 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 haven't 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 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 in the Brigadier's 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 a programmer a domain expert or yeah 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 filled

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 City you know as cologne and there's a big myth going on about German people and about our

language that our languages of like build from very long words and actually that's the lie so kerlun is how we'd 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

[ ... ]

Nota: se han omitido las otras 1.649 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.