Eric Evans — Tackling Complexity in the Heart of Software

dr. with the subtitle of my book because to me that was the point of the book
domain-driven design then is a term to capture this particular approach the way
of dealing with this
the way of doing this important thing of course this presumes that you know ye
that you can find that heart of software which i think is the domain that we're
working on is where the complexity is and I think that that generally you know
that there that is often true but often I'm asked like well what exactly is
domain-driven design i mean it is a hard thing to define kind of it and I
understand why people sometimes are concerned like doesn't seem like you've
given us a really sharp definition and I mean on the one hand i say look there's
basically these few things that the point of domain driven design or rather
the the principles of domain driven design is that we would find that core
complexity in a critical part of our domain and we will focus on that not
focus on the technical platform but on the domain and in particular on
high-value difficult parts in that domain and then in particular how do we
deal with that complexity in those high value complex parts
what we develop models of them but we don't just say okay this is the design
phase or whatever and we're going to make a model and it's going to be this
nice big UML diagram and now it's time to program
it's an integral part of the whole process of development and it goes on
and on
so that's why i always say exploring models furthermore we explore models in
a in a particular engagement with business people or with domain experts
is assuming it's a business domain and that would be actual business people in
other words this modeling is something that business people and software
experts do together
we don't say to the business people you're the ones who know the business so
give us a model which some people have proposed and we don't say what we are
the ones responsible for the software so will develop the model which is what
happens
by default most of the time we say this is really something that if it's going
to come out well it needs to be done together and then there's this point
that the software should express that model that a model that is just a
diagram we draw on the board or even a wonderful discussion we had with our
business people that if we come up with these nice sharp concepts and so forth
the guide and then we do nothing with it nothing tangible in the software then it
really hasn't done as much good night maybe it's of some value but in domain
driven design
there's this principle that the software should explicitly reflect that model and
then that leads to the ubiquitous language
how does it reflect that model anyway well the structures in the model the
structures that the model suggests should show up in the software of course
but the words the language a lot of domain driven design the philosophy of
it revolves around how integral language is to the way that we do these things so
that in the end all this collaboration exploration
and even the programming the thread you can see running through it is the
evolution of this language for talking about the domain problems in an
increasingly precise and expressive way to the point where you can write code
that really says that's like just a reads like an expression of this is the
solution we have chosen for our problem now ubiquitous means every where and
when I say ubiquitous then I mean when I'm talking to a business person or when
I'm talking to another technical person or when I'm programming the computer
when i'm writing a document but it doesn't mean everywhere without
throughout the system and so I have to say ubiquitous language within a bounded
context a bounded context is a recognition that language doesn't mean
anything in general all the things I'm saying only makes sense to it if they do
make any sense to you but they only make sense to you because of the context in
which i'm saying them you know the things I've said before you know the
things in Mathias is introduction and other information that you bring to bear
to say okay that's what this word means now that's what this phrase means now
but it didn't just mean that if you had just seen the sentence i am saying now
on a billboard driving to this place
you wouldn't have known what it meant so when you're reading code in a computer
program the same is true
you can't just look at one line of code and know what it means know what it will
do you have to usually read quite a bit of code that comes in other parts of the
program the code that comes before it in the particular process it in
the code that is referenced by any kind of dependency in that code
so in order to understand a line of code you have to know all these things
bounded context says we're not going to rely on this kind of well just figure it
out as I go along i'll look up
you know every line of code and then every reference it makes and then by the
time i get to that line all know what it means what it will do
we're saying we will define some concepts and within the boundary that we
have specified
this will be very consistent meaning and that we will have some rules and within
that boundary those rules will apply very consistently and rigorously and you
say well of course that's just what
modeling is all about what good design is all about
but the thing is without the boundary it doesn't work it doesn't even make sense
if I you know to take an extremely simple example if I said there's a
number X and a number Y and X will always be less than Y and now you see
some calculation in my program and it is y minus x then you know that that will
be a positive number because X is always less than why i said so
and now you go and you look at another computer program and you see y minus x
you see that actual text somewhere in the program is it a positive number
maybe maybe not maybe it's not even a number
you simply do not know and you cannot know there is no meaning two expressions
outside of a given context so domain-driven design tries to
acknowledge that and use that to our benefit
use it in several ways one of which is simply to say if we really want this to
work
then we need that boundary I need to be able to draw a boundary around me so
that i can do all the cool stuff that I want to do inside that boundary the
boundary has to be tangible it's a real piece of software or markers within the
software and that's the first and most basic way in which it's important to
domain driven design another way it's important to domain driven design is to
say we are going to have just one model but probably several models because we
have a big sprawling domain that has many problems
multiple complex important problems and we want to address them differently so
just is
we have many tools for every kind of work we do we have many models to
address specific domain
a third way in which is important is that most projects of any size have
multiple teams and different teams cannot coordinate is tightly around
I mean to accomplish the kind of clarity and consistency that I was talking about
earlier
you need a very well coordinated team to do that two teams each can coordinate
within themselves but they can't coordinate as well with each other and
so they can accomplish that kind of consistency between them while they can
or in one particular way they can do it by freezing the model in place by
deciding in advance what the rules are and then not breaking them
but if you want to be able to make strict rules and then adjust and evolve
them quickly in response to new insights
then you need to be able to do that within a team
so the fact that we usually have multiple teams working is another reason
that we need bounded context anyway
so that's basically the gist of domain driven design and now I know that
even so I think what I said probably doesn't sound like a very I don't know
it's it it's not a reductionist kind of an attitude
I think you know I i think i've given up on trying to have that very crisp little
definition of domain driven design
it's kind of a it's kind of a gestalt that after a while it is sort of a way
that you look at every problem
no not every problem of course but the sorts of problems they dress as well
like complex domains where you want to write software and it gives some
guidance and then of course there are some concrete techniques that we tend to
use but those are more flexible more fluid at this conference will see people
presenting about different ways of doing some of those things and so as I say I
don't know if I can really define it in that sort of way
and of course one important thing about it gives us some terminology some ways
of talking about some of the important things were doing
you know if we don't exactly agree on that technique that we are applying to
it
so for example to have the word bounded context to describe and say I think that
the boundary of this context has some problems and that actually means
something to the other person that's one of the valuable
now why you say that 12 years after my book was published
we're actually still talking about domain driven design and not only is
still talking about it but actually in some ways
amping up the conversation because this is as you said the first the first real
conference of our own
and how is that i don't know i mean it's kind of a surprise to me
the truly but I mean a very pleasant one
but i think one reason
one possibility anyway involves technology and that that's kind of funny
think say after making the point that the first point of domain driven design
was to focus on the core complexity in the heart of the domain and so on and
that we emphasize those domain problems in not the technical ones and not the
technology and so on and it's true the domain driven design isn't about
technology and in fact I mean part of what made me write it was a bit of a
response to what i saw around me that all the best software designers were
always focused toward the technical aspects of the software and it was like
we just left the b-team people the that is the the less talented people to work
on the actual business problem it was even considered it was certainly
considered less prestigious maybe it still is but I thought that was missing
the whole point
but even though i think that domain driven design is not about technology
that doesn't mean that we are indifferent to the technology the
technology is very important I think the best domain-driven design practitioners
are actually masters of the technology
it's like if a if you said well i'm a master carpenter and I like to make
furniture
handcrafted furniture and that mean let's say I i particularly like to make
like artistic tables and so you would say that that person was a master of
using hammers and saws and chisels and all of these things I'm sure but if you
asked him what is what you do about you wouldn't tell it's all about the songs
the way I used songs and chisels and I know he would say well see this kind of
wood and this kind of you know I like the when the legs are kind of like this
and you would talk about tables all the time and he would be thinking about
tables all the time
what makes that possible in part is because he's mastered the other tools so
thoroughly that he doesn't have to focus on those when i go to do a project
involving something like that
I have to put so much of my attention on just using a saw and not ruining
everything that you know I don't create that kind of a piece of art you have to
master the tool first and then you can actually focus on that thing and so I
think that you know when you when you talk about domain driven design
it's almost as if we've said well yes because we have so mastered the
technology that now we can look at the real problem and bring our tools to bear
so it's no kind of excuse to not be a master of technology and that means we
have to keep up abreast of what's there and what's available and so I started
this saying well why would 12 years later maybe domain-driven design being
more interesting to people than it was when it was written one possibility is
that
there's a combination of better tools and a community better at using those
tools and now they're actually ready to focus on the real problem
and why would I say that they are better tools website room
we like to think that you know time as time goes along our technology gets
better i think in general that's true over long periods of time but let me
think back to two thousand three the books 2004 but of course that means it
was written in 2003 right and reflects the environment at the time it was
written in and I think that was not a good time
from a software technology point of view i started out you know as a professional
programmer i started out in the early nineties and actually that was a good
time
the early nineties at least in the little world that i was in and I i was a
small talk programmer on Wall Street working in an investment bank
I may have been you know it may have been a bit in the service of evil but he
was very interesting and very hit wonderful technology very wonderful
complex problems to dig in you and small talk
you know you probably heard a lot of old guys like me wonder is talking about a
wonderful it was and it was but I I don't want to bring it back or anything
but 2003 wasn't so wonderful
I mean now they don't get me wrong i actually i'm not one of the people who
says I hate jolly just hate job i actually think job is ok
the problem here isn't the java it's the only java right the only language anyone
used in 2003 was job and sometimes c sharp which at that time was just a
dialect of java
and I mean less you know
face it there was hardly any difference back then and java five
you know not picking on that version i'm just saying
actually when you look at java 8 I think it's like a different language them the
old job it's much better but if java 8 were all we had be complaining about
that right
it's we are out of that time when that was there was one language and only one
language but it wasn't really java that I didn't like
as I said j2ee and not to pick on j2ee and particular but all all the
frameworks of the of the era with the heaviest complicated as things you've
ever seen
remember i said we have to attack complexity
those are the critical complexity of the problem which I said is some aspect of
the domain that is really crucial to their success and maybe a big
opportunity or really
yeah but what if you just make the technology itself so complicated that
it's more complex than any part of the business problem you're trying to solve
and that will shift the focus writing quite appropriately
you should apply your attention to the most difficult part of what you're doing
and it's the most difficult part of that is getting some kind of a you know
j2ee container to start then that's where you got to put your best people
now about that time I think people are mostly using spring so i could roll back
to like the year two thousand and things were even worse because II JB's and one
of the things i have hated the most of my old career but by this time
spring had rescued us from that now I know that people these days they talk
about spring so complicated spring so heavy and I get it
I do i I even basically agree but you got to realize
what spring rescues from we should be so grateful for spring spring was the
turning point that's when things started to go the other direction
so no I will always be grateful to them
sequel actually I love relational databases but when you say
all data will be in relational databases then that means you have to squeeze all
data into that shape and that was the reality of 2003 and oh yes the o.r
mapper
I forgot that part because i always try our mappers you know I think the guy i
know the guy think who wrote the very first or mapper brilliant guides
I don't think he intended that this would become the only way of storing
data
I think his poor purpose really was to say well until we have object stores or
some other better way of storing data this will least allow us to move back
and forth between our object sender relational database but we kind of got
stuck stuck with our mappers for 10 years or even 15 years
okay i think the less said about some things the better some things are just
best left in the past but there are a lot of things happening back in the
early two thousands that and the late nineties
another thing that happened in the late nineties was a huge influx of new
programmers because of the dot-com explosion and other things
and the problem was I think that it will on average it was not a very skilled
bunch and that not a very committed bunch i mean people didn't care
the way that before and after
when we were in less heated up periods of time when people came into the world
of software because they were really fascinated by software and wanted to
learn the craft
that probably had an effect two
so let's move to the let's move up to the present
well so can apparently sound doesn't work on this so I'll just skip this part
but you guys probably didn't want to classics like Star Trek anyway
the question would be you know maybe one of the reasons that in 2004 the uptake
of domain driven design was uneven say the least because it was just too hard
the tools were not right for it
look what we're expecting people to do we want them to express a model in code
you know we want them to we want code that reads as if you are reading a
document that explained how you solve the problem
how you think about the problem and how you solve it
that would be the ideal code and yet you're supposed to do that on top of all
that mess that I was just describing even the you know the building blocks
which have been over-emphasised but even those are hard to pull off with that
technology set
you know in DNA it with an o our mapper and so forth
how do you mark off aggregates
it's really hard we say things like you know
define these value objects and make them usable and in the book is sort of talk a
little bit about that but you know it's really hard really hard that kind of
technology to do it and context boundaries i just said that but when
you're running on a monolithic server application where everything max into
the same database
how do you do that how you actually say yeah this is the this is the realm of
the software in which i can make assertions that I'm very confident of
about the definitions of things
the constraints between the things
now you you know it can be done I did it some I was involved with teams that did
it
sometimes and I saw other people do it but it's very hard maybe too hard
so you know I think that if you took that master carpenter and you said well
here is a stone hand axe made by a early crow Mannion
and you said now make your beautiful artistic table maybe maybe you wouldn't
get the same result so maybe that's the situation
now the question would be things have changed
right the no sequel movement comes along and suddenly we have all these different
kinds of databases you kind of hopefully have a database that fits the data they
are working with better and we have vast quantities of memory to work with so
they for a lot of kinds of problems instead of saying well i'm going to take
the object from store and do something and put it back and over and over
I'm saying well a lot of the really intricate parts the complex parts that I
want to work on
I could bring data and I could transform it into a structure that i'll just let
live in memory any kind of interesting results i can write out to the store and
I don't really have to worry about that part you know the that lifts a big
constraint and you know then we have sort of new ideas come along about
well maybe we should just structure our whole model and
designed differently anyway things like event sourcing so you could say maybe
maybe things maybe we can do better now
maybe we're ready maybe not you know I mean maybe we're still not there
I don't know but I think I think it seems to me that when I'm working with
tools of 2015
you know now going on 2016 it feels different
feels better more like when I more like 1994 actually strange that sounds but
but better
you know it's as if we have finally recovered from that ear and finally
gotten back on a path and gotten to a place better than anything I've seen
before
could be that the you know it could be i'm still premature or about this but i
don't think so i think we're ready so you know I think
look at the just the intention of the technologies and the frameworks and
stuff that people come out with now they tended to be so much smaller and and
easier to work with it's like they care about it being easy to work with and
express it like they have in there at they're at their framework or library
level they have created a ubiquitous language one of my favorites at the
moment and it serves as a good example of the kind of thing I'm talking about
is the reactive extensions that if you don't know what that is you should
really look it up it's just it's a wonderfully elegant model and it's been
implemented on in
I think it started out in c-sharp not sure I think so because it's in Java its
enclosure it's in everything
now and it's a good example of its deals with two
technical concerns how do you do you know how to tie together these
multi-threaded problems and and yet not not just get overwhelmed and so that you
have to think about that all the time and so we're in this period where we
don't have only this or only that of anything and that's great and I think
that's when you can actually you know people flock toward things generally
speaking though they're flocking towards things that really are rather nice
and then there's a new explosion of variation around that
let me just quickly talk about one thing because since domain-driven design is so
much about models and and there have been a lot of misconceptions about
domain driven design over the year it was a big overemphasis on the building
blocks for example and when you go into something like functional programming or
whatever you're going to have to really rethink those building blocks
but the fundamentals like we are trying to develop a model that's the real fun
you know that's one of those real fundamentals of domain driven design but
if you are but it only works if you're thinking about model in a certain way
you think of model as a way of structuring domain it a the you know
objects an object-oriented programming language and you say well then
DD is very specific to a particular kind of programming environment that's just
not true
even though all the examples nearly all the examples in my book or that way
that's because it was 2003 and we only had one language
so let me just talk a little bit about what i mean by model and some of you
heard me say this to that people often talk about you know maps and use it as
an example of a model and of course that's perfectly appropriate but it's
not quite the kind of model that i am thinking of but it does help
it's something I can use to explain what I mean by model
so here is a map of the world and everyone looks at it and says okay
here's a map of the world and you can look at in learn and in first certain
things like I bet you can infer where this map was made so but in addition to
that you can look and say okay well let's see there's Chyna
there's the United States and they look about the same size and you can look in
the wikipedia and all of it is it yeah they are about the same size
it's okay you can tell how big things are and you can see that you know
Western Europe's bit smaller and to the east and China's to the west and all
that you can look and see
ok africa and green land they look about the same size so i suppose they are i
mean we tested it with the US and China so it must work generally now
and now that we know that green land is the same size as Africa we can continue
ok so what green land is not the same sides Africa turns out and I did look it
up to see how exactly out big with two are actually Africa is 14 times bigger
than agreement 14 times
so why is the map like this
well theory number one bad data the people who made this map just didn't
know how big green man was or Africa this turns out not to be the explanation
their number two since the map was made in the US
but that the the team that made up the map had a couple of immigrants from
Greenland makes that Americans don't know anything about geography if we tell
them the green lens really big they'll make it big on the map and no one will
ever know the difference that turns out not to be the explanation either the
explanation actually turns out to involve a Belgian from the 15 nineties
named Rick powder
I probably mispronounced the name but i'm sure you know who I'm talking about
now at that time navigating was a tricky business you know just figuring out
which direction to go
and they had all kinds of maps and techniques for doing it they're fairly
complicated to use and he figured out a way to make a better map for navigators
and that and that explains why these things are distorted in the way they are
now everyone knows of course that the map is that we have to distort something
to take the surface of the round earth and flatten it out but this one's flat
out in a very particular way there are other ways to flatten out the earth
this is mark Cotton's way this is projection
so the curious thing about this one is that if you draw a straight line between
two places
let's say you drew a line between lisbon in New York and then you look at the
angle of that line on that map you can get a compass setting from that if you
were to stretch a string around the globe and measure the angle of that
string on the globe
it would be the same angle as the one you get on the map so that as them as
the surface of the round earth is flattened onto the map
it's done in a way that makes the directions of things stay the same
no matter what else has to be distorted the directions of things stay the same
that's what makes the americana maps so valuable or what made it so valuable
you know hundreds of years ago and we use it for other things like teaching
geography and school and so children grow up thinking that green land is
enormous but but that's the reason it wasn't made for them it was made for
navigators
here's another projection
this one doesn't distort the sizes and shapes of things we could use this one
instead
but this one might be confusing to navigators if you were trying to get
from New York to Lisbon for example and you have to go through that white part
so here's the model as i see it
this is mark otters model
the earth is a sphere so we start by saying well this thing there dont the
the domain you know i'm i'm making an abstraction of it and i've taken away
nearly everything that about right
this is not a kind of complete thing i'm not saying everything about Europe then
we're going to say well what data do i want i want the locations of certain
things on the surface
mostly coastlines major port cities may be navigable rivers and I want the I
want to state in a particular form
I probably needed in a spherical coordinate system because this is I've
described the earth is a sphere so that's latitude and longitude a Greek
concept that they that handy for that and then I need to turn it into a flat
piece of paper so i need a little formalism there a mathematical technique
called the projection
now of course McCarter's mathematical techniques for a little different than
what we would use today
I'll just six you know I'm just talking in
modern mathematical terms what he did was but what he did was functionally
equivalent to that and then we have an assertion an assertion that if you apply
this particular projection this particular formula for converting a
sphere to a flat surface that you will be able to say that any direction on the
flat surface is the same as this is the direction on the surface of the sphere
that assertion of course is what makes the thing valuable then this is now and
now how is this different from the map itself because if i take a different
data set and I i apply the same model then let's say we take the data set
available to someone from the 15 nineties then i will get well in this
case this is what i get this is mark otters original model
I mean its original map and although it is doesn't look exactly like a modern
map
it's actually based on the exact same model
it's just the data set that's different so if we zoom in on this is Europe and
the Mediterranean you can see that it actually looks a lot like the modern map
and that's because they had good data for that region but as you go further
afield you get less and less you know the the east coast of the North and
South America
look pretty good there's some mistakes the west coast though of South America
for example
it's a funny thing that details look ok but the whole thing is shifted hundreds
of miles to the east like there's an offset error in the data offset areas on
and then look at the west coast of North America it's like okay
we know there's a West Coast there so they really didn't have much data and
then look down here in the southern areas
say around where we would put Australia and I don't know I don't know what's
going on there some bad data so hopefully this starts to connect with
the kind of things we do we take a sprawling complex domain just an
overwhelming quantity of data and then we have strap that domain in a way that
allows us to focus on some particular important problem particularly important
problem and then apply a model that will transform that data into a form that
really supports thinking about that problem and coming to decisions about it
I mean some models are four different you know some models help you predict
something
some models help you make a decision but and they all evolved
I mean this is a poor Tolan map
it's the kind of map one of the kinds of maps that was available before McCarter
I'm sure it was one of the things that he drew upon as he was figuring out in
those those sort of radiating lines they allow you to know the direction between
two points but specific points
so on this map you can say well from these known points i know the direction
from that known point to that point
mccotter had this brilliant breakthrough in his model where suddenly he could go
from any point to any other . right but it wasn't like it came out of nowhere
so as we are working on these domains it's not like we should feel frustrated
that
oh you know my model doesn't have the elegance of the ricotta projection
now it's like you you take steps
this was a tremendously valuable map in its time one of the distractions though
I mean you know I wasn't talking about what do I mean by model
I'm not talking about trying to see the reality of the business or anything that
i think is actually a distraction
it's this off on the wrong track -
for example is this a realistic image of the world
I mean I don't think that green land is almost the size of Africa so that you
could say is is unrealistic
we could fix that we could make green land smaller and probably that wouldn't
cause too much trouble because how many how much how often do navigators go to
green line but we would make you have to make our assertion slightly different
now the assertion is that any to the angle between any two points on this map
is the same as it would be on the globe and less one of the two points is in
Greenland or we could say well Africa is really too small on this map
so let's enlarge it a little bit make it more realistic but now we have to adjust
the assertion the angle of you know the direction between any two points on the
map is the same as on the sphere
unless one end of it is in Africa and the other end out or one end is in
agreement and the other end out and by the way doesn't that start to sound a
little bit like code
so that's how we end up there is this more realistic than the recorder map
I mean it shows green land and African their true size
I mean the relative size on the other hand it doesn't give you a sense of the
connected
geography of the world the same way that the mark on our map does
you know you can't really relate for example you know South America and
Africa look as if they're on the opposite ends of the world
I don't think it's more or less realistic
I think that's the wrong question to ask you want realistic there is realistic
well is a projection - but it's you know what i mean by realistic i guess what
i'm getting at here is that realism doesn't have much to do with what we're
doing we're writing software
we're trying to solve problems we need models that are focused specifically on
those problems and a narrow focus when you lose the narrow focus then you get
this
this is something I found on the web somewhere by googling for model so
we need to remember keep remembering where folk we need to find a focus on a
specific problem on a specific reasonably complex problem is if it's
not complex why are you doing all this and an important problem because it's
not important why are you doing this
and then we apply all those tools and and and so when I say hey you know we
don't want a realistic model we want a useful model that sounds like oh yeah
you know and I want to be good but I don't mean it that way that mean to say
look usefulness isn't like good usefulness is specific
you can't say that something is useful or not in general you know is a is a
hammer useful
well not if you want to cut a board into pieces
then maybe I saw is useful is this all useful
well not if I want to pound a nail into a board right so things are useful
relative to some specific problem not in general there's nothing that's generally
useful just what you are going to keep in mind with the models in fact it's
quite easy to find something that is not useful for anything
a lot of you know okay there we go
it's easy to find something that's not useful for anything
actually this might be useful for one thing which is I need to have a kind of
generic schema that i can just shove all our data into as a kind of a repository
of some stuff that we might look up from time to time but if you're actually
trying to do the things that domain driven design is focused on this is not
useful
well as was saying and I want to wrap up with a little optimism because sometimes
I don't sound very optimistic because I talked about how not all of the large
system will be well designed and he talked about all the dysfunction in a
large organization
that is going to make sure that is always true and the intrinsic difficulty
of software development that will ensure that it's always through anyway and so
people say oh it's just silence makes me feel bad
well I don't mean it that way I mean it like let's be realistic not all of the
software will be well designed and so we better focus create a boundary and make
one piece that's well designed an important piece but optimism because i
think there's reason to think that the present and the future are going to be
better than the recent past in a way you could say that we have at this point at
least three maybe more actual modeling paradigms
as I said in 2003 everything was object-oriented if you wanted to do you
know she wanted to use models in software object-oriented was the first
place the first paradigm of programming that took that concept seriously but we
have more now
I mean and by the way I love object oriented programming and I know it's a
little out of vogue right now and i actually find that quite refreshing i
I'm enjoying doing things in different ways fact but this is one of the options
we have now event sourcing i would say after thinking about it for a few years
that it's essentially a different modeling paradigm
it says you know that you will represent things primarily as a sequence of events
and then you will in first or you will a project from those events to create a
view of whatever it is that you're interested them and it eliminates
mutation of data and it it it can be very expressive for certain kinds of
problems but your model takes a different shape
it's not like well okay let's figure out what the model is and now we're going to
program it in whatever language that we choose independently
no the to shape each other you have to create a model that fits the paradigm
that you're going to use to build it
relational relational is a genuine modeling paradigm it was intended to be
that they had you know er models and but we stopped using it for that basically
because it became for a decade or more
just a bad way to store objects and so people have practically forgotten what a
really powerful tool it is if you actually say hey this is a problem where
we have to have compared and manipulate big sets
I'm going to actually just express that in terms of sequel queries and I'll i
will create a schema that is actually tailored to the problems i'm trying to
compute about
that's not the kind of schema people have made for the last 20 years
in my experience they create schemes that are meant to be sort of generalized
places put all of our data that's not what i mean by you know a model and that
not what i mean when i say relational is a paradigm that you can use for domain
driven design
I mean though if you say okay I'm not going to use that schema fine for that
one to exist i'm not using it for this
what I'm going to do is create a schema where we take just the information we
want to apply and structure it in a certain way that allows us to do you
know set operations basically to find our answer
so in that sense I think it's a modeling paradigm and then functional now you
know functional is a big thing
maybe more than one thing and so there are people who have been talking about
modeling in the functional realm and doing very interesting things
the thing is models are just systems of abstraction and so if you have a
powerful mechanism for abstraction
you should be able to implement you should be able to express models
furthermore if you want to you know bring that ubiquitous language life in
the code
well some of the functional languages i think a really nice for making making
language in the code and it might be a good mate with events or Sammy I'm just
sort of laying out like I'm pointing out that we have so many options options
that were really not there and 2003 and graphs graph databases it's more than
just a way to store data store highly connected data that's the way they
described it that's not what I think about when I look at it I think this is
a way to model certain kinds of problems you know and and it's brilliantly clear
you know this is one of those classic kind of modeling paradigm that goes back
long before computers so
anyway and maybe this one will come along but so in a nutshell i would say
that
maybe it's a good time to be taking DVD to the next level a little bit maybe our
tools are ready
maybe there are things to that are pushing us toward toward dance more
concern about design
if you look at the typical you know cloud-based application or or mobile you
it you know tying all these things together it becomes perhaps a bit more
that is you can't get away with some of the sloppiness that you can get away
with
if everything's together on one server and the fact that you will not be
forgiven for sloppiness leads to people thinking about the design and wanting to
have assertions about what will happen for example
so having those pressures you know why does
why is software sometimes been so bad i think one of the reasons is because you
can get away with so much
you know the someone once said that if if you built a bridge the way that
people typically write software that this that it would fall down in the
slightest breeze and yet there are no breezes
so you know it works well kinda but and and also the same for like efficiency
you can kind of get away with a roundabout ways of doing things but the
environment that we're in just at this moment might be less favorable that
might be putting more pressure so that might be another reason that things are
going another way
well basically
that's what I wanted to say i want to say that I feel pretty positive and I
see you know we announced this thing and we thought it might be like a hundred
people or 200 people maybe and then five hundred people showed up and then we had
to stop
I mean so that that was exciting and I hope that you know this this conference
about to happen will fulfill your expectations expectations i think it I
think it will i'm i'm rather excited about some of the things that are
happening i'm gonna go around now see I've done mine so i get to just focus on
other people's talks and the and some of the model with strangers stuff that
sounds fun
so I'm really looking forward to all that
yeah