►
From YouTube: Jakarta Tech Talk | Applied Domain-Driven Design Blueprints for Jakarta EE | January 12, 2022
Description
Domain-Driven Design (DDD) is an architectural approach that strongly focuses on materializing the business domain in enterprise software through disciplined object-oriented analysis. This session demonstrates first-hand how DDD can be elegantly implemented using Jakarta EE via an open source project named Cargo Tracker.
Cargo Tracker maps DDD concepts like entities, value objects, aggregates and repositories to Jakarta EE code examples in a realistic application. We will also see how DDD concepts like the bounded context are invaluable to designing pragmatic microservices.
____
Jakarta EE gives developers a comprehensive set of vendor-neutral, open specifications that are used for developing modern, cloud native Java applications from the ground up. With Jakarta EE, technology developers and consumers can be confident they have the best technologies for developing cloud native, mission-critical applications. And they can build on decades of Java developer expertise to move existing workloads to the cloud.
Learn more: https://jakarta.ee/
Follow us on Twitter: https://twitter.com/home
Follow us on LinkedIn: https://www.linkedin.com/showcase/jakartaee/
Like us on Facebook: https://www.facebook.com/JakartaEE/
A
Hello,
everyone
and
welcome
to
another
jakarta
tech
talk
joining
us
today.
We
have
reza
raham
to
present
on
applied
domain
driven
design.
Blueprints
for
jakarta
ee
reza
is
a
large
plays
a
large
role
in
the
java
and
jakarta
ee
industry.
Reza
is
a
former
long-time
independent
consultant
enterprise,
architect
and
java
ee
evangelist
at
oracle
and
is
now
a
principal
manager
for
java
on
azure
at
microsoft.
B
Okay,
so
wherever
you
are
good
morning
good
afternoon
good
evening,
maybe
depending
on,
if
you're
in
the
in
the
asia
pacific
region
or
not
so
yeah,
so
this
is
applied.
Domain
driven
and
design
blueprints
for
jakarta
there's
a
couple
of
different
ways.
I
can
actually
do
this
talk,
but
principally
this
talk
is
about
how
jakarta
aligns,
with
basically
popular
design
patterns
and
design
paradigms
like
domain
driven
design.
B
So
in
my
day,
job.
Yes,
I'm
principal
program
manager
for
java
on
azure,
but
actually
this
particular
talk
doesn't
have
much
to
do
with
my
day
job,
principally
I'm
presenting
today,
mostly
as
a
jakarta
ambassador.
Hopefully
you
can
go
find
out
a
bit
more
about
what
the
jakarta
ambassadors
are
on.
Screen,
of
course,
is
all
of
my
contact
information,
also
not
that
hard
to
get
a
hold
of.
B
So
there's
a
couple
of
different
ways:
we
can
go
about
doing
this
talk.
I
want
to
make
sure
to
explain
the
motivation
for
this
talk
a
little
bit
and
then
have
a
little
bit
of
a
dialogue
with
you
guys
to
see
you
know
how
best
we
can
take
advantage
of
the
hour
or
so
that
we
have
in
our
hands.
So
I
think
we
all
are
probably
mostly
familiar
with
the
so-called
j2e
blueprints
or
java
pet
store.
B
A
B
It
was
honestly
complete.
Chaos
like
every
single
project
would
have
its
own
design
paradigms.
None
other
projects
would
look
very
similar
at
all
if
you're
lucky,
there's
there'll
be
some
kind
of
architecture.
In
many
cases
it's
like
embedded
code
in
written
in
jsps
and
the
like.
So
it
was
honestly
not
a
very
maintainable
situation,
so
we
needed
to
get
some
kind
of
structure
around
that
and
and
the
answer
to
that
back
in
the
day
from
sun
was
this
thing
called
j2e
blueprints
or
java
pet
store
and
what
they
basically
did
was
they
said?
B
B
So,
even
today,
if
we
are
using
things
like
dtos
and
factories
and
dios
or
facades
or
anything
else
like
that,
chances
are
really
what
you're
really
doing
is
implementing
those
very
ideas
that
were
first
shown
in
action
and
put
in
and
put
into
the
mainstream
by
the
java
pet
store
or
j2e
blueprints.
Now.
The
reality
is
that
the
jta
blueprints
had
its
health's
own
problems.
As
such,
it
was
not
a
problem
with
the
project
itself
as
much
as
it's
the
immaturity
of
the
technology.
B
So
back,
then
it
was,
you
know,
ejb2
entity,
beans
and
session
beans,
and
maybe
even
not
that
and,
as
you
know,
all
of
those
technologies-
that's
had
limitations
right.
Understandably,
it's
very
early
days
of
server-side
java
development.
So
all
of
those
things
you
know
transposed
into
the
java
pet
store,
all
of
the
things
that
are
weaknesses
in
the
technology
said
ultimately
surfaced
as
either
design
patterns
to
work
around
it
or
limitations
in
the
architecture.
B
So
the
answer
to
those
problems,
as
we
all
know
ultimately,
was
spring
and
pojo
based
programming
and
hibernate,
as
opposed
to
as
opposed
to
entity
managers,
and
you
know
obviously,
from
the
java
e
side
instead
of
game
annotations
instead
of
xml,
you
know
early
version
of
that
was
x
doclet.
I
still
remember
using
x,
doclet
with
j
to
e,
so
basically
the
as
the
industry
matured.
We
realized.
B
B
B
So
you
come
up
with
slightly
different
semantics,
a
slightly
different
set
of
design
patterns,
but
really
a
radically
different
way
of
thinking
as
opposed
to
what
what
what
was
possible
using
j2e
and
the
java
jt
blueprints
and
java
pet
store
and
we'll
see
some
of
those
differences
in
a
moment.
If
you
don't,
if
you
don't
know
what
I
mean
but
the
reality,
though,
for
me
was
that
you
know
for
java
e5
onward
right,
you
basically
could
apply
domain-driven
design
perfectly
well,
in
fact,
quite
well.
B
B
So
that
is
how
the
cargo
tracker
project
came
out
to
be
so,
it
was
supposed
to
be,
frankly
speaking,
a
replacement
to
the
java
pet
store,
showing
you
this
new
and
better
design
paradigm
and
design
patterns
on
how
to
apply
them
using
jakarta.
So
it
was
part
of
the
official
blueprints
for
java
ee.
So,
as
for,
as
you
all
know,
you
know
the
whole
thing
moved
to
the
eclipse
foundation.
B
So
with
that,
I
also
helped
move
the
cargo
tracker
project
back
into
the
eclipse
foundation
as
well,
not
obviously
as
a
spec
project,
because
this
is
not
a
spec
but
basically
as
as
as
a
part
of
the
jakarta
umbrella.
So
this
is
part
of
the
ee4j
project
set
of
projects
and
basically
it's
one
of
these
projects
that
sort
of
goes
hand
in
hand
with
the
with
the
jakarta
specification
and
platform
and
implementation
projects
and
the
like.
B
So
that's
a
bit
of
so
basically,
what
we'll
do
today
is
give
you
an
introduction
of
cargo
tracker
in
a
manner
of
speaking
right.
So
when
I
go
to
do
this
presentation,
what
I
often
find
is
people
actually
even
10
years
on
now,
a
lot
of
people
actually
don't
really
understand
what
domain
driven
design
is,
and
that's
where
I
need
to
fi.
I
find
myself
starting
with
this
presentation,
instead
of
focusing
more
on
how
to
map
domain
driven
design
concepts
into
jakarta.
B
So
it's
a
delicate
balance
that
I
always
you
know
wind
up
encountering
when
when
I'm
doing
this
talk
and
in
fact
even
even
explaining
cargo
even
demonstrating
cargo
tracker,
I
often
run
into
the
same
issue
that
you
can't
really
even
assume
that
people
know
or
even
understand,
remain
driven
design
later
on.
You
know
how
to
apply
it
in
jakarta.
So
that's
where
I
tend
to
start
in
this
talk,
but
there
are.
There
have
been
situations
where
you
know.
I
have
encountered
people
that
say
yeah.
I
know
domain
driven
design.
B
You
know
I've
read
the
book
by
by
eric
evans
and
I've
done
some
research
on
my
own.
All
I
really
need
to
know
is
hey.
How
do
I
apply
this
in
in
a
environment?
Show
me
the
actual
implementation,
no
need
to
explain
the
actual
concepts
behind
remainder
and
design,
so
that
is
sort
of
a
forking
point
of
how
I
can
approach
this
talk
right.
So
we
can
skip
over
the
domain
driven
design
introduction.
B
But
if
we
do
not,
then
I
I
will
actually
need
to
spend
at
least
half
or
more
of
my
time
today
explaining
what
domain
driven
design
is
and
explaining
the
fundamental
some
of
the
fundamental
design
patterns
in
domain
driven
design.
So
before
we
start
I'd
like
to
do
two
things
number
one
I'd
like
to
tell
you,
there's
no
need
to
hold
questions
until
the
very
end.
You
know
I
try
to
keep
this
talk.
In
fact,
I
hope
all
of
my
talks
fairly
conversational.
B
B
You
know
intermittently
check
there'll,
be
natural
pause
points
in
during
the
talk
where
I
can
do
that,
and
I
can
check
to
see
what
questions
you
have
and
I
can
answer
your
questions
or
you
can
use
this
q
a
little
q
and
a
function,
that's
also
in
in
crowdcast.
I
think
it's
a
little
bit
more
clungy
to
use,
but
you
can
feel
free
to
use
that
also
and
again
I'll
check
that
and
answer
your
questions
as
we
go.
So
that's
number
one
number
two
is.
B
I
really
would
like
your
help
to
help
you
to
better
understand
how
I
can
help
you
today.
So,
as
I
said,
there's
a
couple
of
different
approaches
of
taking
this
talk.
So
here's
what
I
would
like
you
to
do
in
the
chat,
if
you
would
like
me
to
explain-
would
start
with
an
explanation
of
ddd
before
we
jump
into
cargo
tracker
just
type
in
ddd.
B
If
you
would
like
me
to
skip
the
dd
portion
and
focus
more
on
how
ddd
applies
to
jakarta,
just
type
in
jakarta
e,
so
I'll
give
it
I'll
give
you
guys
a
few
minutes
to
think
about
it.
Please
do
me
a
favor
and
do
type
in
your
preference
of
how
we
can
approach
the
next
hour,
so
50
minutes
or
so
actually,
45
minutes
or
so
now
so
yeah,
please
go
ahead
and
do
that
and
then
I
will
sort
of
tailor
the
talk
accordingly.
B
B
B
B
Nobody
for
a
tie,
breaker
all
right.
I
think
we
have
a
tiebreaker,
so
I
think
let's
stop
there.
You
know,
as
I
sort
of
as
it
turns
out
almost
always
in
this
talk.
You
know
people
don't
really
know
ddd
that.
Well,
however,
it's
it's
a
close
tie,
so
here
here's
what
I'm
gonna
do
I'll
spend
some
time
on
ddd,
but
not
too
much
I'll
I'll.
B
What
is
the
thing
and
then
sort
of
have
a
refresher
in
your
mind
as
well,
so
we'll
we'll
explain,
dd
a
bit
and
then
we'll
move
on
on
to
as
quickly
as
we
can
to
the
jakarta
e
mapping
portion
of
the
talk
okay.
So
what
is
ddd
exactly
I've
sort
of
given
away
the
explanation
of
that
a
bit?
So
ddt
really
is
nothing
much
more.
B
The
expansion
of
it
is
domain-driven
design.
So
the
idea
here
is
that
your
implementation
and
your
application
should
look
like
the
real-world
thing
that
you're
trying
to
implement
whether
it's
a
database
field
or
name
of
a
table
or
name
of
a
schema
or
name
of
objects
in
your
software
screen
names
url,
so
on.
All
of
these
things
should
map
to
things
that
are
there
in
the
real
world.
B
In
fact,
the
idealized
view
of
domain
driven
design
is
that,
if
you
were
to,
you
know,
go
over
your
your
architecture,
design,
diagram
or
uml
diagram
or
database
schema
with
somebody
in
the
business.
They
ought
to
be
able
to
understand
what
the
thing
is,
so
the
names
should
be
very
similar
and,
in
general,
things
should
attempt
to
model
the
way
thing.
The
actual
business
domain
that
you're
trying
to
trying
to
accomplish,
and
the
reason
this
matters.
B
B
So
there
is
a
fundamental
philosophy
behind
domain-driven
design.
It's
sometimes
it's
called
the
ubiquitous
language,
so,
in
other
words,
whatever
language
you
are
using
to
express
yourself
in
code
should
model
the
the
language
that
you
are
using
when
you
are
discussing
things
with
your
business
analyst
or
even
your
your
end
users,
if
you
will
so
with
that.
With
that
view
in
mind,
what
happens
is
what
comes
out
of
that
is
certain
design
patterns,
same
the
same
as,
as
is
the
case
with
the
j2e
design
patterns
or
gang.
A
B
Design
patterns,
what
comes
out
of
that
other
than
a
philosophy
and
an
end
goal
of
end
objective
of
what
you're
trying
to
do
is
these
common
things,
common
common
patterns
that
you
ought
to
apply
in
in
your
in
your
applications?
So
this
is
I'll
in
order
to
explain
this.
What
I'll
do
is
I'll
I'll
simply
take
one
of
these
well-known
diagrams
that
are
out
there?
I
won't.
I
won't
invent
anything
because
there
is
no
need
to
that
was
actually
part
of
the
reason
why
I
why
I
decided
and
decided
to
do.
B
Cargo
tracker
is
just
to
simply
leverage
the
knowledge
that
is
already
out
there
in
the
domain
driven
design
field
and
simply
reference
it
right.
So
I'll
do
the
same
thing
here.
So
this
is
a
well-known
diagram
that
basically
explains
to
you.
What
the
fundamental
building
building
blocks
are
another
way
of
looking
at
this
is
what
are
the
key
design
patterns
in
into
pen
driven
design.
So
we'll
talk
a
little
bit
about
what
these
are.
B
B
An
entity
is
a
thing,
it'll
be
a
noun
in
the
in
the
real
world.
An
entity
has
a
few
things.
It
has
certainly
a
unique
identity.
It's
uniquely
identifiable,
if
you
want
to
think
about
it
in
terms
of
relational
databases,
it's
basically
the
item,
the
id,
the
unique
id
for
a
row
and
in
your
table,
if
you
will,
and
in
in
the
object-oriented.
A
B
B
We
have
internal
states
and
in
every
single
machine
or
thing
or
process,
they
all
have
internal
states
data
that
represents
what
they
are
entities
also
have
behavior,
and
that
is
fundamentally
different
from
the
old
way
of
doing
things
in
doing
things
in
the
j2e
design
patterns
world.
So
things
do
things
in
in
in
the
real
world,
and
you
model
these
as
methods
that
ultimately
have
logic
as
well
as
behavior
to
change
the
internal
state
of
itself,
so
that
is
basically
the
methods
and
the
fields
of
of
an
object.
B
The
next
design
pattern
in
ddd
is
value
objects,
so
value
objects
and
entities
are
very
closely
related.
They
are
both
things
or
nouns
in
the
real
world
they
both
hold
hold
both
internal
state
as
well
as
behavior,
so
fields
and
methods.
The
difference
between
entities
and
value
objects
is
that
value
objects
do
not
have
identity
of
their
own
right.
B
They
sort
of
think
about
it
as
sort
of
helper
or
helper
things,
things
that
are
attached
to
other
things,
and
this
actually
reflects
the
fact
that
in
the
real
world,
things
are
related
to
each
other.
They
reference
each
other
and
basically,
entities
and
value
objects
often
have
a
have
a
it,
has
a
relationship
so
containing
relationship.
B
So
a
good
example
of
an
entity
would
be
an
employee,
let's
say
right,
so,
whereas
a
value
object,
a
good
example
of
that
would
be
an
address.
An
address
doesn't
necessarily
need
to
have
an
id
have
an
identity
of
its
own.
It's
simply
there
to
to
be
able
to
model
your
data
better
right,
so
each
employee
will
have
an
address
and
that
address
object
is
you
know,
nested
within
your
employee,.
A
B
So
it
doesn't
need
an
id
on
its
own,
so
next
concept
to
understand
in
ddd
is
aggregates
and
again
it
goes
back
to
the
fact
that
things
in
the
real
world
are
related
to
each
other,
and
often
what
happens
is
there
is
a
hierarchy
of
relationships,
so
some
objects
are
actually
more
important
than
others.
Some
nouns
are
more
important
than
others,
particularly
when
it
when
it
when
it
comes
to
domain
driven
designer
or
domain
modeling.
B
B
Debit
card,
so
these
are
all
will
be
all
objects.
But,
ultimately,
when
you
go
to
model
these
objects,
some
objects
are
going
to
be
more
important
than
others
and
in
fact
more.
What
we
also
observe
is
that
in
these
relationships
there
are
sort
of
these
clusters
of
relationships
right.
So
you
have
these
top-level
important
on
important
entities
that
are
interrelated
to
a
lesser
set
of
important
entities
and
there's
a
few
of
these
right.
So
there's
a
number
of
these
here
and
there
so
again,
another
example
would
be
in
the
insurance
domain.
B
The
insured
and
the
policy
would
probably
be
if
you
will
important
entities
and
then
there'll
be
a
bunch
of
stuff
interrelated
to
those
particular
sub
entities.
If
you
will
so,
this
is
what's
known
as
an
aggregate.
Okay,
so
in
particular
a
particular
types
particular
entities
are
all
will
also
be
called
aggregate
roots.
For
this
reason
upon
the
the
entries
that
are
really
really
important
in
a
particular
domain,
next
is
repositories
so
again
in
when
you're
talking
about
systems.
B
As
we
all
know,
systems
mostly
consists
of
disk
and
memory
and
cpu
right.
So,
basically,
when
you
are
materializing
a
system-
and
it
is
run,
it
is
running,
it
will
be
mostly
consuming
memory
and
cpu,
but
the
other
thing
is.
It
also
needs
to
be
persistent
right.
So
all
of
this
data
that
you
have
that's
modeling,
the
real
world
ultimately
needs
to
reside
in
some
place
that
if
you
shut
down
the
computer
and
restart
it
it's
that
data
is
going
to
come
back
up.
B
A
B
This
is
the
purpose
of
the
of
the
so-called
repository,
so
this
is
the
other
design
pattern.
That
is
very,
very
important,
and
this
is
also
part
of
essentially
a
part
and
parcel
of
your
of
your
domain
model.
This
thing
called
repositories
and
repositories,
unlike
daos,
actually
relate
to
the
aggregate
route,
whereas
in
a
dia
world
you
will
tend
to
have
dta
dios
per.
B
So
for
the
most
part,
when
you're
constructing
these
these
objects,
your
object
model
in
in
the
application.
You
can
mostly
get
away
with
just
invoking
new
a
few
times
and
then
calling
a
bunch
of
setters
and
you're
good
to
go.
But
in
some
cases,
though,
it's
not
as
simple
as
that
right.
So
if
you're
creating
you're
going
to
create
an
aggregate
and
in
the
creation
process
itself,
there
is
business
logic
and
it
seems
to
be
relatively
non-trivial.
B
The
way
you
abstract,
the
creation
process
of
of
those
objects
or
or
entities
in
the
system
is
to
is
to
basically
create
this
object,
called
a
factory
and
whose
job
principally
is
just
to
create
help
create
these
complex
objects.
So
this
is
a
gang
of
four
design
pattern
that,
by
the
way,
also
exists
in
jte
design
patterns
and
is
basically
imported
into
the
into
the
domain
driven
design.
B
World
there's
also
services
and
services
are
a
little
bit
tricky
because
when
and
and
this
is
because
maybe
they
could
have
found
a
better
name
for
it.
So
services
is
not
restful
services
or
soap
services,
or
anything
else
like
that.
In
this
context,
those
things
in
in
the
domain
driven
design
world
is
actually
part
of
the
interface
layer
and
we'll
talk
about
that.
In
a
moment,
this
is
what's
called
domain
services.
So
not
everything
in
the
real
world
is
actually
a
thing.
B
B
Okay,
this
is
actually
a
process,
it's
more
of
a
verb
than
a
thing.
Similarly,
in
logistics,
one
thing
that
probably
is
very
very
important
is
scheduling,
so
these
are
basically
verbs
that
are
important
enough
to
be
modeled
outside
of
entities
sort
of
as
top-level
parts
parts
of
parts
of
the
domain-
and
this
is
what
we
mean
by
by
domain
services
and
domain
services
typically
will
be
just
a
single
thing
right.
It's
a
it's
a
complex
enough
business
object
that
warrants
its
own
top
level.
B
B
You
know
in
in
our
in
our
application
as
well
so
aside
from
that
there's
a
bunch
of
other
concepts,
layered
architecture
which
we'll
talk
about
in
a
moment
and
and
of
course,
domain
modeling
or
object-oriented
analysis
is
driving
all
of
this
stuff,
and
this
can
be
either
upfront
design
or
more
typically,
it's
evolutionary
design.
So
you'll
come
up
with
some
ideas
as
you
are
implementing
it
and
then
you'll
refine
them
as
you
go
okay.
B
B
No,
I'm
gonna
assume
no
okay,
all
right!
Well,
if
you
do
come
up
with
questions,
you
can
ask
them
a
bit
later.
It's
not
a
big
deal,
and
also
you
can
ask
me
later
on
as
well.
Okay.
So
when
you
are
talking
about
designing
these
applications,
you
have
your
nice
domain
model,
but
you
actually
need
something
a
bit
more
than
that
and
what
you
need
is
a
way
of
separating
concerns.
B
I'll
explain
why
so,
let's
assume
for
a
second
that
all
you
had
is:
is
this
domain
model
with
the
with
the
design
patterns
that
I
talked
about
before,
and
that
is
the
heart
of
domain
driven
design?
If
you
will,
what
will
tend
to
happen
is
that
you
will
get
really
bloated
entities
for
the
most
part.
The
reason
is
that
you'll
find
that
you're
adding
more
and
more
functionality,
that's
not
related
to
business
logic
per
se
and
not
even
related
to
the
domain.
B
B
I've
seen
these
these
sorts
of
things
where
people
have
this
real
resistance
to
adding
this
other
concept
called
layering
and
separation
of
concerns,
and
as
a
result,
they
wind
up
with
these
huge
entities,
and
then
they
are,
if
you
will,
a
new
verb
become
a
new
version
of
that
jumbled
code
inside
of
jsps.
If
you
will
so
the
way
you
solve
this
problem
is
the
same
way
that
we've
solved
the
jsp
problem,
namely
separating
the
presentation
concerns
from
the
java
concerns
and
in
most
server-side
applications.
These
concerns
are
actually
relatively
common.
B
They
don't
differ
very,
very
much
so.
This
is
why
you
should
really
consider,
in
addition
to
doing
domain,
driven
design,
considering
also
this
optional
part
of
domain
driven
design,
and
that
is
layering.
Okay,
so
in
server-side
applications
there
tend
to
be
these
layers
right
and
they're
relatively
prescriptive.
B
So,
first
and
foremost
you
have
the
interface
layer,
and
this
has
to
do
with
io,
essentially
or
user
input,
output
or
ux
in,
in
other
words.
So
these
are
they'll,
be
things
like
you
know,
your
your
web
application
framework
or
your
javascript
fancy
javascript
framework,
your
rest
interfaces
that
talk
to
that
fancy.
Javascript
framework,
maybe
system
to
system
communication
interfaces
like
batch,
for
example,
these
all
belong
in
in
the
so-called
interface
layer,
so
you
should
have
objects
that
are
dedicated
to
concerns
of
the
of
the
interface
layer.
B
That's
that's
the
idea
here.
Next
level
down
is
the
application
layer,
and
this
basically
has
echoes
of
how
we
used
to
do
things
in
in
in
the
j2e
blueprints
way
of
doing
things.
So
these
are
basically
objects
that
model
model
high-level
use
cases
in
your
application,
so
these
are
mostly
verbs
actually.
So
this
is
a
a
high
level
object
that
maps
to.
If
you
will
a
subsystem
right
in
in
your
application
that
has
these
behaviors
that
are
very,
very
coarse-grained.
B
Each
of
these
behaviors
will
be
invoking
multiple
domain
objects,
potentially
domain
services,
entities,
value
objects
and
making
them
actually
work
in
a
sort
of
long
script.
If
you
will
so
this
is
what
what
is
known
as
you
can
think
of
this
as
a
facade,
if
you're
familiar
with
the
with
the
business
facade
architecture
blueprint
from
the
g2e
days.
This
is
the
same
thing
here,
so
this
is
of
a
an
abstraction
over
a
high-level
use
case
in
in
your
application,
and
you'll
have
smaller
numbers
of
these
smaller
number
of
the
of
these
application
services.
B
If
you
will
in
in
your
application,
the
next
level
down
is,
of
course,
the
domain,
and
that's
all
those
things
that
we
talked
about
before
entities
value
objects,
factories
repository
these
all
belong
in
in
in
the
domain
layer,
and
this
is
going
to
be
the
heart
of
your
application.
The
idea
here
is
that
you
can
throw
away
the
application
tier
you
can
have
different
application
tiers
all
together,
you
can
throw
away
the
interface
layer
altogether,
but
the
core.
B
Still
remains
basically
static
in
in
in
your
domain
model
and
encapsulates
how
your
real
world
modeling
or
your
application
should
really
look
like
aside
from
this.
We
have
this
cross-cutting
layer
called
the
interface
layer.
Rather
the
infrastructure
layer
and
the
infrastructure
layer
is
basically
anything
to
to
do
purely
with
application
framework
concerns
and
and
system
implementation
concerns.
B
In
fact,
this
is
where
java
e
really
shines,
because
a
lot
of
these
so-called
infrastructure
concerns
actually
are
baked
in
into
the
platform
itself
through,
in
many
cases,
declarative
annotation.
So
all
you
need
to
do
in
order
to
add
a
bit
of
infrastructure
is
just
take
your
you
know:
application
domain
or
interface
layer,
concern
and
just
add
an
annotation
to
it,
and
lo
and
behold,
what's
happening
is
you're
getting
a
bunch
of
infrastructure
services
without
really
realizing
them,
so
the
infrastructure
layer
can
actually
be
used
by
any
of
these
layers.
B
It's
not
a
distinct
layer
on
its
own.
These
are
distinct
parts
of
the
application,
so
you
will,
if
there's
a
something
that
you
are
implementing.
There
is
clearly
infrastructure.
It
will
belong
in
that
infrastructure
segment
and
and
it's
in
in
its
own
specialized
object
if
you
will,
but
they
can
be
consumed
by
any
parts
of
the
any
any
part,
any
layer
whatsoever.
Typically,
infrastructure
will
tend
to
be
consumed
at
the
application
layer,
but
it
can
also
be
implement
used
by
the
domain
layer.
B
B
Okay,
do
let
me
know
if
you're
all
set
and
I'm
gonna
basically
restart
back
where
we
stopped,
and
that
is
beginning
to
map
ddd
concepts
into
jakarta.
So
here's
a
here's,
a
little
diagram.
The
diagram
actually
is
on
the
website
as
well
as
well
as
the
documentation
and
cargo
tracker.
So
you
can
reference
this
later
and
by
the
way
this
slide
deck
is
also
available
in
on
speaker
deck.
You
can
just
google
it
and
you'll
find
it.
So
this
is
all
all
there
in
for
for
your
reference.
B
B
So
if
you're
in
implementing
java
batch-
and
you
have
these
artifacts,
like
readers,
writers
and
operators,
these
are
actually
part
of
the
interface
layer,
so
they
should
be
objects
on
their
own
and
they
should
be
specialized
to
doing
basically
just
what
they're
doing
in
terms
of
implementing
those
those
parts
of
those
parts
of
those
technologies.
Specifically,
similarly,
the
application
tier
to
your
objects
typically
will
be
implemented
either
using
ejb
or
enterprise
beans,
or
cdi,
and
enterprise
beans
in
particular,
is
a
very
good
fit
for
the
application.
B
Tier
and
we'll
see
an
example
of
why
that
is
basically
these
application
services.
The
methods
in
there
tend
to
model
units
of
work
or
use
cases
in
the
application,
so
it
is
a
perfect
place
to
for
to
service
transaction
boundaries
or
where
you
apply,
declarative,
role-based,
security
or
potentially,
where
you
would
want
to
want
to
apply
asynchrony.
So
that
is
why
it
actually
makes
a
lot
of
sense
to
implement
these
application
tier
objects
using
enterprise
beans
or.
A
B
Right
so
you
can,
you
can
use
cdi
and
apply
the
transactional,
annotation
and
hopefully
even
more
ejb,
like
services
going
forward.
So
that
is
something
where
that
that
that
will,
how
that's
how
that
layer
will
typically
be
implemented,
at
least
in
jakarta,
for
entities
usually
there's
a
very
clean
mapping.
Frankly
speaking,
there's
no
need
to
really
over
think
over
overthink
this
too
much
basically
entities
for
the
most
part
map
directly
into
jpa
entities
in
jakarta
ebay
systems.
B
B
There
will
be
some
edge
cases
where
something
doesn't
really
need
an
identity,
but
you
need
to
kind
of
give
it
a
synthetic
identity.
So
it's
a
value
object,
but
it
winds
up
being
implemented
as
an
entity
in
jakarta
e.
It's
a
rare
error
case.
In
most
cases,
you
will
there's
again
there's
a
direct
mapping
between
embeddable
and
value
objects.
In
fact,
it
would
be
awesome
if
jakarta
the
persistence
just
named
the
thing
value
objects
following
the
domain
driven
design
patterns.
A
B
Infrastructure
is
actually
a
lot
of
jakarta
belongs
in
the
infrastructure
layer
in
one
way
or
the
other,
so
things
like
implementations
of
the
of
entity
meant
the
the
entity
manager
interface,
where
you're,
using
that
it
should
probably
just
be
its
own
separate
object
that
does
that
same
thing
for
jms,
rest,
client,
java,
mail.
All
of
these
sort
of
belong
in
their
own
objects
in
the
infrastructure,
layer,
typically
repositories
again
fairly
straightforward.
B
In
most
cases,
they'll
either
be
implementing
that
using
the
jpa
entity
manager
or,
if
you're,
using
nosql
or
jakarta
no
sql.
That
has
its
own
repository
implementation
literally
baked
in
into
the
in
in
into
the
technology,
and
it's
called
ad
repository.
So
it's
telling
you
hey.
This
is
the
the
same
thing
as
a
ddd
repository
concept.
So
definitely
there's
there's
analogs
to
that.
That
will
be
what
your
repository
implementations
will
typically
be
so
either
the
entity
manager
portion
of
jpa-
or
you
know,
then
the
corresponding
thing
in
in
the
jakarta.
B
B
So
here's
the
thing
that
I,
that
is
there
in
in
the
eclipse
foundation
and
the
thing
that
will
show
you
how
to
put
all
of
these
different
concepts
into
action
and
in
fact,
some
of
what
we
talked.
I
talked
about
a
basic
introduction
of
ddd
basic
introduction
of
how
you
go
about
mapping
ddd
into
jakarta
e.
You
know
some
example
implementations.
All
of
this
is
actually
part
of
the
documentation
of
the
carpet
tracker
project.
B
So
you
can,
you
know,
take
a
look
at
all
of
that
aside
from
from
the
talk
today,
but
the
main
project
is
in
this
url
I'll
I'll
go
over
to
that
url
in
a
moment,
and
first
thing
I'll
do
is
I'll.
Just
show
you
the
application
so
that
you're
you're
familiar
with
what
the
application
is
by
the
way,
there's
also
a
video
explaining
the
the
the
core
concepts
of
or
the
or
the
main
parts
of
the
main
functional
parts
of
the
application
as
well.
So
I
won't
repeat
too
much
of
that
I'll.
B
Just
give
you
a
small
taste
of
taste
of
the
project.
So,
let's
go
over
to
the
browser,
and
here
is
the
main
cargo
tracker
website.
Okay,
so
in
the
cargo
trucker
website,
you'll
see
the
overview,
there's
some
stuff
that
we
went
over,
there
will
be
goals
and
non-goals
listed
for
you
and
here's
how
you
get
started.
It's
super
simple
to
get
started.
I
actually
have
the
application
running
running
locally.
It's
you
can
just
use
you,
don't
even
need
to
use
an
ide
if
you
don't
want
to.
B
You
can
just
run
it
just
through
maven
it's
using
paera
today,
but
technically
we
have
plans
to
as
time
permits
to
apply
it
to
make
it
run
on
all
of
the
major
jakarta
application
servers
and,
of
course,
there's
a
github
repo
with
the
with
all
of
the
source
code
as
well
aside
from
this
website,
so
yeah
all
you
need
to
do
in
order
to
run.
It
is
just
run
this
guy
and
make
sure
you
have
maven
set
up
correctly
and
you're
good
to
go.
B
You
can
you
can
begin
to
get
started
with
the
application.
In
fact,
it's
even
easier
because
we
have
the
application
running
using
a
kubernetes
implementation
on
the
cloud
in
publicly
also
right,
so
I'll
go
ahead
and
open
this
guy
okay.
So
this
is
the
application
running
locally.
I
won't
actually
be
using
that
today.
In
the
interest
of
time
we
can
just
do
the
cloud
demo.
Actually,
so
here's
the
application
running
on
the
cloud
you
can
access
it
through
this
through
this
through
this
url.
B
It's
you
know
again
running
on
a
kubernetes
cluster,
thanks
to
our
friends
at
gelastic
they're
hosting
their
hosting
the
project
on
on
their
on
the
cloud
very
kindly
so
we'll
use
that
for
the
demo
and
you
you
can
do
the
same.
So
here's
explaining
the
the
background
that
I
just
did
the
jakarta
ddd
mappings.
That
is
also
explained
here.
B
Okay-
and
we
also
have
the
the
goal
of
this
project-
is
not
to
add
every
single
jakarta
e
feature
that
you
can
think
of
right,
so
it
basically
has
a
representative
set
of
what
you
would
encounter
in
most
quote-unquote
monolithic
applications
or
cohesive
applications.
So
we
do
have
a
decent
amount
of
stuff
that
we
use
from
jakarta.
B
B
Okay,
so
let's
go
ahead
and
do
a
quick
demo
of
the
application.
So
there
are
a
few
different
interfaces
to
the
application,
the
first
so
the
application,
what
it
does,
as
the
name
implies,
is
basically
track
cargo
going
across
the
globe.
So
it's
supposed
to
be
modeling
a
shipping
company's
interface.
Basically,
so
the
first
is
a
public
tracking
interface
and
basically
you
can,
if
you
know
your
tracking
id
right,
you
can
enter
your
tracking
id
and
you
can
see
where
your
cargo
currently
is.
As
you
can
see,
abc123
is
currently
in
helsinki.
B
Currently,
so
you
can
also
see
a
mapping
of
the
destination,
the
last
known
location,
which
is
gothenburg
and
the
origin,
which
is
hong
kong.
Okay,
so-
and
you
can
take
a
look
at
some
other
ones
here
as
well.
So
let's
take
a
look
at
another
one:
jkl,
five,
six,
seven,
okay!
So
it's
currently
misdirected!
B
So
over
here
you
can
see
all
of
the
you
know
where
all
of
your
cargo
is
in
in
one
go
in
fact,
there's
also
a
live
map
to
show
you
the
same
information,
so
you
can
take
a
look
at
where,
where
all
the
cargo
is
currently
and
some
information
about
the
cargo,
you
can
also
route
a
particular
cargo.
So
if
it's
cargo
is
not
routed,
you
can
say:
hey
go
ahead
and
route
this
and
it
will
give
you
a
few
routing
options
right,
so
you
can
pick
a
routing
option
and
then
it'll
be
routed.
B
B
B
B
B
B
Okay,
so
now
we
can,
I
think,
begin
to
dig
in
into
the
into
the
source
code
and
see
how
the
source
code
looks
like
and
I'll
do
that
using
github.
I
think
I
could
pull
up
the
id
to
do
that,
but
there's
no
real
reason,
reason
to
actually
github
does
a
pretty
decent
job
of
color
coding
things
and
so
on.
So
here's
all
the
code.
B
A
B
B
So,
as
you
can
see
at
the
top
level
here,
this
is
a
breakdown
of
the
layers,
layering
concepts,
as
we
talked
about
already,
so
you
have
the
application
layer,
the
domain
layer,
the
infrastructure
layer
and
the
and
the
info
infrastructure
layer.
So
we'll
start,
I
think,
top
let's
start
from
from
from
the
top.
So
here's
the
infrastructure,
layer,
okay
and,
as
you
can
see,
there's
a
couple
of
different
in
interfaces
in
sorry.
B
I
meant
to
show
you
the
interface
layer,
apologies,
so
there's
a
couple
of
different
interfaces
that
we
talked
about
before
right,
there's,
a
booking
handling
and
tracking.
So
if
you
take
a
look
at,
for
example,
the
tracking
interface
here
is
the
track
object,
and
this
is
basically
a
jsf
bean
and
it's
part
of
the
infrastructure
tier.
So
this
just
deals
with
infrastructure
concerns
right,
so
it
has
a
view
adapter
and
it
does
things
like
handling
handling.
B
B
Okay
and
it
basically
responds
to
different
use
cases
in
your
application,
so
booking
new
cargo
loading,
cargo
for
routing,
assigning
a
cargo
to
a
route
changing
destination,
and
this
is
by
the
way,
functionality
in
the
ui
changing
deadline
listing
all
cargos.
These
are
all
high-level
objects,
high
level
use
cases
and
they
all
repo
and,
as
you'll,
see
they're
relatively
short
each
of
these
methods,
because
all
of
the
work
is
actually
delegated
to
a
lower
layer.
B
Next,
let's
move
on
on
to
the
application
layer,
okay,
so
there's
really
one
application
layer
object
that
is
most
important
at
the
other
parts
of
the
interface
actually
are
skipping
the
application
tier
which,
by
the
way,
you
can
do
that
the
application
tier
is
not
mandatory
right.
You
can
directly
interface
with
the
repository
or
domain
layer
from
the
interface
layer.
If
you
like,
the
application.
Tier
is
more
of
an
intermediary,
so,
as
you
can
see,
there
is
an
implementation
of
it,
and
that
is
the
default
booking
service.
B
So
we
talked
about
that
already,
and
this
is
definitely
an
a
application
tier
object.
So
again,
it's
modeling
those
high-level
business
cases,
booking
new
cargo
requesting
possible
routes
for
cargo
assigning
a
cargo
to
a
repository,
and
this
is
a
stateless
session
beam.
Let
me
increase
the
font
a
little
bit
more.
I
think
this
is
a
stateless
session
mean,
and
these
are
all
basically
the
transaction
boundaries.
So
if
you
take
a
look
at
book
new
cargo,
for
example,
it
is
creating
a
bunch
of
domain
objects.
B
And
then
you
have
the
infrastructure,
layer
and
you'll
see
again,
there's
implementations
of
some
of
those,
so
the
cdi
there's
logging
and
there
is
messaging
and
so
on
so
logging.
As
you
can
see,
we
have
a
logger
producer
here.
This
is
infrastructure
level
concerns
and
this
is
why
it
warrants
sort
of
its
own
object.
Similarly,
for
all
of
the
all
of
the
repositories,
if
you
look
at
the
persistence,
there's
a
number
of
repositories
here,
we'll
take
a
look
at
the
cargo
repository,
for
example.
B
B
Okay
and
finally,
let's
take
a
look
at
the
domain
layer,
the
most
important
portion
in
domain
driven
design.
So,
as
you
can
see,
it
is
broken
down
into
the
model
and
service
portions.
So
I
do
have
a
domain
service,
as
we
talked
about
routing
is
a
service
here.
So
there
is
a
routing
service
implementation,
and
that
is
part
of
the
infrastructure
tier
as
well.
But
routing
service
is
an
example
of
a
domain
service
right.
B
So,
as
you
can
see,
it
just
has
one
verb
right:
it's
modeling,
just
fetch
me
given
given
a
particular
route
specification,
so
source
destination
and
deadline.
What
are
the
routes
that
match
this
particular
thing?
That
is
an
important
behavior.
It's
a
top
level
domain
domain
concept,
so
in
the
model
you'll
see
that
there
is
different,
that's
broken
down
into
different
different
parts
also,
so
this
is
corresponding
to
the
top-level
aggregates
in
my
in
my
application.
So
cargo,
obviously
is
an
important
one.
Handling
is
another
important
one.
Location
is
another
important.
B
One
voyage
is
another
important
one,
and
these
roughly
correspond
to
key
entities
or
or
aggregate
routes.
So,
for
example,
in
the
cargo
aggregate,
I
have
the
cargo
entity
and
that
is
actually
an
aggregate
route
and
that
aggregate
route
actually
uses
a
number
of
other
entities
and
value
objects,
so
delivery
handling,
itinerary
leg.
All
of
these
are
are
also
entities
themselves,
but
they
are
the
main
aggregate
route.
Here
is
cargo.
B
It
has
an
id
here's,
the
id,
it
has
a
number
of
state
and
each
of
these
states
are
actually
either
primitives
or
embeddable
objects
or
in
some
cases,
relationships
to
other
entities.
So
there's
a
tracking
id,
that's
the
id
location
is
another
another
entity.
Actually,
so
we
do
have
a
many-to-one
relationship,
so
this
is
the
origin.
B
Similarly,
we
have
things
like
delivery
and
route
specification
and
the
like
and
you'll
see
there's
business
logic
built
into
here.
So
here's,
for
example,
specifying
a
new
route,
so
in
in
here
there'll
be
things
like
delivery
update
on
routing,
and
this
is
where
all
of
the
business
logic
actually
resides.
B
B
A
B
Much
of
not
much
not
every
single
entity
will
have
behavior.
Some
of
them
really
are
just
state
handlers,
but
if
you
look
at
delivery,
for
example,
delivery
should
be
an
embeddable
yeah.
It
is
an
embeddable
okay
and
it
actually
has
a
number
of
important
bits
of
business
logic
built
into
it.
So
there
will
be
things
like
calculating
etas
and
the
like.
There's
a
non-trivial
bit
of
business
logic,
typically
going
on
in
in
in
in
the
delivery
object
that
you
can
take
a
look
at.
B
B
Let
me
finish
up
so,
as
you
can
see,
and
you
will
see
when
you
begin
to
investigate
the
cardboard
application,
jakarta
actually
fits
ddd
very
well,
and
if
you
really
begin
to
look
at
ddd,
it's
a
very
nice
clean
way
of
implementing
enterprise
applications,
in
fact,
nowadays,
finally,
things
are
coming
to
some
kind
of
sense,
and
people
are
talking
about
things
like
strategic
monoliths
and
modular
monoliths,
and
in
fact
that
is
what
the
cargo
trucker
application.
Actually
is
it's
a
modular
monolith.
B
If
you
wanted
to
you
could
break
you
know
cargo
tracker
up
into
smaller
many
smaller
pieces,
but
there
won't
be
much
of
a
value
proposition
to
be
honestly
to
be
doing
that,
but
all
of
the
architecture
and
modularity
is
already
there
because
of
the
way
ddd
is
is
structured.
So
you
almost
get
the
modularity
for
free.
If
you
will,
if
you
take
a
take
a
certain
approach
of
modeling
domain,
driven
design
between
layering,
as
well
as
the
concept
of
aggregate
roots,
it
all
works
out
fairly
nicely.
B
So,
hopefully,
cargo
tracker
is
a
great
place
where
you
can
get
started
with
all
of
this.
I
do
have
some
resources
for
you.
All
these
are
are
listed
in
the
resources
section
of
the
documentation
on
the
cargo
tracker
website.
Also
so,
of
course,
there's
the
cargo
tracker
website
itself
and
then
there's
some
good
resource
resources
to
get
started
with
domain
driven
design.
I
highly
recommend
the
one
pager
by
d
zone.
I
think
it's
a
very
good
one.
B
There's
a
nice
ref
card
on
on
ddd
there's,
also
a
very
nice
mini
book
that
info
queue
has
on
ddd.
It's
a
very
small,
thin
book.
You
know
for
people
just
beginning
ddg,
I
almost
referenced
it
as
a
like
a
table
top
book.
If
you
will
it's
like
less
than
100
pages,
it's
a
real
thin
book
on
ddd
and,
of
course,
if
you
want
to
learn
more
about
jakarta,
you
know,
there's
a
jakarta
tutorial
and
jakarta
examples.
B
A
B
B
B
The
reason
we
don't
use
it
anymore
is
because
we
didn't
have
the
use
case
and
it
turns
out
that
the
the
live
map
that
you
saw
that
I
briefly
demo
that
used
to
be
implemented
using
websocket,
but
it
turns
out
that
we
we
can.
We
can
get
away
with
just
implementing
it
using
ssc,
so
we
don't
have.
We
got
rid
of
the
websocket
use
case
and
we,
but
we
do
have
ssc
or
server
set
events
demo.
B
You
know
with
with
the
live
map,
if
you
can
think
of
a
use
case,
a
legitimate
one
for
websocket
there's,
no
reason
why
we
couldn't
put
websocket
back
in
if
you
want
to
take
a
look
at
websocket,
the
old
version
of
the
application,
so
the
java
ee5
version
of
it.
Rather
sorry,
the
java
e6
version
of
it
and
we
have
all
of
the
old
versions
also
in
in
in
the
project,
so
the
java
e6
version
does
have
websocket
in
it.
B
B
If
you
will,
if
you
really
wanted
to
go
even
further,
you
could
deploy
each
of
the
each
of
the
aggregate
routes
as
their
own
microservice
and
so
on,
and
it
just
depends
on
how
small
how
micro
you
want
to
get
with
microservices,
but
you,
the
the
same
principles
of
domain
driven
design,
would
actually
apply.
So
you
would
basically
treat
each
micro
service
as
its
own
as
its
own
domain
context,
which
we
didn't
really
talk
about
too
much.
B
B
Let
me
post
it
again
so
yeah
you
can
definitely
get
a
pdf
copy
of
the
presentation
for
sure
thank
you
jeffrey
for
for
president
for
posting,
the
the
slides,
but
if
you
really
wanted
the
source,
the
powerpoint
for
it,
yeah
just
reach
out
to
me
or
post
on
the
mailing
list.
I'll
share
that
with
you.
It's
it's
no
problem.
You
can
have
at
it.