00:00:00
[Music]
00:00:02
foreign
00:00:06
[Applause]
00:00:07
[Music]
00:00:08
I would say let's get started uh thank
00:00:12
you all for showing up in such huge
00:00:14
numbers I'm impressed
00:00:16
isn't it good to be back here in
00:00:18
Barcelona as I said yesterday already
00:00:19
it's nice
00:00:22
um so
00:00:23
give me a quick hands who was in the
00:00:27
talk of me and Oliver yesterday just
00:00:30
raise your hands ah okay quite a few
00:00:33
folks for those who weren't there don't
00:00:35
worry
00:00:36
um I have included the most important
00:00:39
messages which I have sent out there in
00:00:41
this slide tag as well so uh you won't
00:00:44
get lost no worries all will be good
00:00:47
um so I'm today I'm or yesterday we
00:00:50
talked about
00:00:51
modularization some general ideas and I
00:00:56
mean we all heard that at University
00:00:58
when we learn programming and so on and
00:01:01
so forth
00:01:02
sometimes we forget about some of those
00:01:04
principles fair enough there is so much
00:01:07
new stuff pumping into our brains all
00:01:09
the time that's a good thing but when we
00:01:11
talk about modularity a question that I
00:01:15
get very often is how do I identify
00:01:18
those boundaries
00:01:19
I mean the concepts are cool but how do
00:01:22
I actually do it and that's what we want
00:01:25
to do today and there is a thing called
00:01:28
domain driven design something that is
00:01:31
not very new at all old stuff 19 years
00:01:35
old crazy isn't it and
00:01:37
um but the with a very active community
00:01:40
and that Community always produces new
00:01:43
ideas how to improve the work and so on
00:01:45
and what I try to tell you or explain to
00:01:48
you in this talk today is I would say
00:01:51
the current status in 2022 and there's a
00:01:54
lot of new stuff a lot of open source
00:01:57
stuff on GitHub under Creative Commons
00:02:00
licenses and so on I'll show you all
00:02:02
that stuff in this talk just a few words
00:02:04
about myself I'm Michael I work for a
00:02:06
company called innocu which is basically
00:02:09
a Consulting software delivery company I
00:02:12
would consider myself to be a member of
00:02:15
the DDD Community I'm also a part of
00:02:18
that organization here on GitHub and I
00:02:22
like doing conference talks quite a bit
00:02:24
so here I am
00:02:26
separation of concerns yeah is an idea
00:02:30
where we divide a complex systems into a
00:02:32
bunch of responsibilities yeah something
00:02:35
you probably all heard about
00:02:37
those of you who were in The Talk
00:02:39
yesterday heard quite a bit about that
00:02:41
but I think that's something most of you
00:02:43
have already heard and modularity is a
00:02:46
specialization of of separation of
00:02:48
concerns with a key focus on stuff like
00:02:51
information hiding loose coupling High
00:02:53
cohesion and all these good old design
00:02:56
principles now how do I how do we
00:02:59
achieve that
00:03:01
one idea for doing that is domain driven
00:03:04
design so
00:03:06
what we are usually pretty good at
00:03:08
especially when we look at separation of
00:03:10
concerns it's a separation into
00:03:12
technical concerns yeah like layered
00:03:15
architecture onion architecture clean
00:03:17
architecture hexagonal architecture on a
00:03:19
technical horizontal level we are pretty
00:03:22
good at that this idea here published 19
00:03:25
years ago in this phenomenal phenomenal
00:03:28
book but also hard to read book by Eric
00:03:30
Evans is an idea for or contains ideas
00:03:34
for modularization on a vertical level
00:03:37
on a vertical slicing and there are I
00:03:40
would say two key modularization
00:03:43
Concepts in domain driven design one is
00:03:45
the boundary context the other one is
00:03:47
the Aggregate and it also
00:03:50
emphasizes that we need to do design
00:03:53
domain modeling in an iterative fashion
00:03:56
I mean who comes up with a property sign
00:03:59
for a complex system that's what DDT
00:04:02
does address
00:04:04
in the first run is there someone of you
00:04:07
who does that
00:04:09
ah good for you great congrats so most
00:04:13
of us aren't capable of doing that so
00:04:16
and in the DDT space we talk about
00:04:18
modularity on a first hand
00:04:20
in a construct called bounded context I
00:04:23
would call that a rather coarse grain
00:04:25
module usually when you work with
00:04:28
microservice architectures or a
00:04:31
specialization of that like stuff like
00:04:34
self-contained systems and you usually
00:04:37
cut the deployment units along boundary
00:04:40
context and please don't mix these
00:04:42
Concepts up the boundary context is the
00:04:45
domain boundary
00:04:47
a microservice is not is a deployment
00:04:50
boundary the boundary of a deployment
00:04:53
unit something that you deploy
00:04:55
independently
00:04:57
don't mix this up if you take a look at
00:04:59
the idea of modulus what Oliver dropbomb
00:05:03
is talking about quite a bit yeah that's
00:05:06
basically a big deployment boundary
00:05:07
which can contain a bunch of boundary
00:05:10
contexts so you never Implement
00:05:13
something as a boundary context
00:05:15
you model a boundary context a boundary
00:05:18
context is basically a boundary around
00:05:19
the domain module and in that thing we
00:05:22
have a finer grained option for
00:05:25
granularity those are the Aggregates and
00:05:28
this talk aims to explain to you how to
00:05:31
model these things Yeah so basically we
00:05:34
start off with boundary context and now
00:05:37
the first tint when you leave this call
00:05:39
this call I I'm still stuck in the
00:05:43
remote but
00:05:45
that was a good one now when you leave
00:05:48
this talk here
00:05:50
oh god
00:05:52
um
00:05:53
you may want to check out this
00:05:55
organization on GitHub it's called
00:05:57
dddcrew github.com DDD crew under this
00:06:02
organization uh the the active part of
00:06:05
the domain room design Community I I
00:06:07
would say there are 10 to 20
00:06:09
contributors yeah they are publishing
00:06:13
work and everything there is Creative
00:06:15
Commons so for instance this
00:06:18
visualization so we have published a a
00:06:20
description DDD starter modeling process
00:06:23
a lot of people ask how do I get started
00:06:25
check this out and that's a good idea
00:06:27
good resource also contains mirror
00:06:30
templates so if you want to do modeling
00:06:32
on Miro you can download board backups
00:06:34
for templates and stuff like that good
00:06:36
stuff there and I want to do this talk
00:06:40
along this DDD starter modeling process
00:06:42
we won't touch point on anything there
00:06:45
so in this talk we will not talk about
00:06:48
understanding business models and user
00:06:50
needs Pro tip to you as developers
00:06:53
please do that try to understand why
00:06:56
your organization and how your
00:06:58
organization is earning money with the
00:07:00
software you write I think it will lead
00:07:02
to very good and sensible design
00:07:04
decisions good idea we don't have time
00:07:06
for that I'd love to talk an hour about
00:07:08
that as well
00:07:10
um we also won't talk about make or buy
00:07:12
decisions strategic thinking and
00:07:15
organizational aspects aligning teams
00:07:17
that's not what we're going to do but we
00:07:19
will Chomp head first yeah into this
00:07:21
discovery part now in this talk
00:07:24
now would repair brandolini a very smart
00:07:28
Kyle from Kai from bologna in Italy uh
00:07:31
who is the inventor of a method called
00:07:33
event storming which we will check out
00:07:35
in this talk once said it's not the
00:07:37
expert's knowledge of the domain experts
00:07:40
that goes into production
00:07:42
it's the mostly implicit assumptions
00:07:46
in your brains as developers about a
00:07:49
certain domain that goes into production
00:07:52
yeah usually we are why do projects fail
00:07:55
usually we're pretty good at technical
00:07:57
things yeah I mean of course you're all
00:08:00
using Springs or we're all good on the
00:08:02
tech side yeah perfect but
00:08:05
projects very often failed due to a
00:08:07
mismatch of assumptions and stuff like
00:08:09
that yeah and that's a very small quote
00:08:12
and very often we are faced with this
00:08:14
situation I told God we all have a
00:08:16
shared understanding really
00:08:19
let's check this out one method yeah and
00:08:22
this the main expert knowledge is
00:08:24
totally essential for domain driven
00:08:26
design yeah so you need to talk to your
00:08:28
business people for finding good
00:08:30
vertical module boundaries that's the
00:08:32
first thing you should take away yeah
00:08:35
and sometimes you can say oh I've got a
00:08:37
bunch of requirements Engineers yeah
00:08:40
and they do that for me
00:08:44
some of you have kids I'm pretty sure
00:08:46
and at a at the birthday party for the
00:08:48
kids sometimes in Germany we have a game
00:08:51
called Silent post so we line up one kid
00:08:54
another kid another kid another kid and
00:08:58
we whisper a story Into the ear of one
00:09:00
of the kids and the kids are supposed to
00:09:02
whisper the story further further and
00:09:04
further
00:09:05
and after the fifth kid everyone loves
00:09:07
what utter nonsense is coming out
00:09:12
this happens in software as well but no
00:09:14
one is laughing there yeah no one could
00:09:15
receive that to be funny yeah so
00:09:19
what you want to have is that the last
00:09:21
kid really chats to the first kid
00:09:25
I'm sorry for those who have to work
00:09:26
with safe yeah because in safe you have
00:09:29
a very big distance sometimes yeah
00:09:32
now we need direct collaboration but how
00:09:35
do we do that yeah what could possibly
00:09:37
go wrong yeah
00:09:40
let's check this out and I'm going to be
00:09:43
super sarcastic now I don't want to
00:09:45
offend any developers here so we have
00:09:47
this hotel room here yeah that was one
00:09:50
in Switzerland I think how would usual
00:09:53
business folks name these things here it
00:09:55
has something like window trolley TV
00:09:57
chair desk painting now let's imagine we
00:10:00
implement this room as a code base
00:10:03
or do we very often see in code bases
00:10:06
and I'm being really evil now like that
00:10:08
yeah I see class names like transparency
00:10:12
Factory decorator impulse entertainment
00:10:15
provide a Singleton work enablement
00:10:17
device uh rollable stuff container or
00:10:20
rest provider or something like that
00:10:22
yeah and sometimes the language even
00:10:25
leaks to the business and the business
00:10:27
starts talking that language as well
00:10:29
yeah that's a very nice source of a lot
00:10:33
of evil out there yeah now what we want
00:10:36
to have in DDD is we want to achieve a
00:10:38
ubiquitous language a shared language
00:10:41
that we speak together which becomes the
00:10:43
basis yeah for the domain model in that
00:10:46
modules yeah I want to see that language
00:10:49
in drawings I want to see it in the
00:10:51
documentation and I want to see that
00:10:53
language in the code so that I have a
00:10:56
class or a module called TV and not
00:10:59
entertainment provider Singleton I mean
00:11:02
that sounds really smart yeah I mean you
00:11:05
you can you can say okay then we need to
00:11:08
implement the entertainment provider
00:11:09
single and everyone else in the meeting
00:11:11
is like oh that's a smart person here
00:11:13
seriously yeah
00:11:15
now one way to facilitate that is a
00:11:18
method called event storming please
00:11:20
raise your hand who has done some event
00:11:21
storming already
00:11:26
next year I want to see more hands here
00:11:28
that's a great Workshop so basically you
00:11:31
get together a bunch of folks this room
00:11:34
would be super cool for an event stomach
00:11:36
because we have a very long wall in the
00:11:38
back over there yeah a very long one and
00:11:41
you need many sticky notes and many pens
00:11:44
and stuff like that and what you start
00:11:45
with you explore the domain and you
00:11:47
think about domain events that can
00:11:50
happen yeah so stuff like application
00:11:54
corrected in-depth validation done loan
00:11:58
granted loan not granted signed contract
00:12:01
answered
00:12:03
and not
00:12:04
um rest template initialized or
00:12:07
something like that we want to focus on
00:12:09
business events and we want to collect
00:12:11
them in a brainstorming fashion after
00:12:13
that we sort them in an order so that we
00:12:16
can tell a story this is not technical
00:12:20
at all everyone can participate in those
00:12:23
workshops yeah everyone can participate
00:12:26
I think that's a very easy thing yeah
00:12:28
and um
00:12:31
I've even seen blind persons
00:12:33
participating you know just put someone
00:12:35
next to them and and then you write the
00:12:38
sticky notes and put them on the wall
00:12:39
where they see them fit that works
00:12:41
that's good yeah and this can ignite
00:12:45
discussions and there you will see a
00:12:48
bunch of misunderstandings because they
00:12:49
are explicitly on the wall
00:12:52
good stuff and after that we try to
00:12:55
identify so-called pivotal events events
00:12:59
that are really important yeah so for
00:13:02
instance for searching and his amazing
00:13:04
team yeah props to everyone involved
00:13:06
here in this conference yeah ticket
00:13:08
purchased
00:13:10
yeah speaker slot confirmed those are
00:13:13
more important events than
00:13:17
um
00:13:18
session abstract checked out for
00:13:21
instance or if you configure a new
00:13:23
laptop yeah Ram added
00:13:27
hard disk edit processor chosen screen
00:13:30
size chosen
00:13:32
all good stuff but laptop purchased
00:13:35
that's a really important thing I mean
00:13:37
you can configure as many of your dream
00:13:40
MacBooks as you want as long as you
00:13:42
don't buy them it's totally
00:13:43
uninteresting for apple and it basically
00:13:45
costs some money yeah so you try to
00:13:48
identify them and maybe you also see
00:13:50
showcase some parallel streams over
00:13:52
there yeah and take a look at that
00:13:56
at those events what do you think are
00:13:58
some pivotal events there
00:14:00
so we have an application filled out
00:14:03
application submitted application form
00:14:06
validated for mandatory Fields
00:14:08
pre-scoring green pre-scoring red
00:14:10
application rejected any ideas someone
00:14:14
application submitted absolutely I would
00:14:17
say yeah those here those are good
00:14:20
candidates for such pivotal events we'll
00:14:22
come back to them they'll be important
00:14:24
later on yeah
00:14:27
and then we go into a decomposition and
00:14:32
especially based on that event storming
00:14:35
knowledge that we have gathered gathered
00:14:36
there yeah so
00:14:38
we can group things along many concerns
00:14:41
yeah we can group stuff by shape color
00:14:43
text size yeah
00:14:45
now what's the wrong thing we don't know
00:14:47
we need to find out we need to talk to
00:14:48
other peoples and discard the ones that
00:14:51
make absolutely no sense
00:14:53
yeah so heuristic
00:14:56
here
00:14:58
there is a very high chance that those
00:15:01
pivotal events sit at the boundary of a
00:15:04
module
00:15:05
yeah so because they are important maybe
00:15:08
they leave the boundary of a module yeah
00:15:11
think about drawing an image
00:15:13
the Mona Lisa for instance in the Louvre
00:15:16
everyone knows the Mona Lisa and do you
00:15:18
think it was drawn in the first place as
00:15:21
a perfect one no someone sketched out
00:15:23
the Contours yeah I see a bunch of folks
00:15:26
with tattoos in the in the crowd yeah
00:15:28
when you go when you do a tattoo yeah
00:15:30
you also sketch some lines and so on you
00:15:33
make a draft and then you finalize these
00:15:36
things yeah
00:15:37
and that's what we do here with the
00:15:39
pivotal events they are an indicator
00:15:40
yeah maybe let's go for that let's check
00:15:43
this out stuff like that yeah and then
00:15:47
after we've done that we check out the
00:15:48
swim Lanes we start thinking hey maybe
00:15:51
those are good good candidates
00:15:54
for boundaries so we move towards them
00:15:58
those are not the perfect boundaries
00:16:00
that's a starting point for further
00:16:03
discussions for further refinements yeah
00:16:06
and then we move to the bounded context
00:16:08
by definition the boundary context is
00:16:11
the boundary for a domain model
00:16:13
expressed in a consistent language
00:16:14
tailored around a specific need
00:16:18
that definition sounds really smart
00:16:21
doesn't it but what does it mean let's
00:16:24
depict it I'm pretty sure some of you
00:16:26
left the call left the call
00:16:29
again the talk yesterday maybe I should
00:16:33
start a soon call us
00:16:35
to be in my used habitat
00:16:38
um now left the talk yesterday and and
00:16:40
thought what did he mean with that
00:16:43
let's go into that test that one
00:16:46
injury
00:16:47
every module is a boundary obviously
00:16:49
isn't it it should be yeah
00:16:53
um and within that boundary we want to
00:16:55
be able to learn and master some domain
00:16:56
complexity we want to conduct
00:16:58
experiments and learn about the domain
00:17:00
yeah and we want to deliver high value
00:17:02
software within that boundary
00:17:06
it's a boundary for a model and now
00:17:09
model what does the domain room design
00:17:11
World think about a model
00:17:15
we don't think about data here we think
00:17:18
about Behavior
00:17:19
like business rules decisions policies
00:17:23
yeah so there's a big difference between
00:17:26
the classic object-oriented design which
00:17:29
focuses on nouns first
00:17:32
and then attributes very often we build
00:17:35
a data model with that here we focus on
00:17:38
verbs first think about the event
00:17:39
storming stuff
00:17:41
and then we think about rules Behavior
00:17:45
that's expressed in a consistent
00:17:47
language a language has terminology
00:17:50
definitions and meaning
00:17:52
now let me ask you a question
00:17:55
to to get an example for that what's a
00:17:58
tomato is it a fruit or a vegetable what
00:18:00
do you think
00:18:02
fruit fruit yeah that's what botanics
00:18:06
say yeah Botanical science says tomato
00:18:08
is a fruit
00:18:10
however in the context of cooking in the
00:18:13
context mind that of cooking a tomato is
00:18:16
often treated as a vegetable who wants a
00:18:19
tomato in a fruit salad no one yeah very
00:18:22
strange yeah now think about U.S customs
00:18:25
used Customs had import tariffs on
00:18:28
vegetables what did people do
00:18:30
they imported a lot of tomatoes
00:18:32
until the U.S customs said we don't care
00:18:35
what science says I mean who cares about
00:18:37
science anyways these days yeah we don't
00:18:40
care about that we Define the Tomato as
00:18:43
a vegetable
00:18:44
another context who who knows the time
00:18:47
management technique pomodoro
00:18:49
some raised hands here yeah in this
00:18:52
context the Tomato represents a unit of
00:18:55
25 minutes of uninterrupted work yeah
00:18:59
and now let's go back way back to the
00:19:03
time where theater pieces were done at
00:19:06
markets at marketplaces now in this
00:19:10
context what was a tomato there that was
00:19:13
flying to the stage
00:19:15
negative feedback
00:19:18
those are all linguistic contexts and
00:19:21
that's what I want to achieve with that
00:19:23
and then there's this last thing in this
00:19:26
definition purpose I want to bind that
00:19:28
language those rules and this specific
00:19:30
model to a given purpose now the
00:19:33
boundary context is not about building a
00:19:36
botanics use Customs cooking time
00:19:37
management feedback tomato
00:19:40
how do we do that very often under the
00:19:43
dry principle don't we yeah
00:19:47
so you know that example from yesterday
00:19:49
let me quickly recap that those of you
00:19:52
haven't been in the talk yesterday we
00:19:54
just go quickly over that to give a hook
00:19:56
point to the ones who were in The Talk
00:19:57
yeah so Sergi did some room planning
00:20:01
handle payments sold tickets that
00:20:03
involved you as visitors to the
00:20:05
conference
00:20:06
we can group those concerns
00:20:09
don't repeat yourself we know that
00:20:11
principle we love it
00:20:13
another principle we are very often
00:20:15
built
00:20:16
a boundary around the model like that
00:20:19
yeah the
00:20:21
batch printing
00:20:23
ticket selling
00:20:25
event management customer that can do
00:20:28
everything perfect thing absolutely
00:20:30
reusable
00:20:32
well maybe some parts let's revisit this
00:20:35
definition
00:20:37
while this is a boundary to a certain
00:20:39
degree yeah
00:20:41
is it a model hmm
00:20:43
we didn't talk about rules yet it's more
00:20:46
a data model isn't it
00:20:48
has it does it have a consistent
00:20:50
language not so much and is it tailored
00:20:53
around a specific purpose hell no
00:20:56
definitely not yeah this has no purpose
00:20:59
at all and the language is totally
00:21:02
generic there
00:21:04
maybe that's a better idea
00:21:07
so tie things to a purpose
00:21:10
we use explicit terminology some domain
00:21:14
room design folks even call themselves
00:21:16
domain linguists because they take care
00:21:19
about these details
00:21:23
now you can also you have a ton of
00:21:25
terminology on your event storming wall
00:21:28
it's written down there you just need to
00:21:31
read it
00:21:32
yeah you can also find misconceptions
00:21:36
unsharpness
00:21:38
um abbreviations and stuff like that
00:21:41
gives you the chance to to ask questions
00:21:44
hey what's the difference between an
00:21:46
application form a contract proposal and
00:21:49
a contract
00:21:50
tell me ah okay maybe that's an
00:21:54
indicator
00:21:55
huh and then yeah when you have
00:21:57
identified the first candidates for
00:22:00
those founder contacts yeah based on
00:22:01
that so let me go back to that slide
00:22:03
quickly yeah so for instance
00:22:06
this one here scoring rule cluster here
00:22:09
maybe that's an indicator of merging
00:22:12
things again yeah so okay we have here
00:22:14
two different pivot two pivotal events
00:22:17
main scoring green red pre-scoring green
00:22:19
red
00:22:20
it even contains the term scoring maybe
00:22:23
we want to define a boundary context for
00:22:25
this part and this part that this is the
00:22:27
same thing yeah or also those rejections
00:22:30
yeah what do we do that is a rejection
00:22:33
the same thing as a decision maybe a
00:22:35
rejection is actually a decision so
00:22:38
those are valuable discussions that we
00:22:40
can have there and the next thing that
00:22:42
we can do is we can see how Loosely
00:22:45
coupled is that stuff now I think we
00:22:48
talked
00:22:49
this drives you so far a lot towards
00:22:52
cohesion yeah
00:22:56
but how about
00:22:58
the coupling
00:22:59
the loose coupling we need to verify
00:23:01
that
00:23:02
and again here the DDD crew helps you
00:23:06
um a guy called Nicktoon who's amazing
00:23:09
make sure to follow Nick on Twitter and
00:23:12
check out his blog post on medium he
00:23:15
publishes a lot of good stuff he brought
00:23:18
into place this technique called the
00:23:21
main message flow modeling so we have
00:23:23
some boundary context candidates and
00:23:25
then we can check out
00:23:27
what messages need to go between them
00:23:30
you can go ahead and say okay let's work
00:23:33
in a synchronous way working a lot with
00:23:35
queries and commands like
00:23:38
get requests post requests put requests
00:23:41
and stuff like that you can model
00:23:43
event-driven architectures with that
00:23:46
and what you can visualize in a way
00:23:49
there
00:23:49
how the coupling is between those if you
00:23:53
have a high degree of communication
00:23:56
bandwidth yeah on a coupling side
00:23:59
between these things you may have an
00:24:01
indicator
00:24:02
that you may want to revisit yeah
00:24:06
the the boundary context you have
00:24:08
identifies and no one wants a death star
00:24:10
context that
00:24:12
covers to everything that's coupled
00:24:14
that's bound to everything because then
00:24:16
yeah we we don't have this loose
00:24:20
coupling idea here and there with this
00:24:22
technique you can visualize coupling and
00:24:24
as some of you may already see this is a
00:24:27
mirror graphic there is also a mirror
00:24:30
template for that so if you want to do
00:24:32
that grab the template start a mirror
00:24:35
and you're good to go
00:24:36
yeah for instance here is also an
00:24:38
example so and you can tell stories
00:24:42
on that and I like this storytelling
00:24:44
idea here so what can we say Okay an
00:24:47
applicant yeah over there
00:24:51
ah an applicant fills an application
00:24:55
in the context application entry and
00:24:57
check they submit the application in
00:25:00
application entry and check application
00:25:03
entry and check fires and event
00:25:05
application submitted yeah
00:25:08
scoring reacts on that
00:25:11
and sooner or later fires an event
00:25:13
pre-score in green
00:25:15
then we ask for some documents hey
00:25:18
please prove what you have added in the
00:25:19
other application do you really earn
00:25:22
5000 Euros a month
00:25:24
possible prove it yeah and so on so you
00:25:27
can walk through that with the domain
00:25:30
experts
00:25:32
and in parallel you already get
00:25:36
a bunch of candidates maybe for restful
00:25:39
HTTP apis for events that you want to
00:25:43
publish through
00:25:45
Kafka or whatever what you want to do
00:25:47
yeah you'll really get some indications
00:25:49
for API design there as well for the
00:25:52
module and this is not technical API
00:25:55
design
00:25:56
that's an API design which contains
00:26:00
domain stuff which exposes capabilities
00:26:04
yeah
00:26:06
some of you heard me ranting about this
00:26:08
get set hell yeah in the Ides yesterday
00:26:12
yeah and the same goes with the restful
00:26:15
HTTP apis how many apis haven't we seen
00:26:18
get put post delete yeah crud apis I
00:26:22
always tell my customers it would be
00:26:24
more honest if you had the database
00:26:26
credentials to the consumers directly
00:26:29
yeah you save some latency with the
00:26:32
restful HTTP API there yeah if you do
00:26:34
that yeah it may also give you an
00:26:37
indication for hypermedia usage so when
00:26:41
can we offer submitting the application
00:26:45
when the application is complete when
00:26:48
everything is in place then we can
00:26:51
display the submit button can indicate
00:26:53
that here as well so but in a way that
00:26:57
is not too technical so I've seen a
00:27:00
bunch of domain experts who have never
00:27:02
written a single line of code who were
00:27:04
able to contribute on this level and
00:27:06
understand this
00:27:08
that's a good thing when you achieve
00:27:10
that
00:27:12
now let's go further into the definition
00:27:15
part
00:27:17
away
00:27:19
that gives you a checkpoint is then the
00:27:22
boundary context design canvas again
00:27:24
posted on the DDD crew GitHub site
00:27:27
available as various templates PDF HTML
00:27:31
my row whatever yeah and this helps you
00:27:35
in asking questions about the module so
00:27:37
what's the purpose
00:27:40
what terminology is in here roughly
00:27:42
which rules do we have in it which
00:27:45
communication goes into that module what
00:27:48
communication goes out of that module
00:27:50
this helps you in asking questions and
00:27:53
in the end after you've done that you
00:27:54
also have a very decent piece of
00:27:56
communication of documentation for your
00:27:58
module as well yeah so you can fill this
00:28:02
out yeah the the domain message slow
00:28:04
example which I've shown you before can
00:28:06
look like that in a uh in a boundary
00:28:09
context canvas and now think about
00:28:11
cohesion you can run a next check on
00:28:15
your modularity maybe you can dissect
00:28:18
certain swim Lanes where you have a
00:28:21
strict separation in terms of inbound
00:28:24
communication language rules outbound
00:28:27
communication if you identify that you
00:28:30
may have a good candidate for splitting
00:28:32
this context up into two contexts
00:28:35
yeah so that you can also play some
00:28:37
games on that yeah with questions yeah
00:28:40
so we split this up into an application
00:28:43
entry context and an application check
00:28:45
context and so that's very nice stuff
00:28:49
now so far
00:28:51
we've done that and we have our bonded
00:28:54
context candidates those are candidates
00:28:56
for
00:28:58
big modules in a modolithic application
00:29:02
or a well-designed monolith I don't
00:29:05
consider a monolith to be a bad thing
00:29:07
per se yeah so if you have a very nice
00:29:10
modular monolith those are your
00:29:13
candidates there those are also
00:29:15
candidates for microservices
00:29:17
self-contained systems so core screen
00:29:19
modules now let's dig into them and
00:29:23
check out the aggregates
00:29:25
yeah
00:29:26
this is everything from here on yeah is
00:29:31
already moving heavily into code now
00:29:33
yeah this is a movement where we really
00:29:37
get to implement things and everything
00:29:39
from here on is inside of a bounded
00:29:43
context so finer grain modules within a
00:29:47
microservice within a module or a
00:29:50
vertical slice of a monolithic monolith
00:29:54
or something like that yeah
00:29:55
now there are a bunch of patterns in the
00:29:58
Tactical design world yeah in the
00:30:00
Tactical domain term design world
00:30:03
um I won't go into detail over all of
00:30:05
them but I want to quickly talk about a
00:30:08
bunch of patterns entities value objects
00:30:11
and Aggregates because they are the
00:30:12
important ones in terms of modularity
00:30:15
it is represent Core Business objects
00:30:18
with behavior that have a constant
00:30:20
identity and their own life cycle and a
00:30:23
quick note here your jpa entity is not a
00:30:27
domain entity not a DDT entity even if
00:30:31
some folks claim that the jpa entity is
00:30:34
a data model
00:30:36
it represents usually a table in a
00:30:39
database
00:30:40
some ideas in jpa have been inspired by
00:30:43
that but this is about domain Behavior
00:30:45
yeah and not about database separation
00:30:49
of concerns what we want to model here
00:30:51
is domain concerns and not database
00:30:53
concerns
00:30:55
the same goes for the value object yeah
00:30:57
they derived their their identity from
00:31:01
their values which they have so
00:31:04
let's say I sell this presenter for 100
00:31:07
euros I won't because I need it
00:31:11
um
00:31:11
I don't care with which hundred euros
00:31:14
you pay me that presenter with I just
00:31:16
want 100 euros and they also don't have
00:31:20
their own life cycle
00:31:22
so usually when I say okay it I I I put
00:31:26
a new price tag on it 80 Euros I removed
00:31:28
the old price tag 100 I put a new one on
00:31:31
that value objects are always immutable
00:31:33
yeah
00:31:35
um
00:31:36
they are also supposed to cons contain
00:31:39
business logic in here
00:31:42
so usually when we model in a boundary
00:31:45
context like that we end up with rather
00:31:47
big object graphs
00:31:49
yeah they tend to be some a little bit
00:31:51
error-prone sometimes yeah we have
00:31:53
haven't we all seen that yet you changed
00:31:55
something at one end of your code base
00:31:58
and at a totally different end of the
00:32:00
code base boom a bug pops up and you
00:32:02
wonder whoa how could that happen maybe
00:32:04
propagate it a little bit and those
00:32:07
Aggregates help you in grouping those
00:32:09
entities and value objects together
00:32:13
yeah
00:32:14
and there are some special things
00:32:16
each aggregate
00:32:19
um contains the so-called root entity
00:32:21
which is a special thing first of all
00:32:25
it's the only allowed entry point and
00:32:28
reference point to the aggregate
00:32:30
think about loose coupling
00:32:35
usually I put my Aggregates into a
00:32:38
package on a code level package
00:32:40
and there is only one class with a
00:32:43
public visibility that's the root entity
00:32:45
everything else all other entities all
00:32:48
other value objects are packaged private
00:32:51
so everything from the outside can only
00:32:54
access the root entity we limit coupling
00:32:57
points with that yeah
00:32:59
information hiding yeah the next thing
00:33:03
the root entity is responsible for the
00:33:05
life cycle of the complete aggregate so
00:33:08
it contains the life cycle and the third
00:33:10
thing it should act as a facade like the
00:33:13
facade design pattern it should offer
00:33:15
inside a boundary context for that
00:33:18
context some higher valuable business
00:33:21
logic some business capabilities within
00:33:23
that boundary context
00:33:24
Pro tip never have direct references
00:33:27
between your aggregates never they
00:33:30
shouldn't know each other
00:33:32
so
00:33:33
who know who who has read about this
00:33:35
principle of corner sense
00:33:37
maybe in the refactoring world so yeah
00:33:40
Connor sense means Connor sense is a
00:33:42
principle in software engineering that
00:33:44
says that two
00:33:47
components classes or whatever are
00:33:49
constant when you need to change both so
00:33:53
that the complete system is able to work
00:33:57
indicator for a high degree of coupling
00:33:59
I don't want my Aggregates to be
00:34:02
constant
00:34:04
usually I want to be able to change them
00:34:07
independently of each other and thereby
00:34:10
we say okay don't build direct
00:34:12
references between them no now they
00:34:16
usually
00:34:17
encapsulate the main Concepts by
00:34:19
grouping invariants those are business
00:34:22
rules that need to run together in a
00:34:24
consistent fashion they contain Behavior
00:34:27
yeah now you may wonder
00:34:30
how do I now go ahead and identify
00:34:35
Aggregates what are good candidates for
00:34:37
identifying aggregate boundaries
00:34:41
there is another type of events I mean
00:34:43
you can use eventually for that there is
00:34:44
a type called design level event Stone
00:34:47
which is a little bit more complex than
00:34:49
the one which I've shown you
00:34:52
a little bit bigger yeah let me quickly
00:34:55
guide you through this
00:34:57
so usually you have a starting point now
00:34:59
we have this application submitted which
00:35:02
was a pivotal event we do something
00:35:04
against some external systems and then
00:35:07
we have this pre-scoring performed red
00:35:09
and green so we're in the scoring
00:35:11
bounded context of our big example where
00:35:13
we want to score a credit application
00:35:15
now the first question you ask the
00:35:17
domain experts you want to talk to your
00:35:19
domain experts with that
00:35:21
what kind of business rules are there
00:35:25
where we can determine if pre-scoring
00:35:28
was performed red and green
00:35:31
tell me the rules
00:35:34
what's there and then they start
00:35:36
explaining yeah well there's a rule if
00:35:38
there's more than 120 points it's green
00:35:41
if there is a no-go criteria it's red
00:35:44
and so on and you write down all of
00:35:47
those rules on yellow cards
00:35:51
heuristic when your domain experts laugh
00:35:55
at you and tell you hey it's totally
00:35:57
impossible to write down all the
00:36:00
business rules for that boundary context
00:36:03
your boundary context is probably too
00:36:06
big
00:36:06
yeah it's too core screen maybe you want
00:36:10
to split this up yeah but you write down
00:36:12
all the rules and then you ask the
00:36:15
domain experts hey how would you group
00:36:17
those rules
00:36:18
are there any ways to group these rules
00:36:20
which rules have to run together in a
00:36:23
consistent fashion and so on the one
00:36:25
hand we can go for points no-go criteria
00:36:28
and determination of a scoring result
00:36:31
another perspective can be yeah we have
00:36:33
the determination of a scoring result
00:36:35
but no we we have something that scores
00:36:38
the real estate financing something that
00:36:41
scores the monthly cash flow the
00:36:43
applicants or some credit agency results
00:36:46
yeah
00:36:47
now
00:36:49
what's the right grouping here
00:36:54
everything is right every grouping is
00:36:57
right
00:36:58
Alan holup a very smart guy from the
00:37:01
agile Community a guy whom I really
00:37:03
appreciate once said the key to an
00:37:05
incremental architecture is to build on
00:37:07
a framework that can accommodate change
00:37:09
that framework is the domain by modeling
00:37:12
the domain you can more easily handle
00:37:15
changes to the domain now what we want
00:37:18
to get is the perspective on the domain
00:37:21
from the domain experts now from which
00:37:24
perspective do they look at this scoring
00:37:27
stuff
00:37:28
because from that perspective
00:37:31
they will also always give us new
00:37:34
feature requests they don't come out of
00:37:36
nothing your domain experts and your
00:37:38
business folks they're not sitting in
00:37:40
their office and talking in their daily
00:37:42
stand-up oh how can we torture our
00:37:45
developers today
00:37:47
no they don't wake up like that yeah no
00:37:50
the the new requests the changes that
00:37:52
they do they come from a certain
00:37:53
perspective and I want to have this
00:37:56
perspective in code
00:37:57
yeah so let's go for that
00:38:00
yeah these groups they are get great our
00:38:03
domain experts say that's the grouping
00:38:05
that we have
00:38:06
from my own experience
00:38:08
this is the biggest biggest
00:38:13
thing that you can do in terms of
00:38:15
maintainable code
00:38:17
you can't do as much of clean code
00:38:19
practices and whatever as much as you
00:38:22
want
00:38:23
when this stuff doesn't match the
00:38:25
perspective of the domain experts every
00:38:27
new feature requests will be a wrestling
00:38:31
yeah
00:38:33
I've seen that countless times happening
00:38:35
and now mind the difference please in
00:38:37
classical object oriented analysis and
00:38:41
design ooad yeah
00:38:44
there is a we start I I still remember
00:38:47
when I was at University we had a book
00:38:50
that said okay first of all look for
00:38:52
nouns
00:38:53
those are your classes
00:38:55
then look for attributes
00:38:58
and after that look for the methods
00:39:01
what have we built with that very very
00:39:05
often
00:39:06
data models
00:39:09
and not domain models
00:39:11
from that perspective we are very often
00:39:13
see classes and modules private
00:39:15
attribute private attribute private
00:39:17
attribute and then comes the shortcut
00:39:20
from the Gates of Hell generate public
00:39:23
Getters and set it and don't even get me
00:39:25
started with lombok yeah
00:39:28
[Music]
00:39:28
um
00:39:29
yeah
00:39:32
this is an endemic domain model then
00:39:34
never all the behavior is in some
00:39:36
services with really ugly hard to read
00:39:40
code yeah and DDD starts from a
00:39:43
different perspective we start with
00:39:44
behavior first yeah I haven't talked
00:39:47
about data at all yet no we we thought
00:39:51
about how do we group the rules
00:39:54
how do we derive model boundaries from
00:39:56
that and so on and what this does
00:39:59
basically this grouping of the rules
00:40:01
that we have there are aggregate
00:40:03
boundaries
00:40:04
yeah they are good candidates for
00:40:06
Aggregates and then yeah this is then a
00:40:09
full picture I won't go into a lot of
00:40:11
detail here because I I don't have uh
00:40:14
the time for that I could talk three
00:40:16
days about that stuff no problem
00:40:19
um
00:40:21
you can then go ahead and think which
00:40:23
commands do we need for those rules
00:40:26
what data do those rules need so I
00:40:30
derived the data demand from the rules
00:40:33
and which events do they publish
00:40:36
quick hint to the German speaking folks
00:40:39
here there is a talk
00:40:41
of Me on YouTube I know there are many
00:40:43
Germans at that conference in German the
00:40:46
ghost that talks alone one hour about
00:40:48
this thing yeah so
00:40:51
um
00:40:51
check this out that's really good stuff
00:40:54
and let me quickly go back to another
00:40:57
thing here you remember this
00:41:01
um ubiquitous language idea yeah let me
00:41:04
go back to one slide yeah to this one
00:41:07
here you remember this and it also said
00:41:11
then I wanna see
00:41:14
that language in the code
00:41:17
let me quickly give you a quick hint
00:41:19
which just popped out in my head
00:41:23
question
00:41:24
what can you do code wise when you're at
00:41:27
that stage of a design level event
00:41:29
stomach do you have any ideas
00:41:36
the idea also contains 2DS not DDD but
00:41:42
tdd I mean you can start writing unit
00:41:46
tests for each of those rules
00:41:49
now when you write those unit tests try
00:41:52
to reflect the language on these cards
00:41:56
in the test methods
00:42:00
when you have successfully grouped your
00:42:03
rules when you have decided yeah for
00:42:06
which grouping you go for which
00:42:08
Aggregates you regroup your unit tests
00:42:12
and a very nice thing I I sometimes do
00:42:15
that with customers and I show The
00:42:17
Domain experts the code of the unit
00:42:20
tests
00:42:21
just plain unit testing no Behavior
00:42:25
driven cucumber whatever stuff just the
00:42:28
unit test
00:42:29
when your domain event experts are able
00:42:32
to read the tests for these you're doing
00:42:36
a pretty good job in terms of ubiquitous
00:42:39
language and do not underestimate the
00:42:42
motivating character this has on
00:42:44
business folks sometimes business folks
00:42:46
are scared of I.T yeah because they hear
00:42:49
all our slang kubernetes k-native spring
00:42:52
Boots Spring data whatever yeah oh
00:42:54
what's that what kind of language do
00:42:56
they talk
00:42:58
this gets you in a good conversation in
00:43:00
a meaningful conversation and when they
00:43:02
see oh
00:43:04
I went
00:43:05
go home to the families and they say hey
00:43:07
I read code and I understood that they
00:43:10
they feel yeah we hear these digital
00:43:13
Natives and so on yeah or a Karma
00:43:16
account yeah they feel like they've
00:43:18
become 10 more digital and yeah I'm I'm
00:43:22
choking a bit here but this is super
00:43:24
motivating for many folks and this leads
00:43:26
to a better collaboration between
00:43:28
developers and business folks and that's
00:43:30
what we want to have here and then yeah
00:43:32
let me quickly move here those blue
00:43:35
cards those commands they are the apis
00:43:38
of your Aggregates they are the public
00:43:44
methods of the aggregate not get set get
00:43:47
set get set blah no
00:43:50
this is a meaningful API that we have
00:43:53
there
00:43:54
which contains business stuff
00:43:58
I like this approach however
00:44:00
um I don't wanna want this to be a plain
00:44:04
uh marketing session here for DDD let me
00:44:07
quickly talk about some challenges I'll
00:44:10
remove the I'll make that black up
00:44:14
doesn't work
00:44:15
um
00:44:16
so first challenge this whole domain
00:44:18
room design thing is tailored at complex
00:44:22
stuff
00:44:23
when you don't have complexity this is a
00:44:26
total Overkill don't do it yeah
00:44:30
yeah it's not a silver bullet a good
00:44:32
friend of mine yogmada once wrote on
00:44:34
Twitter a good developer is like a
00:44:36
werewolf afraid of silver bullets and
00:44:39
that's true this is not a silver bullet
00:44:41
this aims at complex stuff and not
00:44:45
trivial stuff which you can Implement
00:44:47
with Ruby on Rails or whatever yeah and
00:44:51
um
00:44:52
I can do that at a spring conference
00:44:54
yeah
00:44:56
um but I'm a big Ruby on race fan I have
00:44:58
to admit yeah and don't boom me and
00:45:00
throw me off the stage here yeah
00:45:03
um and also
00:45:05
all these workshops you will need to
00:45:07
exercise them and especially this design
00:45:09
level events I mean that's not trivial
00:45:11
so maybe you want to add a facilitator
00:45:13
to that who stoned that quite a few
00:45:15
things who helps you with the method but
00:45:17
make sure that you get educated
00:45:20
on the method you can do that on our on
00:45:23
your own maybe you start off with
00:45:24
something super trivial hey let's event
00:45:26
Storm the Red um the purchase of a plane
00:45:31
ticket or reservation of a seat in a
00:45:33
cinema
00:45:34
trivial stuff so that you get fluent
00:45:37
with that and be prepared to make
00:45:39
mistakes
00:45:40
domain room design is about continuous
00:45:43
learning and continuous learning
00:45:45
involves making mistakes
00:45:47
and that's also the reason why this DTD
00:45:49
starter modeling process has so many
00:45:51
iteration errors arrows you need to
00:45:55
iterate your first drafts will not be
00:45:58
the perfect thing and make sure that
00:46:00
your management has the right
00:46:02
expectation on that this is an iterative
00:46:05
process that you want to do again again
00:46:08
again and again
00:46:10
you may want to do that in areas that
00:46:12
are
00:46:14
differentiating for your business and
00:46:16
not in totally generic stuff because
00:46:18
this is also expensive
00:46:20
yeah
00:46:21
all right
00:46:22
that's it from my side
00:46:25
um so who's interested can check out my
00:46:27
DDD book I also do DDD trainings and
00:46:30
Consulting if you're interested in that
00:46:33
um it's always a pleasure to be at
00:46:35
Spring IO I think that's my fourth or
00:46:37
fifth time at the conference always nice
00:46:40
to be in Barcelona so we have some
00:46:43
minutes for some questions
00:46:46
but I'll also be around until the mid
00:46:49
afternoon so you can hook me hit me up
00:46:51
at the uh somewhere in the whole room
00:46:54
and thanks a lot for your interest
00:46:57
thanks for having me
00:47:03
thank you
