Search
Talks
Domain Driven Design & NoSQL
Edit
Summarized using AI

Domain Driven Design & NoSQL

Lucas Dohmen • June 26, 2014 • Singapore • Talk

In the presentation titled "Domain Driven Design & NoSQL", Lucas Dohmen discusses the integration of Domain Driven Design (DDD) with NoSQL databases to enhance software applications. The talk emphasizes the importance of establishing a common language among project stakeholders to ensure effective communication. DDD, introduced by Eric Evans, advocates for a shared language that aligns with the project’s domain rather than technical jargon, aiming to bridge the gap between developers, domain experts, and other stakeholders.

Key Points Discussed:
- Communication Barriers: Dohmen highlights the issue of differing terminologies (e.g., 'tables' versus 'classes') that can lead to misunderstandings among project members. The story of the Tower of Babel serves as an allegory for these communication challenges.
- Core Concepts of DDD: The two main foundations of DDD are iterative development and a close relationship between developers and domain experts. Effective communication is essential for developing a shared language.
- Understanding NoSQL: Although the term NoSQL typically suggests non-relational databases, its meaning is diverse. Dohmen humorously illustrates the confusion surrounding NoSQL with anecdotal definitions.
- Domain Objects: He describes core domain object types—entities, value objects, services, repositories, and aggregates—that form the foundation of DDD. Fake examples portray how these objects would behave in a typical application.
- Disconnect Between Domain and Database: The traditional relational database model creates a disconnect between the domain language and database tables. Dohmen discusses how NoSQL databases, particularly document stores, allow for a more natural representation of domain relationships.
- Graph Databases: He further explains how graph databases enable modeling relationships directly, which can be more intuitive than traditional SQL joins.
- Multi-Model Databases: Dohmen advocates for multi-model databases that combine the best features of document and graph databases, allowing for optimal problem modeling.
- Evolving the Model: The speaker stresses the need for continuous evolution of the domain model rather than a static approach, encouraging ongoing communication within teams.

The takeaway from the session is the significant reduction of the disconnect between domain language and database design when combining DDD with NoSQL and multi-model databases. A shared understanding fosters better usability and user experience in the final product, reflecting the collective knowledge and agreement among project members.

Domain Driven Design & NoSQL
Lucas Dohmen • June 26, 2014 • Singapore • Talk

Domain Driven Design is a software development process that focuses on the finding a common language for the involved parties. This language and the resulting models are taken from the domain rather than the technical details of the implementation. The goal is to improve the communication between customers, developers and all other involved groups. Even if Eric Evan's book about this topic was written almost ten years ago, this topic remains important because a lot of projects fail for communication reasons.

Relational databases have their own language and influence the design of software into a direction further away from the Domain: Entities have to be created for the sole purpose of adhering to best practices of relational database. Two kinds of NoSQL databases are changing that: Document stores and graph databases. In a document store you can model a contains relation in a more natural way and thereby express if this entity can exist outside of its surrounding entity. A graph database allows you to model relationships between entities in a straight forward way that can be expressed in the language of the domain.

I want to look at the way a multi model database that combines a document store and a graph database can help you model your problems in a way that is understandable for all parties involved.

Help us caption & translate this video!

http://amara.org/v/FGYY/

Red Dot Ruby Conference 2014

00:00:19.829 so hello everyone today I want to talk
00:00:24.189 about two main topics the first one is
00:00:27.550 no SQL a second one is domain driven
00:00:29.710 design and then I want to bring those
00:00:32.290 two concepts together and explain how I
00:00:34.780 think they can enhance your applications
00:00:38.079 and make them better so there's this
00:00:41.260 story about building the Tower of Babel
00:00:43.510 in in this story in the beginning they
00:00:47.109 all spoke the same language and they
00:00:49.870 build a really impressive Tower like
00:00:51.609 look at this tower it's really
00:00:53.320 impressive but they got really braggy
00:00:57.039 because if people build something very
00:00:58.719 impressive they will get braggy so they
00:01:01.359 were punished and the language was taken
00:01:02.980 away and then the tower never got
00:01:05.410 finished so in our projects we often
00:01:11.740 don't start with the same language we
00:01:13.690 maybe start with the same human language
00:01:15.370 so even if not all the people involved
00:01:17.830 in the project have the same native
00:01:19.660 tongue they will probably switch to
00:01:21.550 English or something but we all speak a
00:01:24.070 different jargon so you may have someone
00:01:26.800 in your project who's like dealing with
00:01:29.080 data bases for example and this person
00:01:31.330 uses words like tables for example and
00:01:34.390 then you have a programmer and she will
00:01:36.220 probably talk about classes and about
00:01:38.290 variables and stuff like that and even
00:01:42.850 those two worlds are not very close
00:01:44.950 together and then we haven't domain
00:01:47.920 expert in our example because space is
00:01:50.680 awesome we choose space shuttles and
00:01:53.710 astronauts so this person really knows a
00:01:56.200 lot about space shuttles and astronauts
00:01:58.470 so this person if someone tells them
00:02:01.870 there are tables going on then this
00:02:04.810 person probably doesn't know what this
00:02:07.540 means
00:02:08.019 even though they are very familiar with
00:02:09.369 the application so Eric
00:02:12.350 came up with this idea of domain-driven
00:02:14.240 design so he wrote a really good book
00:02:15.980 about it
00:02:17.090 and he says that his main goal is that
00:02:20.390 everyone finds in the Brigadier's
00:02:21.590 language that means that this language
00:02:23.660 is understood by every single person
00:02:25.460 involved in the project no matter what
00:02:27.260 their role is if they are a programmer a
00:02:30.740 domain expert or yeah database person in
00:02:41.810 this language and a lot of projects I
00:02:44.930 see that people try to evolve this
00:02:47.060 language from the programming stuff but
00:02:51.100 Eric Evans suggests that you take the
00:02:54.320 domain language because this is the
00:02:56.750 problem you are trying to solve and
00:02:58.550 therefore it should be at the core of
00:03:00.440 your discussions so domain driven design
00:03:05.540 has two building blocks it is filled on
00:03:09.800 so without them you can't do it
00:03:11.660 the first one is iterative development I
00:03:13.880 won't talk about that too much because
00:03:15.380 most of us know that and probably do
00:03:17.480 that if you have questions about that
00:03:18.830 come to me later so I will skip over
00:03:21.410 that the other important thing is that
00:03:24.440 you have a close relationship between
00:03:25.820 your developers and your domain experts
00:03:27.860 because if you want to develop a
00:03:29.450 language that everyone understands then
00:03:31.220 you have to talk to each other
00:03:32.330 if you don't talk to each other then you
00:03:34.520 can't develop a language so hi my name
00:03:39.200 is Lucas I don't come from a place with
00:03:41.420 such beautiful beaches I come from a
00:03:44.180 cold place called Germany and in
00:03:47.450 particular I come from City you know as
00:03:49.490 cologne and there's a big myth going on
00:03:53.090 about German people and about our
00:03:55.250 language that our languages of like
00:03:57.290 build from very long words and actually
00:03:59.780 that's the lie so kerlun is how we'd
00:04:02.750 call Cologne in Germany and as you see
00:04:05.480 it's much shorter than Cologne so this
00:04:08.090 is an obvious lie if you take one thing
00:04:11.000 away from this talk please let it be
00:04:13.130 this
00:04:15.340 so as a second example in the background
00:04:19.280 you see this quite impress the
00:04:20.660 impressive church and in German it's
00:04:24.979 called a dome and in English it's called
00:04:27.110 a cathedral so you see this is all a big
00:04:29.750 lie but I don't want to lie to you so
00:04:32.990 this bridge you see on the right side
00:04:35.030 it's a whole and so on twerker so maybe
00:04:39.139 there's some truth in that okay so I
00:04:43.639 work for a company called a Dunwoody
00:04:45.410 begin B huh
00:04:46.250 which means like our angle to be inked
00:04:48.530 maybe so we work on something called
00:04:52.699 angle D B and angle D beam is an OS no
00:04:55.970 SQL database which is open source it's
00:04:58.010 on github and it's a lot of fun working
00:05:00.530 on an open source project for money so
00:05:04.000 one question that this raises is what is
00:05:07.070 no SQL and I think a lot of people
00:05:09.560 understand different things when they
00:05:10.910 hear the word no SQL so I want to yeah
00:05:14.300 first confuse here a little bit more and
00:05:15.830 then try to explain what I think no SQL
00:05:17.930 means so if you look at this there is
00:05:20.539 something called SQL and then everything
00:05:23.060 that's not SQL is obviously no SQL right
00:05:25.849 so if you have a chair a chair is
00:05:29.479 definitely no SQL maybe it can even
00:05:32.630 scale so and people try to confuse you
00:05:37.849 even more so they say the no doesn't
00:05:40.430 mean no because it would be too obvious
00:05:42.229 so it means now not only so this makes
00:05:45.949 it even more confusing because now even
00:05:47.750 parts of this SQL thing are part of SQL
00:05:50.599 not know SQL so yeah nobody really knows
00:05:54.440 what is going on anymore but let's try
00:05:56.930 to analyze what what this means so what
00:06:01.159 is noise Carol it's not SQL obviously
00:06:03.650 like this is probably the only thing we
00:06:05.479 can say about it and this is not even
00:06:07.070 true anymore
00:06:08.150 so the question is what is SQL and SQL
00:06:11.690 is a relational algebra and this raises
00:06:14.389 the question what is in a relational
00:06:16.460 algebra and it's obviously in algebra
00:06:18.470 relations so what what is a relation so
00:06:24.039 this is a relation
00:06:26.910 a set of tuples so in this case we have
00:06:30.390 two tuples one is Ellis some date and a
00:06:33.300 number and the other one is Bob some
00:06:35.520 date and a number and we can't really
00:06:38.130 say what this means fact because what is
00:06:40.620 this number at the end this second one
00:06:42.750 could be a birth date it could be
00:06:45.210 anything but what is this number we
00:06:47.850 don't know so we came up with a quite
00:06:50.490 good idea on how to represent this in a
00:06:53.220 more natural way and this is the table
00:06:55.170 so you can give it a header line and you
00:06:58.650 can explain what those things mean so in
00:07:01.620 the case of name and birthday this is
00:07:03.480 quite clear so the name is the name in
00:07:05.400 the birthday it's the birthday but why
00:07:06.930 in the hell is the city a number because
00:07:09.930 cities normally are like words like Kern
00:07:15.080 so this is a topic called joints which
00:07:20.370 we will get to in a in a few minutes but
00:07:23.430 first let's say okay we represent those
00:07:26.460 as tables because we also like adopted
00:07:29.790 that into our language if we talk about
00:07:31.740 our that database we talk about tables
00:07:34.740 and we drop tables and stuff like that
00:07:37.050 we even flip tables so we have one
00:07:41.040 problem and this is a huge disconnect we
00:07:44.070 have a domain world and in this domain
00:07:46.950 world we say that Alice owns a spaceship
00:07:49.620 right so this might be a diagram that
00:07:53.250 someone draws that that wants to explain
00:07:55.680 to you what this explain that what the
00:07:57.780 domain is about like they would say like
00:07:59.370 here this is Ellis and this is a
00:08:01.230 spaceship and they are they are like
00:08:02.930 connected to each other and we draw it
00:08:05.370 with an arrow and then there is this
00:08:07.800 database person and says of course then
00:08:10.169 I will have three tables and every
00:08:13.169 person that doesn't know anything about
00:08:15.720 SQL will probably now be confused and
00:08:19.200 this is the disconnect this talk is
00:08:21.570 about so but let's first dive into this
00:08:25.350 left side into this domain side so Eric
00:08:28.830 Evans sees six main types of domain
00:08:32.610 objects and the first one is an entity
00:08:35.280 and that entity has this identified by
00:08:38.160 an identity
00:08:39.520 so it yeah it is something so it yeah it
00:08:44.650 if you change something about it it will
00:08:47.140 still still be the same thing a good
00:08:49.660 example for that is a person so if a
00:08:51.730 person gets married and change its it
00:08:53.830 changes his or her last name then it
00:08:56.350 will still be the same person at least
00:08:58.540 in the database and therefore we have to
00:09:02.350 make this state mutable and this is
00:09:06.730 different for a value of object because
00:09:08.770 a value object is only identified by its
00:09:10.930 value so for example a street is a value
00:09:14.680 object a street has a street number and
00:09:18.040 a house number street number I think and
00:09:22.500 if you change something about those two
00:09:25.030 things then they are not the same thing
00:09:27.790 anymore so they are immutable as soon as
00:09:30.670 you change it it's not the same thing
00:09:31.930 anymore and this is quite important and
00:09:35.920 then we have services and services are
00:09:37.990 things that do things and they are just
00:09:40.630 identified by what they do so for
00:09:42.340 example a service that sends mail to
00:09:44.890 people would be identified by it sends
00:09:47.530 mail to people and it's hopefully
00:09:51.460 stateless I see a lot of services that
00:09:53.410 are not but hopefully they are so if you
00:09:55.630 do the same thing twice with a service
00:09:57.580 it should produce the same output twice
00:10:00.780 ok and then there are three more I will
00:10:03.940 skip over them a little like we have
00:10:06.190 factories in Ruby we call them builders
00:10:08.500 because Java is probably but we still
00:10:12.790 have them so there's something that
00:10:15.120 produces other domain objects then we
00:10:19.780 have a repository and a repository is
00:10:22.240 basically a thing that stores other
00:10:24.670 things so you can imagine it as in a big
00:10:27.700 array for example you can add things
00:10:30.310 remove things search for things and
00:10:32.470 stuff like that
00:10:34.300 and the important thing is because we
00:10:36.430 are talking about the domain we are not
00:10:38.290 talking about how this is implemented at
00:10:40.240 all we just say like you can put
00:10:42.310 astronauts into this repository how it
00:10:44.890 is implemented is not relevant and in a
00:10:47.980 lot of cases it is implemented by by
00:10:51.940 being backed
00:10:52.720 database and then we have aggregates and
00:10:55.680 aggregates are a connection of a domain
00:10:59.199 model plus one or more entities so for
00:11:02.680 example a person with the address they
00:11:04.480 live in and aggregates are yeah give no
00:11:12.040 Eric Evans has suggests us to do
00:11:15.339 something special with aggregates and
00:11:18.089 this is denormalization and this is
00:11:21.819 possible because those value objects you
00:11:24.550 connect your object with are immutable
00:11:27.339 so you can copy them as many times as
00:11:29.920 you want because if one of them changes
00:11:33.279 you don't have to change all of them
00:11:34.629 that have the same value because if some
00:11:36.519 person moves to another another house
00:11:39.009 then not all people that live in this
00:11:41.410 house change switch their houses to not
00:11:44.949 necessarily at least so we can do
00:11:47.110 normalize this stuff and in SQL this is
00:11:51.009 kind of an anti-pattern and the reason
00:11:54.339 for that is that we cannot put the
00:11:57.399 tuples into tuples in an SQL database so
00:12:01.569 the idea that some people had was let us
00:12:04.569 let's lift those restrictions let's say
00:12:06.490 like okay now we can put tuples into
00:12:09.699 tuples also let's allow to 'pls with
00:12:12.879 arbitrary attributes where you can just
00:12:14.889 say like okay this person has a name and
00:12:16.660 this person doesn't have a name which
00:12:18.490 makes a lot of sense so in this world we
00:12:24.519 can now put our value objects into our
00:12:27.730 domain one objects we call this
00:12:29.889 embedding so if we have a space shuttle
00:12:32.170 and the space shuttle has some parts
00:12:34.029 then we can't just embed those parts in
00:12:36.939 the space shuttle and if your database
00:12:39.879 is able to do this kind of thing that is
00:12:42.790 probably a document store so this is one
00:12:45.129 kind of a no SQL database so it's a
00:12:48.309 place where you can every document has
00:12:50.829 its own structure and this structure can
00:12:52.839 even be nested so in our example we now
00:12:57.129 would have three documents we had we
00:12:59.589 would have Alice and the Space Shuttle
00:13:01.300 and we would have a third
00:13:03.610 serious document which has something to
00:13:06.880 IDs in it which is like the join
00:13:09.519 document basically and this is again
00:13:14.079 like it's closer to what we explain to
00:13:16.720 people because we don't have this most
00:13:18.519 mysterious tables going on but we still
00:13:20.410 have this problem of connecting to
00:13:22.060 things and we have to create something
00:13:24.430 especially for explaining what we are
00:13:27.519 what we want to do here also joins like
00:13:32.709 I I heard a lot of about joints in one
00:13:35.589 talk today and I kind of like like a
00:13:37.420 flashback because in a past life I did a
00:13:40.329 lot of SQL joints I did like social
00:13:44.079 network analysis at University and I did
00:13:47.320 a lot of joints a lot of joints and a
00:13:49.600 lot of them were recursive joints and if
00:13:51.459 you don't know what that means don't
00:13:52.660 look it up it it's bad don't do it so we
00:13:57.519 had this long SQL queries in our code
00:14:00.810 because yeah we had didn't have
00:14:03.250 something cool like Aero
00:14:04.329 it was just like long strings like build
00:14:08.500 together and they had comments beneath
00:14:11.110 them and they were all like I have no
00:14:13.240 idea what's going on here like every
00:14:15.010 single one so joints can get really bad
00:14:18.640 really quick like in the beginning they
00:14:20.320 seem like really fluffy and nice but as
00:14:22.839 soon as they get bigger they are kind of
00:14:25.180 scary so there's a different way to
00:14:29.820 model relationships between things and
00:14:32.470 this is a graph so we have Ellis and as
00:14:36.880 the person that drew the domain before
00:14:39.519 we would draw like an arrow between
00:14:41.949 those two things there's an ownership
00:14:43.360 between those things so Ellis owns the
00:14:45.820 spaceship this is the way we would draw
00:14:47.589 that and if you can do that kind of
00:14:50.410 thing in your database then it's
00:14:52.209 probably a graph database there are a
00:14:54.220 lot of different definitions of graph
00:14:56.140 databases I don't want to get into those
00:14:58.649 I think the mate of the most important
00:15:02.079 thing is you have some way of storing
00:15:04.540 grass in your database and you have some
00:15:06.339 way of naturally currying those graphs
00:15:09.300 more is up to discussion I guess
00:15:13.450 so in this in this graph database we
00:15:16.630 could now express this for this arrow
00:15:19.060 directly so then there is this we had we
00:15:23.650 had this special that had consists of
00:15:27.460 parts and we have this relationship now
00:15:30.640 it would be nice if we could combine
00:15:32.050 those two kinds of things and the idea
00:15:35.050 behind the idea on how to do that is
00:15:37.360 simple we just say that Alice and the
00:15:39.880 Space Shuttle are both documents and and
00:15:42.790 those myth with those documents we can
00:15:45.010 do all those things that I described
00:15:46.630 before like embedding stuff and the
00:15:49.600 second trick is that the edges between
00:15:51.610 them are also documents so again we can
00:15:56.050 do all those things that I just talked
00:15:58.210 about so for example if we would want to
00:16:01.210 say that Ellis owns the spaceship since
00:16:04.110 1978 for example then we could put that
00:16:07.390 into the edge because it's a natural way
00:16:09.070 of expressing that and if we want to
00:16:11.560 know all outgoing edges that have that
00:16:15.130 have been there since 1978 we know which
00:16:17.920 spaceships she owned from that period on
00:16:21.030 so if your database can do that then it
00:16:24.820 is a multi-modal database it's called
00:16:27.430 it's called like that because it
00:16:29.110 combines two models of database into one
00:16:32.380 database you could also combine
00:16:34.300 different database together but most
00:16:36.550 multi model databases put those two
00:16:38.290 things together maybe also key value at
00:16:40.540 the store which I won't get into so I
00:16:43.800 talked about this disconnect between the
00:16:46.510 the domain world in this world of tables
00:16:49.120 and I think that a lot of us we don't
00:16:53.530 see this disconnect anymore because
00:16:55.000 we're really deep into this entire world
00:16:57.700 of SQL statements and stuff like that
00:17:00.970 but you have to think about that someone
00:17:03.580 in your team has to translate between
00:17:05.350 those worlds and either this is your
00:17:07.420 developer who does this in his or her
00:17:10.210 head but someone has to do the
00:17:12.370 translation and in a translation always
00:17:15.520 it's always the case that information
00:17:17.830 gets lost so I think it's important that
00:17:21.520 we see this disconnect
00:17:22.940 and be aware of it in the case of a
00:17:25.850 multi model database this disconnect is
00:17:28.880 much smaller because this is much closer
00:17:31.130 to the thing that we could draw on our
00:17:33.140 piece of paper when we talk to our
00:17:34.790 domain expert or product owner or our
00:17:36.980 customer because this is basically what
00:17:39.740 they would draw if you would ask them
00:17:41.210 hey could you like say that Ellis owns
00:17:44.180 this spaceship so the procedure I
00:17:48.980 suggest is first explain graphs to this
00:17:53.060 person like the domain expert or product
00:17:54.980 owner and say like this is how are you
00:17:57.590 draw a graph and this won't take long
00:17:59.660 like I've done this multiple times and
00:18:01.220 it's not a problem I try to explain
00:18:03.080 joints and it did not succeed but so
00:18:05.270 well um so this is a very short task and
00:18:09.860 then there's a very long time and this
00:18:11.810 is learning about the domain so you talk
00:18:13.490 about with a domain expert and ask you
00:18:15.680 ask this person yeah what what is this
00:18:19.580 what is this problem about where what
00:18:21.650 words exist in this in this world and
00:18:24.980 from that you can then build a common
00:18:26.900 language and you can draw on a piece of
00:18:30.140 paper or the graphs that belong to this
00:18:32.090 language into this problem and then you
00:18:35.420 have a shared understanding and this is
00:18:38.300 extremely important because now you
00:18:41.180 build one model that everyone in the
00:18:42.980 team understands like every single
00:18:45.440 person in the in the in your development
00:18:48.230 group in your and your company
00:18:49.660 understands the same thing and if you
00:18:52.430 read the excellent book the design of
00:18:54.410 everyday things this is also very cool
00:18:57.560 because if a customer comes to this
00:18:59.690 website you have build and all of you
00:19:02.270 had the same model in their hand then
00:19:04.520 this model will also reflect in your
00:19:06.170 product and it will also get into the
00:19:08.150 head of your customer so it will be
00:19:10.430 extremely nice for usability and user
00:19:12.320 experience so one important thing
00:19:17.450 because it sounds like big design up
00:19:19.310 front you have to evolve this model
00:19:21.680 don't just draw a piece of paper and
00:19:23.750 this is like the absolute truth you have
00:19:26.960 to evolve it this is the reason why it's
00:19:29.030 relative development is one of the like
00:19:31.700 basis of this methodology
00:19:35.640 so thank you for listening I'm moon
00:19:38.760 bloom on github and Moonbeam labs on
00:19:40.710 Twitter and if you want to check out a
00:19:43.020 multi model database go to Arango DB doc
00:19:45.920 thank you
00:19:55.860 you
LD
Lucas Dohmen
1 talk
Explore all talks recorded at Red Dot Ruby Conference 2014
+20