Download "Is Domain-Driven Design Overrated? • Stefan Tilkov • GOTO 2021"
%3Aformat(webp)%2Fi.ytimg.com%252Fvi%252FZZp9RQEGeqQ%252Fmaxresdefault.jpg&w=1139&q=75)
Please wait. We're preparing links for easy ad-free video watching and downloading.
Table of contents
Audio from this video
Video tags
Subtitles
Russian
00:00:00
[Music]00:00:13
so let's start by talking about my topic00:00:16
the main driven design i think that one00:00:18
reason you you attend this talk or you00:00:20
watch this talk is that you know what00:00:22
that is but in case you don't i'm going00:00:24
to spend a few minutes on explaining my00:00:27
understanding of domain driven design i00:00:29
promise not to make this too long00:00:33
basically what i what i will try to00:00:34
emphasize is what i think00:00:36
the core contributions of the main00:00:38
driven design are as sven said because00:00:41
in fact despite the title i do like the00:00:43
concept i do like the community i do i00:00:45
like many of the members of this00:00:47
community and i like a lot of the00:00:48
contributions00:00:50
so let's talk a bit about what domain00:00:52
driven design actually is00:00:54
so this is my attempt at00:00:58
to me00:00:59
this is an approach to designing00:01:01
software that puts the domain at the00:01:03
center00:01:04
and that seems to be something that00:01:05
should be completely obvious this should00:01:07
be the only way to build software after00:01:09
all why would you build software if00:01:11
you're not building it for the domain00:01:12
it's intended to serve right it seems00:01:14
completely obvious00:01:16
but as you can see i'm an old person00:01:17
i've been in this business for a long00:01:19
time and i have been part of00:01:21
a group of people that loves to play00:01:23
with technology and i've seen lots and00:01:25
lots of projects that were based around00:01:27
a particular technological logical00:01:29
effort around some tool that were00:01:31
motivated more by the interest of people00:01:33
to play with cool stuff as opposed to00:01:36
focusing on the domain so i think that00:01:38
is the core idea in the main driven00:01:40
design00:01:41
and another thing that i consider to be00:01:42
a core part is that00:01:44
what others in other00:01:46
communities consider to be something00:01:49
that should be separate from the00:01:50
software00:01:51
is00:01:52
a core part or is the essential part of00:01:55
the software in the mandatory design00:01:57
namely the model so the idea that the00:01:59
model that you have of your domain00:02:02
actually is the core of the software00:02:04
system that you're building00:02:05
the the the main concepts that you00:02:08
typically express in the model are00:02:09
actually visible within the code that00:02:11
implements that domain logic that's the00:02:14
other key part that those are the two00:02:16
things that i consider very important of00:02:18
course i'll give you the official00:02:20
definition as well this is one from from00:02:22
eric evans's domain driven design00:02:24
reference so eric evans is the author of00:02:26
the original book which came out i think00:02:28
in 2000 something 2003 or so00:02:32
so um in one of the updates to the to00:02:34
the terminology he gave this definition00:02:37
it has a lot a lot in common with with00:02:39
what i just said so focus on the core00:02:41
domain another important aspect to him00:02:43
is the collaboration between domain00:02:45
experts domain practitioners and00:02:47
technology or software practitioners so00:02:50
we should work together and we should00:02:51
have a shared understanding to arrive at00:02:54
this ubiquitous language which is the00:02:56
idea00:02:58
that you have a common set of words that00:03:00
you don't have to translate between the00:03:02
terminology the software people use00:03:03
versus the one the domain people use00:03:06
as a software person should be your goal00:03:08
to capture that language to help the00:03:10
domain experts clear up the language and00:03:12
make it a core part of all of the00:03:14
concepts and components and building00:03:16
blocks that you have within your00:03:17
software system00:03:19
so is that a good thing or not i think00:03:20
this is a completely good thing we00:03:22
probably can all agree that this sounds00:03:24
very good and i i definitely do think it00:03:26
sounds very good00:03:27
when i read the book i had an00:03:29
interesting that was a long time ago as00:03:31
i said when i read the book i had an00:03:32
interesting feeling that i that i've00:03:34
learned to recognize as something good00:03:36
and that feeling is00:03:38
well yeah that seems obvious00:03:40
if you read a book and what's written as00:03:43
seems to00:03:44
seems to be very obvious then that's00:03:46
often the case that somebody took the00:03:48
time to actually00:03:50
write something down in a cohesive00:03:52
a logical fashion that should be common00:03:54
knowledge but often isn't it might be00:03:56
obvious to you it might not be obvious00:03:58
to other people not everything might be00:03:59
obvious to you only parts of it might be00:04:01
and establishing this shared00:04:03
understanding is i think a very good00:04:05
thing i don't think eric evans would00:04:07
claim that he invented tons of new00:04:09
things i don't think he ever did that00:04:10
what he said was he00:04:12
he derived a pattern language he came up00:04:15
with a way talking about things that was00:04:17
to him best practice at that point in00:04:19
time00:04:20
and the key aspects in the book that00:04:22
that you know00:04:24
resonated with me00:04:25
were were three things one was this00:04:28
ubiquitous language that we already00:04:29
talked about i think that's that's an00:04:30
excellent concept it changed many things00:04:32
for me00:04:33
made me made me want to invent new terms00:04:36
less made me want to understand why00:04:39
the main people used the language they00:04:41
used so i think that's a very good thing00:04:44
and it's a very very useful thing to00:04:45
have this agreed upon language00:04:48
the second contribution of the book is00:04:50
one that i'm going to talk about a00:04:51
little bit more slightly later on which00:04:53
is this idea of tactical patterns00:04:56
now if you're building software it00:04:59
doesn't really matter whether you do00:05:00
that in an object oriented fashion or00:05:01
not but00:05:03
especially if you're building object00:05:04
oriented software then you are familiar00:05:06
with certain patterns such as a value00:05:08
object or probably an entity object00:05:11
those things were around before the book00:05:13
came out they're not an invention by by00:05:16
domain driven design00:05:18
but they are a key part of the book they00:05:20
may actually make up a major part of the00:05:22
book00:05:23
and they serve as a set of patterns to00:05:26
help you structure and design your00:05:28
software system00:05:30
so entity object value object service00:05:33
repository factory those were things00:05:35
that were had been there before module00:05:37
as well it was elevated to the same00:05:39
level as a pattern here00:05:41
things like aggregate were a little more00:05:43
i wouldn't say obscure but a little more00:05:45
novel00:05:46
but this was essentially the language if00:05:49
you will that that eric evans came up00:05:51
with in his book and again this was not00:05:53
something that was completely new to me00:05:54
we've been using similar terms in many00:05:56
projects i know that many other people00:05:58
were at the same time so it was00:05:59
um basically giving good names or00:06:02
assembling things with good names that00:06:04
were common use00:06:06
that's a technical view on the whole00:06:08
thing and after the technical part00:06:10
actually there's another quite different00:06:12
part with this which is the strategic00:06:14
part of the main driven design in that00:06:15
book and that's i think also an00:06:17
extremely important to me actually the00:06:19
more important part of domain driven00:06:21
design00:06:22
it also has a number of patterns a00:06:24
number of concepts with names like for00:06:26
example the bounded context which means00:06:29
the key concept here and a number of00:06:31
patterns for the relationships between00:06:33
banner context and the teams that help00:06:35
build the software that implements that00:06:37
context i'm going to explain the term00:06:39
context a little bit more in the next00:06:40
slide00:06:41
but the key idea that i want to want to00:06:43
get across here is that again the book00:06:46
and the and the domain of design concept00:06:48
contains a number of those things which00:06:50
are good and useful things to talk to00:06:53
use when talking about relationships00:06:55
between contexts and teams00:06:58
so what is this bounded context thing00:07:01
that we're talking that i was talking00:07:02
about abandoned context essentially is00:07:05
well a context within a certain part of00:07:08
the ubiquitous language or if you will a00:07:10
certain ubiquitous language holds true00:07:12
so look at this example here if you00:07:14
think of a larger system then very often00:07:16
you end up decomposing it into00:07:19
let's call them modules or subsystems or00:07:22
packages or building blocks00:07:24
within those building blocks things may00:07:26
exist that seem the same as those in00:07:28
other building blocks so in my example00:07:30
here you see a product and a customer in00:07:32
my three different bounded contexts here00:07:34
with an order management and accounting00:07:36
and fulfillment those content concepts00:07:38
exist00:07:39
and they do have a relationship but00:07:41
they're not the same00:07:43
if you consider what a customer is from00:07:45
an accounting perspective that's mostly00:07:47
financial00:07:48
thing it has financial relevance whereas00:07:50
a customer from an order management00:07:52
perspective is more related to you know00:07:54
creating an order and maybe tracking00:07:57
order status and having00:08:00
some kind of i don't know customer00:08:01
information to propose other things for00:08:03
them to order whereas in the fulfillment00:08:05
domain the key thing might be the00:08:06
shipment address and the way they want00:08:08
their package delivered these are just00:08:11
examples right but the point is that00:08:13
within those contexts you uh you get you00:08:16
get a certain level of isolation by00:08:19
agreeing uh what the what the what the00:08:21
domain terminology means within that00:08:23
particular context as opposed to overall00:08:27
which is sort of the uh00:08:28
sort of the the absolute nightmare of00:08:30
every of every person who has to build00:08:33
software in my view which is that00:08:34
somebody went around the company and00:08:36
asked everybody what do you think that a00:08:37
customer is what do you think that00:08:39
customers what do you think and then00:08:40
adding attributes and responsibilities00:08:43
to a god-like customer object that then00:08:45
that some poor soul would then have to00:08:47
implement00:08:48
because trying to come up with one00:08:49
customer that serves everybody's needs00:08:52
is surely going to end up in a disaster00:08:54
so this idea of separating things again00:08:57
was not an invention of domain-driven00:08:59
design but it got a very cool name and a00:09:01
name that stuck this bounded context00:09:03
concept is to me the single most00:09:05
important concept within all the main00:09:07
driven design and the one that i really00:09:08
love to use in lots of places00:09:12
so that all sounds good i hope i hope you00:09:15
don't think that i wanted to you know00:09:17
paint things in battle i didn't want to00:09:19
do that so i think these are all00:09:20
valuable contributions and useful things00:09:23
so let's talk a bit about the problems00:09:25
that i have with some of those things00:09:28
so the first one is that i really value00:09:30
conceptual extensibility00:09:33
i i really like this idea of having a00:09:36
language right so the idea that you have00:09:39
this language that you that you can use00:09:41
to talk to talk to others about certain00:09:43
concepts is a very valuable thing if you00:09:45
can agree under the main language that's00:09:47
really cool00:09:48
but if you consider what the main00:09:50
language is on our level you know on the00:09:52
designer level then there's certain you00:09:54
know00:09:55
a certain way of uh of meta level here00:09:58
right so let's think about this if we00:10:00
generalize this whole concept and this00:10:02
ubiquitous language also exists on the00:10:04
level of software design so the patterns00:10:06
that i showed you00:10:08
themselves could be a ubiquitous00:10:10
language right the patterns that we're00:10:12
talking about other patterns of software00:10:14
design within the software design domain00:10:16
we have entities and aggregates and00:10:17
values and contexts and partnership00:10:19
relationships whatever right those are00:10:21
our that's our language00:10:24
right00:10:25
well the the interesting thing here is00:10:27
that the same that i that i that i00:10:29
claimed was true for the domain that we00:10:31
typically think of is true for our00:10:33
domain as well would you really expect00:10:35
us to be able to walk around every00:10:37
software project in the world and come00:10:39
up with the one set of patterns that00:10:41
matches all of them00:10:43
i for one wouldn't because software00:10:45
projects are very different i mean they00:10:46
have they have00:10:48
they have different contexts right the00:10:50
context actually are00:10:52
we as software developers so i think00:10:54
this idea this language should really be00:10:56
more of a jargon kind of thing right00:10:58
it's a jargon within a certain context00:11:00
within a certain community so let's00:11:01
assume that all of us here work within00:11:05
within a larger software project where00:11:06
may be distributed across several teams00:11:09
then we have our own jargon on multiple00:11:12
levels we have words that have meaning00:11:14
within each team we also have words that00:11:16
have meaning across the teams so for00:11:18
example the ways we figure out on how to00:11:20
integrate our stuff or how to do00:11:22
frontends or how to access the database00:11:24
or00:11:25
perform network communication right00:11:27
those things00:11:29
are ways that we come up with and that00:11:31
change over the course of time once we00:11:33
discover a pattern00:11:35
we actually use it so00:11:37
the key thing that i want to get across00:11:39
here is that the set of predefined00:11:41
patterns is always only a starting point00:11:44
it's not an end in itself i don't think00:11:47
that eric evans ever wanted to claim00:11:48
that the set of patterns that he came up00:11:50
with was the one and only set of00:11:52
patterns that could ever be useful to00:11:53
anybody of course why would he claim00:11:55
such a thing he's a smart person but00:11:57
some people take it00:11:59
extremely literally literally00:12:01
they think that these things here are00:12:03
the pattern the patterns if you do the00:12:05
main drum design then you have to use00:12:07
these things these things only and you00:12:09
have to use them in exactly the way that00:12:11
the book describes them whereas my view00:12:14
is that this might be a great starting00:12:16
point they might be perfectly fine for00:12:17
you but you also might have with your00:12:19
own language you might add filters and00:12:20
rules and proxies and contracts roles00:12:22
reference whatever it is that makes00:12:24
sense within your jargon within your00:12:27
context language right so whatever makes00:12:28
sense to you you add at this level00:12:31
so that essentially means we're00:12:33
extending the the technical patterns but00:12:35
of course the same is true for the00:12:36
context relationships as well so if you00:12:39
think of what these if you if you're00:12:41
familiar with them00:12:42
what they do if you're not a briefly00:12:44
explain them what they do is they they00:12:46
tell you the ways that contexts might be00:12:48
related for example one context owned by00:12:51
one team00:12:52
might be um00:12:54
simply conforming to whatever interface00:12:56
another context prescribes you have no00:12:59
say in that they're more powerful than00:13:01
you that you find something that may be00:13:02
an outside company or a standard product00:13:05
whatever they tell you the contract is00:13:07
is the contract that's the way you ex00:13:09
you access their services or their00:13:11
interface whatever it is they offer to00:13:13
you right so that's one way of a00:13:15
relationship another might be a00:13:16
partnership where it's more of a00:13:18
negotiation between equals or the00:13:20
relationship might be one where you00:13:22
actually share a code where you have a00:13:24
common piece of code that that is that00:13:26
is available and used in both contexts00:13:29
right maybe not a good idea but that's00:13:30
not the point the point is that you can00:13:32
describe this relationship if it exists00:13:34
and that's again very useful it's a cool00:13:36
thing you draw a context map you00:13:39
visualize those dependencies you can00:13:40
reason about them you have some ways of00:13:43
dealing with them so for example00:13:44
introducing an anti-corruption layer as00:13:46
a means of isolating yourself against00:13:48
changes00:13:49
those are all very good ideas but again00:13:52
they're a starting point right you might00:13:53
have something like a formal contract00:13:55
that might mean something very specific00:13:56
to you you might have a shared spectrum00:13:58
a third party standard or whatever it is00:14:00
whatever kind of pattern makes sense to00:14:02
you again00:14:03
you should be able to extend this as you00:14:06
see fit00:14:07
so my criticism is not that the patterns00:14:09
are bad i have some issues with some00:14:11
with some of them i'm not a big fan of00:14:12
the aggregate pattern but whatever i00:14:13
mean that's a discussion we can have if00:14:15
we ever work together in a project but00:14:18
whatever makes sense to you within your00:14:19
project should be the kind of00:14:21
terminology and the kind of language00:14:22
that you come up with00:14:24
in fact00:14:25
we used to do this in a domain that is00:14:28
really really not cool anymore it's00:14:30
really not fashionable anymore and it's00:14:32
the model driven community the model00:14:34
driven architecture remodel driven00:14:36
development community right so if you're00:14:38
if you have gray hair like me then maybe00:14:40
you remember that that was once a really00:14:42
cool thing00:14:43
i don't think it's bad just because it's00:14:45
no longer fashionable i don't think it's00:14:47
the i don't think that is the solution00:14:49
to everything either not at all but00:14:52
what i want to point out is that back in00:14:54
the day when we did that we had we had a00:14:55
similar concept we had a language a meta00:14:58
level a way to express models00:15:00
with certain stereotypes in for example00:15:03
uml it was the same idea it was the same00:15:05
concept it's on the you know from far00:15:07
away this looks extremely similar to the00:15:09
whole thing00:15:10
so that was my that was my point number00:15:12
one that i wanted to make00:15:14
the second one is about00:15:16
what domain driven actually means00:15:19
so i mentioned that um00:15:21
i like the idea of being driven by the00:15:23
domain in fact i have a slide from a00:15:26
different slide deck00:15:27
that um that talks about this common00:15:30
disease among developers i hinted at00:15:32
that at the beginning right domain00:15:33
allergy that's a that's a common thing00:15:35
weirdly enough i find it it's it's00:15:38
especially prevalent among software00:15:40
architects i don't know why i think00:15:42
software architects love to play with00:15:43
stuff they love to figure out how00:15:45
technical technically complicated things00:15:47
work so they sort of flee from the00:15:49
domain into the i can say that because i00:15:52
am a software architect myself right so00:15:54
i'm always dissing myself00:15:55
as much as anybody else so the00:15:57
this idea that you can that you can00:15:59
avoid uh getting to know the domain by00:16:02
you know taking refuge in00:16:04
in technology is kind of a sad00:16:07
sad thing but it happens and the00:16:09
mandarin design wants to do things00:16:11
differently and that's to be applauded00:16:14
one of the ways it wants to do this is00:16:16
by00:16:17
having this very pure thing at the heart00:16:20
of the software system that you're00:16:21
building00:16:22
so if you're developing in in an00:16:24
object-oriented language saying java or00:16:27
scala or c-sharp then then the idea is00:16:30
that you have this piece of code that00:16:32
really only has the main logic ideally00:16:35
it has no dependency on any outside00:16:37
technical aspect at all00:16:40
so whatever it is that your system needs00:16:41
to interface with right so there are00:16:44
some examples like some kind of document00:16:46
store the network the database the user00:16:48
interface whatever it is all of those00:16:50
things are external to your domain00:16:53
kernel your domain logic00:16:55
right this domain logic in the center00:16:58
can live00:16:59
while can can continue to provide value00:17:01
while the outside interfaces change00:17:05
and the connection is made by a port so00:17:07
you have certain ports certain00:17:08
expectations typically so your domain00:17:11
code might expect that there is00:17:13
something that can maybe talk to others00:17:17
and then some implementation of that00:17:18
will connect it to an actual00:17:20
an actual network interface as just one00:17:22
example right so those these adapters00:17:25
that are sort of from the outer00:17:26
perimeter here they they sort of00:17:29
translate between the technical details00:17:32
of some specific interface and the pure00:17:34
beauty of your internal model00:17:38
and you've probably seen this under00:17:39
different names right so the shapes here00:17:41
suggest this is this is a00:17:43
hexagonal architecture the name suggests00:17:45
sports adapters that's basically the00:17:47
same thing00:17:48
um you've also probably seen it as clean00:17:50
architecture i haven't written it here00:17:52
but i think it's basically not really00:17:54
different from a good layered00:17:56
architecture but i'm willing to argue00:17:57
that debate that point if you want to at00:17:59
the end it's not not very important to00:18:00
me00:18:01
the key00:18:02
aspect to me here is this this00:18:05
this wonderful idea this wonderful idea00:18:07
of having this this really valuable code00:18:09
right this this really business focus00:18:12
the main focus pure code00:18:14
now if i were a mean person and i'm not00:18:17
then i would show you this slide i'm00:18:18
going to be very brief with it right so00:18:20
i mean sometimes you figure out that00:18:22
your actual value00:18:25
lies somewhere else i mean this is00:18:27
something that might not look as cool if00:18:29
you draw a diagram but sometimes you00:18:31
find out that there's a lot of00:18:33
actual value going on at the database00:18:35
layer or the user interface layer or00:18:36
some other layer of your application and00:18:39
the domains logic is actually not that00:18:42
fancy00:18:43
but the domain logic only provides00:18:47
if that's how kind of song sounds weird00:18:48
how can the domain let me rephrase that00:18:50
the domain logic is always the most00:18:52
important part but sometimes the domain00:18:54
logic is not best implemented in a pure00:18:57
object-oriented core model sometimes00:18:59
there are better solutions for00:19:01
implementing your domain model00:19:03
so i think these are two different ways00:19:05
of talking about whether or not00:19:07
something should be domain driven or not00:19:10
right so should design be the main00:19:12
driven well yes of course every design00:19:14
should be driven by the domain should00:19:16
not be driven by technology00:19:18
but if you understand something00:19:20
different00:19:21
when you hear domain driven design then00:19:23
i will say no not every server needs to00:19:25
be built using a technology neutral00:19:27
object oriented core again this does not00:19:29
mean that i have a problem with any of00:19:31
that i mean i like object orientation00:19:33
maybe not as much as i did 20 years ago00:19:35
but i still like it i think it's a good00:19:36
concept and again if you look at the way00:19:39
people's people programmed and sometimes00:19:41
still program small talk today then i00:19:44
think they had these same concepts they00:19:45
really had they had this idea of00:19:47
ubiquitous language they wanted to00:19:48
capture the main concepts within the00:19:50
classes and methods messages they sent00:19:52
they built beautiful systems that had a00:19:54
lot of these a lot of these attributes00:19:56
so that is a cool thing and something00:19:57
that you can absolutely do00:19:59
but you don't have to do it every time00:20:02
so let me offer you some mix some00:20:05
alternatives or some other ways you00:20:07
could go about building your domain00:20:09
logic00:20:10
one would be god forbid actually using00:20:12
your relational database00:20:14
this might come as a surprise to some00:20:16
domain driven design practitioners but00:20:18
relational databases are actually pretty00:20:20
cool pretty mature technology they're00:20:22
very very useful00:20:24
if your application is data driven then00:20:26
actually modeling your data in terms of00:20:28
tables and views and relationships00:20:30
between them indexes for key constraints00:20:33
and and all of that you actually end up00:20:35
with something that's really really00:20:37
maintainable that really really has00:20:39
super high performance because it does00:20:41
what a database is good at so sometimes00:20:43
this might be an excellent choice for00:20:45
your application00:20:47
in fact i've seen and been confronted00:20:49
with a lot of applications that00:20:52
naively wanted to implement as much as00:20:55
possible within the oo layer and made it00:20:58
and had disastrous performance because00:21:00
they created tons of n plus one problems00:21:02
when interacting with the database did00:21:04
lots of things in memory that could have00:21:05
been done on the database layer created00:21:07
lots of problems all in the name of a00:21:09
better architecture00:21:11
and it's kind of weird that you want to00:21:13
do the right thing that you want to00:21:14
follow a clean architecture and ends up00:21:16
with an ups up with something that's00:21:18
actually pretty dirty because you end up00:21:20
having to tweak and do lots of little00:21:22
tricks in some places so again this is00:21:24
i'm not suggesting this is the best00:21:26
model you know there's a there's a00:21:28
there's a guy i really recommend called00:21:30
lucasada on twitter you can find him00:21:31
very easily he writes the jooq library00:21:34
which is fantastic to access the00:21:35
relational database as a relational00:21:37
database as opposed to hiding it behind00:21:40
some fancy ooh mechanism and he's00:21:43
somebody who would say this is almost00:21:44
always the best you can do so if you00:21:46
wanted that if you want that opinion00:21:47
follow him i'm just pointing it out at00:21:49
as one very useful opinion that he could00:21:52
have and that you could use00:21:56
okay so shawna rewrites that he's also00:21:57
seeing that approach lead to really00:21:59
thorny data integrity telling just00:22:00
that's that's true i mean this is i'm00:22:02
actually not not sure whether sean's00:22:04
referring to the one i'm proposing here00:22:05
or the one i propose is an alternative00:22:08
because it's true it can be true in both00:22:09
right it can be true in the hybrid00:22:10
approach as well as in the pure00:22:12
relational approach so you'll absolutely00:22:14
have to watch out what you're doing here00:22:16
and i'm not a fan of giant messes of pl00:22:19
sql stored procedures in some messy00:22:21
oracle database either right so it all00:22:23
has the replay has its place00:22:25
okay so that was number one suggestion00:22:27
number two00:22:29
drive it from the ui drive it from the00:22:31
user experience drive it from the user00:22:34
i mean sometimes you're not in the phase00:22:36
where you have stable domain logic and00:22:38
domain experts to talk to because domain00:22:41
experts don't exist yet because you're00:22:43
building something completely new maybe00:22:44
you're building software for a startup00:22:46
that needs to figure out what it is that00:22:49
the market wants00:22:50
you're definitely not in a phase where00:22:52
you're creating a stable model for the00:22:54
next decade that you will use in terms00:22:56
of applications you're in a phase where00:22:58
you want to iterate really really00:22:59
quickly build something that and get it00:23:01
in front of actual users as quickly as00:23:03
possible00:23:04
i would say user interface matters much00:23:06
more than many architects think00:23:09
and i think user interface the actual00:23:11
way you connect to your to the actual00:23:13
domain users is a way of viewing domain00:23:15
driven as well right i think is this is00:23:17
actually what's most important to your00:23:19
actual end users so you should should00:23:21
assign a lot of importance to that00:23:24
again is this the only thing of course00:23:26
not so00:23:28
consider it as something that you might00:23:29
be might want to do in many many00:23:32
occasions personally i think that front00:23:34
end development and user-centric00:23:36
development and ui development doesn't00:23:37
get the credit it deserves in large00:23:40
parts of our industry so i think we00:23:42
should invest more everybody should know00:23:43
a little bit of that00:23:45
so um probably you should do more rather00:23:47
than less of this but again i'm just00:23:49
pointing it out as one particular00:23:51
alternative that you could use to this00:23:53
domain driven or o core design thing00:23:56
but maybe that's not your thing maybe00:23:58
you're not maybe you don't really have a00:23:59
user interface issue here maybe you have00:24:01
a really really complex piece of00:24:03
business logic maybe it's really all the00:24:06
all of the complex relationships between00:24:08
the main concepts that really really00:24:10
create the value here so maybe then the00:24:12
domain driven or o design core is the00:24:14
right thing or maybe you could go with00:24:16
this one this is an alternative um i had00:24:18
the pleasure to do two podcasts one in00:24:20
german one in english one with my00:24:22
colleague last super one with mike did i00:24:24
do both i think look at it both in00:24:26
english for the case podcast00:24:28
so um00:24:29
they both suggested something that00:24:31
actually is way more mathematical00:24:33
they're both very much into functional00:24:35
programming so their model is you you00:24:37
try to map your domain into a00:24:40
into a a00:24:42
cohesive grammar cohesive algebra that00:24:45
really connects the concepts00:24:47
using rules that actually make00:24:50
mathematical sense or similar to00:24:52
something that you are used to from from00:24:53
other mathematical branches and then you00:24:55
actually discover new domain concepts by00:24:58
applying00:24:59
the the logic within that algebra right00:25:01
so if the something is combinable00:25:03
according to your rules you try that out00:25:05
and that's that's maybe something that00:25:07
you've never that no domain expert has00:25:08
ever thought of being00:25:10
able to be combined but once you do that00:25:13
and talk to them look could we do it00:25:14
this way they say oh wow00:25:16
this looks kind of cool we didn't think00:25:17
of that00:25:18
so we actually abstract things to a00:25:20
different level you abstract things to00:25:21
this mathematical model which00:25:24
i'm pretty sure won't have entities and00:25:26
aggregates and value objects right00:25:27
that's a different way of designing a00:25:29
software you maybe have different ways00:25:31
of permutations or common combinations00:25:34
right thanks then for the link in the00:25:37
and the chat regarding the post the00:25:38
podcast episodes00:25:40
so this might be an option or maybe you00:25:42
want to go with this one maybe you have00:25:44
you don't have the single00:25:46
the single deployment chart you don't00:25:48
have the single00:25:50
software way of expressing your things00:25:52
maybe you're in a domain where your00:25:54
programming language that that's00:25:55
available to you isn't powerful enough00:25:58
to do that maybe you don't have an o00:25:59
language at your disposal maybe a00:26:01
programming in c or an embedded system00:26:03
right or maybe you have to program the00:26:05
same thing for multiple environments so00:26:06
maybe you will go with such a model00:26:08
driven approach where you actually end00:26:10
up having00:26:11
a model separate from the software00:26:13
because that is what gives that00:26:15
provides the most value to your specific00:26:17
scenario00:26:19
i'm not suggesting that any of these00:26:20
things is better than this domain driven00:26:23
oo design or domain driven design core00:26:26
right not suggesting that in fact i00:26:28
think domain driven design actually has00:26:30
a great solution for this concept which00:26:32
which is this this concept a context00:26:35
concept so i talked about those contexts00:26:37
if we look again at the definition of a00:26:39
bond of context an abundant context00:26:42
is something where a particular model is00:26:44
defined and applicable00:26:46
so in my example that i had at the00:26:48
beginning at the beginning of this00:26:49
presentation i had these three bounded00:26:51
contacts with the order management model00:26:52
the accounting model and fulfillment00:26:54
model that all have their own validity00:26:57
within that particular context00:26:59
and you could view that and extend it to00:27:01
include the choice of technology right00:27:04
you could decide to implement things00:27:06
differently within each of those00:27:08
contexts and decide that the relational00:27:10
model works best for your accounting00:27:12
scenario here whereas the ux driven one00:27:14
works best for the order management and00:27:16
the tactical ddd one works best00:27:19
as an implementation strategy for the00:27:20
fulfillment domain00:27:22
i don't really care this is just an00:27:23
example right this is no this does not00:27:25
attempt to actually suggest that this is00:27:27
a good choice for those for those00:27:30
particular kind of context i'm just00:27:32
pointing out that you don't have to do00:27:33
things the same way in all of those00:27:35
comics00:27:37
so00:27:38
is the idea overrated00:27:41
i think that00:27:42
that strategic ddd is an excellent00:27:44
starting point00:27:46
in fact i use that almost all the time00:27:48
sometimes i call it strategic dvds00:27:50
sometimes i don't use that terminology00:27:53
sometimes i use the word bounded context00:27:54
sometimes i don't in fact i've been00:27:56
doing that for far longer and the main00:27:58
driven design exists which is not00:28:00
supposed to sound like an arrogant00:28:02
statement or mean that domain of design00:28:03
does not create a lot of value i think00:28:05
it creates a lot of value in this regard00:28:07
so00:28:08
this is a good thing00:28:10
tactical ddd00:28:12
i use slightly less favorably i think00:28:14
it's a good starting point as well but00:28:16
it's best viewed as a micro level00:28:17
decision i mean this is one way of00:28:19
implementing systems and it's really on00:28:21
a different level i'm i'm not sure it00:28:23
should be part of the same discussion00:28:25
right this is00:28:26
this is a different thing you can do00:28:28
actually you can build excellent systems00:28:30
in a domain driven way i think or you00:28:32
can claim that you're doing domain00:28:33
driven design even if you don't ever use00:28:35
any of the stereotypes mentioned in the00:28:37
technical dvd part00:28:39
of the book or in any of those00:28:40
discussions00:28:42
i really appreciate ddn's community00:28:44
right i want to make that clear i like00:28:46
the people there i respect them a lot i00:28:48
have fantastic discussions with many of00:28:50
them some of my colleagues are very00:28:51
local parts of that community and that's00:28:54
that's perfectly fine i'm not i don't00:28:55
want to you know00:28:57
do the typical these these guys are all00:28:59
stupid and i knew it all along not at00:29:01
all00:29:02
but i think sometimes there's the00:29:04
tendency to view this one solution as00:29:06
the only viable one which sort of leads00:29:08
me to my summary right i think just in00:29:10
general as general advice00:29:12
no matter what the particular topic is00:29:15
you shouldn't be looking for just one00:29:17
thing00:29:18
maybe that's something if if you're just00:29:20
entering this this domain then it will00:29:22
take a while if you've been here for a00:29:23
while you probably know that already00:29:25
pretty sure you do00:29:26
no single approach no single approach00:29:28
will will match your needs in 100 of the00:29:31
cases or even 50 of the cases right00:29:34
everything you learn is an addition to00:29:36
your tool set and something that you00:29:38
might be able to use you might know some00:29:40
things very well others not so well but00:29:42
still you should have a large tool set00:29:44
to be able to choose something that00:29:46
matches the particular needs unless00:29:49
your day job is being a00:29:51
speaker at conferences that who talks00:29:53
about one particular topic i mean that's00:29:55
a different thing then you can pick one00:29:56
and just stick to that but if you're a00:29:58
general purpose practitioner who builds00:30:00
actual systems for a domain then00:30:02
probably you need more than one approach00:30:06
recipes are fantastic starting points so00:30:10
specifically especially if you're00:30:12
starting something from scratch and00:30:13
don't have a lot of experience then you00:30:15
might want to follow the recipe more00:30:16
closely you might00:30:18
some dogma might actually be valuable00:30:20
right that part of your learning curve00:30:24
it's the same as with a cooking recipe00:30:25
right when you're doing it for the first00:30:26
time you probably follow the recipe more00:30:28
closely than when you're cooking the00:30:30
dish for the tenth time then you'll do a00:30:32
lot more variation depending on your00:30:34
character you might start the first00:30:35
recipe in a completely different00:30:37
whatever it doesn't really matter right00:30:38
so the00:30:39
the following rules at the start is fine00:30:41
but don't continue to be dogmatic in the00:30:43
long run00:30:45
and i think to me the most important00:30:46
thing is use those contexts which are00:30:48
the most valuable contribution as sort00:30:51
of decision spheres use them00:30:53
to give you a00:30:54
boundary within which you can decide00:30:57
differently from all the others and00:30:58
that's i think a very useful thing to do00:31:00
and will help you with a lot of00:31:02
decisions00:31:04
okay that's all i have00:31:20
youDescription:
This presentation was recorded at GOTOpia Chicago 2021. https://gotochgo.com/2024 Stefan Tilkov - Co-founder & Principal Consultant at INNOQ ABSTRACT Yes, there is a life beyond DDD. In the best sense of pattern languages, domain-driven design gives clear names to things that many developers and designers know how to do, but cannot reliably and compatibly communicate about. But like other very popular approaches, it is sometimes treated as if it were the only viable design strategy. In this talk we’ll look at DDD’s contributions as well as some of the misunderstandings and misuses that come with the hype surrounding it. We’ll try to derive some useful guidelines for treating domain-driven design in particular, and software design hypes in general [...] TIMECODES 00:00 Intro 00:26 What is DDD? 04:27 Key aspect 1: Ubiquitous language 04:52 Key aspect 2: Tactical patterns 06:13 Key aspect 3: Strategic design 07:00 Bounded contexts 09:29 Conceptual extensibility 15:15 Should design be domain-driven? 26:30 Contexts revisited 27:38 Is DDD overrated? 31:05 Outro Download slides and read the full abstract here: https://gotochgo.com/2021/sessions/1778/is-domain-driven-design-overrated RECOMMENDED BOOKS Simon Brown • Software Architecture for Developers Vol. 2 • https://leanpub.com/visualising-software-architecture Mark Richards & Neal Ford • Fundamentals of Software Architecture • https://www.amazon.com/Fundamentals-Software-Architecture-Comprehensive-Characteristics/dp/1492043451?language=en_US Gregor Hohpe • The Software Architect Elevator • https://www.amazon.com/Software-Architect-Elevator-Redefining-Architects/dp/1492077542?s=books&language=en_US Michael Keeling • Design It! • https://www.amazon.com/Design-Programmer-Architect-Pragmatic-Programmers-ebook/dp/B077FHD78B?s=books&language=en_US George Fairbanks • Just Enough Software Architecture • https://www.amazon.com/Just-Enough-Software-Architecture-Risk-Driven/dp/0984618104?s=books&language=en_US Nick Rozanski & Eoin Woods • Software Systems Architecture • https://www.amazon.com/Software-Systems-Architecture-Stakeholders-Perspectives/dp/B00C7GBGN0?s=books&language=en_US Peter Coad, Eric Lefebvre & Jeff de Luca • Java Modeling In Color With UML • https://www.amazon.com/Java-Modeling-Color-UML-Enterprise/dp/013011510X?language=en_US Eric Evans • Domain-Driven Design • https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215?language=en_US Grady Booch, James Rumbaugh & Ivar Jacobson • The Unified Modeling Language Reference Manual • https://www.amazon.com/Unified-Modeling-Language-Reference-Manual/dp/020130998X?language=en_US https://twitter.com/GOTOcon https://www.linkedin.com/company/goto- https://www.facebook.com/unsupportedbrowser #DDD #DomainDrivenDesign #SoftwareArchitecture #UX #UI #Udriven Looking for a unique learning experience? Attend the next GOTO conference near you! Get your ticket at https://gotopia.tech/ SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily. https://www.youtube.com/user/GotoConferences/?sub_confirmation=1
Preparing download options
Similar videos from our catalog
%3Aformat(webp)%2Fi.ytimg.com%252Fvi_webp%252F0kI-as3K4Zo%252Fmaxresdefault.webp&w=1139&q=75)
%3Aformat(webp)%2Fi.ytimg.com%252Fvi_webp%252FHVsySz-h9r4%252Fmaxresdefault.webp&w=1139&q=75)
%3Aformat(webp)%2Fi.ytimg.com%252Fvi_webp%252FKLEDKgMmbBI%252Fmaxresdefault.webp&w=1139&q=75)
%3Aformat(webp)%2Fi.ytimg.com%252Fvi%252FMWsk1h8pv2Q%252Fmaxresdefault.jpg&w=1139&q=75)
%3Aformat(webp)%2Fi.ytimg.com%252Fvi_webp%252FOBabwRH0XUo%252Fmaxresdefault.webp&w=1139&q=75)
%3Aformat(webp)%2Fi.ytimg.com%252Fvi_webp%252FRtMmxqkPVug%252Fmaxresdefault.webp&w=1139&q=75)
%3Aformat(webp)%2Fi.ytimg.com%252Fvi%252FWgLlwjZNEtY%252Fmaxresdefault.jpg&w=1139&q=75)
%3Aformat(webp)%2Fi.ytimg.com%252Fvi_webp%252FiCGrKFH2oeo%252Fmaxresdefault.webp&w=1139&q=75)
%3Aformat(webp)%2Fi.ytimg.com%252Fvi_webp%252Ft92iupKHo8M%252Fmaxresdefault.webp&w=1139&q=75)
%3Aformat(webp)%2Fi.ytimg.com%252Fvi_webp%252FuBqRv8bDroc%252Fmaxresdefault.webp&w=1139&q=75)
* — If the video is playing in a new tab, go to it, then right-click on the video and select "Save video as..."
** — Link intended for online playback in specialized players
Questions about downloading video
How can I download "Is Domain-Driven Design Overrated? • Stefan Tilkov • GOTO 2021" video?
http://unidownloader.com/ website is the best way to download a video or a separate audio track if you want to do without installing programs and extensions.
The UDL Helper extension is a convenient button that is seamlessly integrated into YouTube, Instagram and OK.ru sites for fast content download.
UDL Client program (for Windows) is the most powerful solution that supports more than 900 websites, social networks and video hosting sites, as well as any video quality that is available in the source.
UDL Lite is a really convenient way to access a website from your mobile device. With its help, you can easily download videos directly to your smartphone.
Which format of "Is Domain-Driven Design Overrated? • Stefan Tilkov • GOTO 2021" video should I choose?
The best quality formats are FullHD (1080p), 2K (1440p), 4K (2160p) and 8K (4320p). The higher the resolution of your screen, the higher the video quality should be. However, there are other factors to consider: download speed, amount of free space, and device performance during playback.
Why does my computer freeze when loading a "Is Domain-Driven Design Overrated? • Stefan Tilkov • GOTO 2021" video?
The browser/computer should not freeze completely! If this happens, please report it with a link to the video. Sometimes videos cannot be downloaded directly in a suitable format, so we have added the ability to convert the file to the desired format. In some cases, this process may actively use computer resources.
How can I download "Is Domain-Driven Design Overrated? • Stefan Tilkov • GOTO 2021" video to my phone?
You can download a video to your smartphone using the website or the PWA application UDL Lite. It is also possible to send a download link via QR code using the UDL Helper extension.
How can I download an audio track (music) to MP3 "Is Domain-Driven Design Overrated? • Stefan Tilkov • GOTO 2021"?
The most convenient way is to use the UDL Client program, which supports converting video to MP3 format. In some cases, MP3 can also be downloaded through the UDL Helper extension.
How can I save a frame from a video "Is Domain-Driven Design Overrated? • Stefan Tilkov • GOTO 2021"?
This feature is available in the UDL Helper extension. Make sure that "Show the video snapshot button" is checked in the settings. A camera icon should appear in the lower right corner of the player to the left of the "Settings" icon. When you click on it, the current frame from the video will be saved to your computer in JPEG format.
What's the price of all this stuff?
It costs nothing. Our services are absolutely free for all users. There are no PRO subscriptions, no restrictions on the number or maximum length of downloaded videos.