►
From YouTube: Applied Domain-Driven Design Blueprints for Jakarta EE
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.
A
Hello,
everyone:
how
are
you?
My
name
is
reza
rahman
in
my
day,
job,
I'm
principal
program
manager
for
java
on
azure
at
microsoft.
Today,
though,
really
I'm
not
here
for
my
day
job,
I'm
really
on
behalf
of
the
jakarta
e
ambassadors.
In
fact,
as
you
can
see,
I'm
wearing
a
jakarta,
e-branded
shirt,
my
screen
and
my
slide
deck
is
also
jakarta
e
branded
and
in
fact
today
I'm
going
to
be
talking
a
bit
about
a
project
that
I
lead.
That
is
very
closely
related
to
the
ee4j
umbrella
projects.
A
I
interacted
as
part
of
the
e
for
j
umbrella
projects,
and
it
is
closely
related
to
jakarta
e
as
a
technology
as
well
on
screen
you'll
see
my
contact
information.
So
if
you
have
any
questions
of
about
any
of
this
later
on,
please
do
feel
free
to
reach
out
to
me
and
certainly
I'll
I'll,
try
my
best
to
help
you.
So
the
title
of
the
talk,
as
you
can
see,
is
applied
domain-driven
design
blueprints
for
jakarta
e.
This
is,
in
essence,
talk
about
a
pro
eclipse
cargo
tracker.
A
So
I'll
give
you
a
little
bit
of
a
background
of
what
eclipse
cargo
tracker
is
and
what
we're
trying
to
do
and
how
it
relates
to
ddd
or
domain
driven
design.
So
this
all
goes
back
quite
a
few
years,
actually
about
25
years
to
be
exact.
Hopefully
some
of
you
still
remember
the
j2e
blueprints
or
so-called
the
java
pet
store.
A
So
if
back
in
those
days,
server-side
development
in
java
was
actually
pretty
chaotic,
in
fact,
server
side
development
in
general
was
fairly
chaotic,
everybody
sort
of
did
their
own
thing.
Every
single
project
that
you
would
look
at
you
would
use
different
design
patterns
and
look
would
look
completely
different
from
each
other.
A
All
that
changed
with,
essentially
with
the
j2e
blueprints
and
java
pet
store.
What
this
project
did
was
define
a
set
of
design
patterns
and
architectural
blueprints
that
all
server
side,
projects
that
use
j2e
as
a
technology
should
follow,
and
in
fact
it
really
brought
a
lot
of
order
into
server-side
architecture.
Back
in
the
day,
of
course,
just
like
j2ee,
the
j2e
blueprints
had
has
had
its
own
set
of
problems,
but
in
reality
you
know
this
has
been
very
profoundly
impactful.
A
So
even
today,
if
you
think
about
things
like
dtos
or
dios
or
session,
facade
or
remote
proxy
or
any
of
those
design
patterns
that
you
likely
are
using
in
your
in
your
projects
today,
those
most
likely
originated
in
in
the
pet
store,
but
the
issue
with
the
pet
store
was
essentially
the
same
issue
as
existed
in
j2e,
namely
what
is
known
today
as
anemic
domain
models.
So
you
really
at
your
domain
model
layer.
A
You
couldn't
apply
object,
orientation
very,
very
well,
because
primarily
j2e
as
a
technology
only
allowed
you
to
model
more
or
less
the
data,
so
it
would
be
almost
a
mirror
image
of
whatever
you
had
in
your
relational
database,
but
you
couldn't
really
do
a
very
rich
domain
model
and
certainly
you
couldn't
mix
in
behavior
and
state
in
in
your
domain
model.
Very,
very
well.
A
So
a
response
to
that
really
was
this
thing:
domain
driven
design
and
domain
driven
design
by
no
means
is
that
new
either,
but
really
what
it
did
was
it
said.
Okay,
you
know
your
domain
models
should
not
be
anemic.
There
should
be
rich
domain
models
that
have
that
model.
Essentially
your
real
world
application
as
closely
as
possible.
A
Now
I
had
been
an
early
adopter
of
domain
driven
design
and
also
an
early
adopter
of
j2ee
and
subsequently
java,
ee
and
jakarta
e.
So,
unlike
j
to
ee,
jakarta,
ee
does
actually
map
to
domain
driven
design
relatively
well,
first
and
foremost,
because
you
can
create
rich
domain
models,
but
second
of
all,
java
e
also
makes
jakarta.
E
also
makes
a
philosophical
distinction
between
infrastructure
and
code.
A
So
your
idea
is
that
you
should
really
be
just
be
focused
on
writing
your
business
domain
level
code
and
leave
the
infrastructure
level
stuff,
primarily
as
annotations
or
specialized
apis.
So
that's
why
jakarta
fits
the
domain,
driven
model
philosophy
and
way
of
doing
things
extremely
well.
So
that
is
really
what
the
cargo
tracker
project
is
fundamentally
about.
A
A
A
A
So
that
is
fundamentally
the
philosophy
of
domain
driven
design.
Now,
in
order
to
do
that,
it
basically
employs
a
set
of
architectural
paradigms
and
design
patterns,
and
the
fundamental
design
patterns
are
just
a
few
they're,
not
they're,
not
very
large,
in
number,
and
these
basically
form
the
fundamental
building
blocks
of
what
domain
driven
design
is
supposed
to
be.
So
this
diagram
that
you
see
on
screen
now
is
actually
not
something
I
have
formulated.
A
This
is
a
a
a
diagram
that
is
there
and
it's
well
understood
in
the
domain
driven
design
community
and
they
basically
encapsulate
the
building
blocks
of
domain
driven
design
and
some
of
the
key
design
patterns
that
exist
there.
So
we'll
take
a
look
at
these
design
patterns
first
and
do
a
quick
tour
of
them,
and
that
will
give
us
actually
a
pretty
good
understanding
of
what
how
to
apply
domain
driven
design
in
real
life.
A
So,
let's
start
with
some
of
these
design
patterns,
one
of
the
most
fundamentally
important
ones
is
the
entity,
in
fact,
at
the
heart
of
it.
This
is
really
what
what
makes
domain
driven
design
really
what
it
is.
So,
as
the
name
implies,
an
entity
is
an
important
thing
in
in
your
in
your
business
domain.
Most
of
the
most
of
the
things
in
in
the
real
world
are
really
things.
These
are
nouns
of
various
kinds.
A
A
Some
of
you
from
jpa
might
think
this,
but
don't
think
this
way,
so
entities
are
not
just
about
data
right
they're,
not
a
just
a
representation
of
of
your
of
a
database
or
of
a
database
table
it's
much
more
than
that,
because
entities
are
not
only
supposed
to
model
state
but
also
behavior,
so
there
will
be
aside
from
getters
on
center.
There
will
be
behavioral
methods
in
entities
that
actually
encapsulate
the
business
logic.
A
closely
related
design
patterns
to
entities
is
value,
objects
so
similar
to
value
objects
similar
to
entities.
A
A
So
I'll
give
you
an
example
of
a
convenient
example.
Let's
say
you
have
an
hr
system,
an
employee
is
an
entity.
It
makes
sense
for
employee
to
be
an
entity
in
that
system,
but
within
that
that
employee
object,
there's
also
address
data.
Well,
you
can
put
in
address
data
as
direct
fields
in
your
employee
object,
but
that's
not
good
object-oriented
modeling.
What
you
would
want
instead
is
a
containing
contained
object
called
address
that
has
all
those
address
fields
in
it.
Now
this
address
object
itself
does
not
need
an
identity
of
its
own.
A
It
can
simply
be
attached
to
an
employee
object.
So
that
is
what
a
value
object
actually
is.
It
is
a
thing
just
like
an
entity,
but
the
distinction
between
an
entity
and
a
value
object
is
that
a
value
object
is
really
there
to
help
you
construct
a
better
domain
model,
but
it
does
not
have
an
identity
of
its
own.
It
does
not
need
one
in
terms
of
database
technology.
Basically,
it
wouldn't
have
a
primary
key,
whereas
an
entity
would
have
a
primary
key.
A
Another
closely
related
concept
that
is
important
to
understand
in
demand
driven
design
is
aggregates.
So
let's
imagine
for
a
moment
that
you've
designed
your
system
and
it's
a
well-designed
system
and
there's
a
number
of
databases
in
in
your
database
to
store
your
data.
What
you
will
tend
to
notice
is
that
some
database
tables
are
more
related
to
each
other
than
others,
so
they'll
tend
to
have
constraint,
relationships
between
them,
foreign
relationships
defined
between
them
and
the
like.
A
This
is
because,
when
you
model
the
a
real
life
object,
some
objects
are
more
closely
related
to
each
other
than
there
are
other
parts
of
the
system.
Each
of
these
closely
related
clusters,
if
you
will
form
an
aggregate
and
we'll
we'll
take
a
look
at
this.
In
the
example,
that's
the
best
way
really
to
understand
the
concept
of
an
aggregate,
but
an
aggregate
is
basically
a
set
of
closely
related
entities
and
value
objects.
There
is
a
encapsulation
relationship
here.
A
The
next
design
pattern
to
understand
is
repository,
and
I
think
this
is
a
familiar
one
to
many
of
you.
This
is
basically
dios
in
in
j2e
blueprints
power
lance.
So
the
purpose
of
the
repository
is
really,
as
its
name
implies.
It
basically
act
as
an
interface
between
the
underlying
data
storage
technology
and
the
object
model.
So
if
you
want
to
retrieve
an
entity,
you
query
the
repository.
If
you
want
to
save
an
entity,
you
query
the
repository.
A
If
you
want
to
delete
an
entity,
you
tell
the
repository
to
delete
that
entity
from
the
underlying
data
store.
So
it's
really
nothing
much
more
than
in
terms
of
jte
parlance,
a
session
facade
of
sorts
right,
but
it's
a
specialized
session.
That's
why
it's
called
a
dao
or
data
access
object
in
in
j2e
design
patterns.
A
The
next
design
pattern
we'll
talk
about
is
a
factory,
so
a
factory
is
again
in
in
the
gang
of
four
design
patterns.
This
is
a
creational
object,
so
in
most
cases
entities
and
value
objects,
you
can
simply
create
them
using
a
constructor
or
simply
some
setters,
and
that's
all
that's
all.
You
need
to
do
in
order
to
construct
a
new
new
entity
or
a
value
object.
A
But
in
certain
cases
some
objects
are
simply
too
complex
and
they
involved
a
bit
of
business
logic
even
for
the
creation
step,
and
that
is
why
factories
exist.
The
factories
essentially
encapsulate
that
logic
of
creating
a
non-trivial
entity
or
in
most
cases,
non-trivial
aggregate
entity
is,
is
the
most
likely
case,
and
there
are
again
examples
of
this
in
the
cargo
tracker
application
that
you
can
take
a
look
at
as
to
how
these
things
how
these
things
should
be
implemented.
A
The
next
one
is
services,
and
this
is
a
bit
tricky,
because
the
moment
I
say
services,
most
of
you
probably
are
thinking
either
restful
services
or
soap
services,
or
something
else
like
that.
But
there
is
an
analog
to
those
thing.
Those
things
in
domain
driven
design,
we'll
talk
about
that
in
a
moment,
but
this
is
not
it.
This
is
what
is
called
a
domain
service.
A
A
Essentially,
routing
is
a
very,
very
important,
important
thing
to
be
doing
any
kind
of
logistical
system.
Routing
is
an
important
thing
to
be
doing
so
that
deserves
to
be
a
service
on
its
own
right
and
it
acts
upon
other
entities.
It
acts
upon
voyages
and
and
cargo,
but
it
itself
actually
is
a
top-level
domain
object.
A
Similarly,
if
you're
to
do
an
insurance-based
system
underwriting
is
a
very
important
verb,
so
that
will
probably
something
that
will
be
encapsulated
as
a
domain
service
as
well
and,
of
course,
there
is
an
example
of
a
domain
service
in
cargo
tracker,
so
other
than
these
a
small
number
of
key
design
patterns.
There
are
a
few
other
things
to
understand
in
terms
of
domain
driven
design.
These
are
things
like
a
model
driven
development,
layered
architectures
and
a
smart
ui.
A
I
won't
cover
all
of
them,
but
the
one
thing
that
I
you
absolutely
should
understand
is
layering
architectures,
so
you
fundamentally
layering
is
not
not
required,
not
not
an
absolutely
mandated
part
of
domain-driven
design.
You
can
do
remainder
and
design
without
introducing
layers.
What
and
I
have
seen
such
systems.
A
Now,
the
reality
in
most
enterprise
systems
is
that
you
actually
can
fundamentally
separate
some
concerns.
There
are
some
concerns
that
are
recurring
and
if
you
separate
those
concerns
out
into
their
own
layers,
you
actually
will
wind
up
not
having
these
long
complicated
objects
and
what
you
will
have
is
much
more
narrow
objects
with
with
small
amounts
of
code
in
them
because
they're
specialized
they
do
a
specialized
thing.
A
So
we'll
we'll
take
a
look
at
these
layers.
This
is
another
diagram
again
that
is
out
there
in
the
ddd
community.
You
know
it
is
also
part
of
the
cargo
tracker
documentation.
I'll
show
you
that
in
a
moment,
so
you
can
refer
to
it
later.
So
the
domain
layer
is
the
stuff
that
we
talked
about
before
entities
value
objects,
factories
repositories,
those
all
belong
in
the
domain
layer
and
they
constitute
the
core
part
of
your
your
application
or
your
domain
model.
A
If
that's
what
you're,
what
you
happen
to
be
using
messaging
interfaces,
its
whole
purpose
is
to
communicate
out
to
something
else
other
than
the
core
of
the
application,
either
a
human
or
another
or
another
system.
If
you
will-
and
they
do
things
like
translating
from
one
data
type
to
the
other,
doing
serialization
and
deserialization
doing
some
assembling.
A
These
are
all
of
the
concerns
that
we'll
see
in
a
moment.
These
are
more
to
there's.
Some
analog
to
this
in
another
concept
called
a
bounded
context,
but
that's
right
type
of
work.
It's
usually
just
mapping
things
from
one
to
the
other,
converting
things
to
from
one
to
the
other
that
that's
what
it
interface
layer
typically
does
now,
in
addition
to
all
this
stuff,
there
is
another
concern
called
infrastructure
level
concerns,
and
these
are
things
like
transactions,
data
access,
asynchrony.
A
A
So
that's
all
about
inter
interfaces,
applications
and
domain.
So
the
one
thing
that
I
will
note
for
you
is
that
notice
that
layers
are
not
mandatory.
So
even
in
my
diagram
here
there
is
a
case
where
there
is
a
direct
interface
invocation
into
the
domain
layer,
and
that
is
also
perfectly
fine.
You
do
not
need
an
application
layer
always
if,
if,
if
it
doesn't
add
value,
you
can
just
directly
invoke
your
domain
object
from
your
interfaces
and
the
cargo
trucker
example
has
has
both
cases
modeled.
A
So
you
can
take
a
look
at.
You
know
how
it
do,
how
it
differs,
and
it
is
similar
these
two
types
of
doing
things
if
you
will
all
right.
So,
let's
begin
to
map
the
concepts
of
domain
driven
design
and
jakarta
e
more
concretely,
so
here's
a
convenient
mapping,
typically
because
of
the
because
of
those
factors
that
I
talked
about
in
jakarta
before,
there's
a
relatively
clean
mapping
that
does
not
overlap
too
too
much.
So
interfaces
tends
to
be
things
like.
A
A
Applications
are
typically
very
well
modeled
modeled
as
ejbs.
The
reason
is,
as
I
mentioned
before,
applications
are
application,
layer,
objects
or
methods
typically
are
use
cases
or
units
of
work
in
your
application,
so
that
is
a
very
good
place
to
apply
logically
apply
things
like
transaction
boundaries
using
the
ad
transaction
annotation
or
just
ejb
transactions
or
security
or
asynchrony
or
scheduling
these
are.
These
are
good
places
to
apply
those
concerns.
So
typically
your
application
objects
will
be
ejbs.
That
is
in
fact
the
case
in
in
cargo
tracker.
You
don't
have
to
do
that.
A
A
entities
usually
have
a
pretty
clean
mapping
to
jakarta.
Typically,
entities
are
typically
jpa
entities,
almost
a
direct
mapping,
so
it
models
both
state
and
behavior
and
we'll
see
that
in
the
application
also
again
value
objects
have
a
pretty
clean
mapping
as
well
and
they
tend
to
be
embeddable
objects.
Some
cases
it's
convenient
to
still
map
value
objects
as
entities
just
as
a
infrastructure
level
concern.
A
It
doesn't
change
the
fact
that
they
are
in
fact
functioning
as
value
objects,
but
in
the
typical
case-
and
that
is
the
case
in
cargo
tracker-
a
value
object
will
typically
just
be
an
embeddable
infrastructure
again,
those
all
those
nice
apis
in
in
jakarta
that
has
that
deal
with
infrastructure,
specifically
right.
So
this
is
a
jpa
java,
mail,
jakarta
messaging.
A
These
are
all
typically
infrastructure
level
concerns
and
and
there's
a
number
of
those
in
use
in
cargo
tracker,
and
you
can
take
a
look
at
an
example
of
all
of
those
also
and
then
finally,
there's
a
repository.
These
are,
these
will
be
part
of
the
domain
object.
Typically,
they
will
be
defined
in
terms
of
jpa
or
cdi.
A
A
Even
in
a
monolithic
application,
you
can
have
a
modular
monolithic
application
that
has
these
bounded
contexts,
and
certainly
that
is
absolutely
in
microservices.
There's
a
case
for
bonded
context
as
well.
So
the
way
to
understand
bounded
context
is,
let's
take.
Let's
say
you
have
a
key
entity
called
let's
say
in
an
insurance
based
application,
a
policy
holder
that
policyholder
object
will
actually
have
different,
behavior
and
different
bits
of
data
depending
on
which
subsystem
it
is
in.
A
So
it
will
look
very
different
to
a
salesperson
versus
somebody
who
is
doing
billing
versus
somebody
who
is
doing
customer
service
they're
going
to
want
to
look
at
different
types
of
policyholder
information.
That
is
relevant
for
that
particular
subsystem
or
use
case,
and
the
behaviors
of
what
can
be
done
to
this
policyholder
will
also
significantly
change
depending
on
what
subsystem
that
it
that
it
is
in.
A
These
are
all
legitimate
domains
of
their
own
right,
they're,
sort
of
mini
domains
in
in
your
application
and
in
if
you,
in
this
diagram,
which
is
again
also
well
understood,
each
bounded
context,
or
if
you
will
a
microservice
in
the
extreme
case,
communicate
each
other
with
each
other.
Using
certain
paradigms,
and
you
can
take
a
look
at
and
understand
the
details
of
all
of
these
things.
A
It
could
be,
at
the
extreme
end,
the
big
baller
mud,
where
you're
dealing
with
the
legacy
system
or
something
like
shared
kernel
or
open,
host
or
separate
ways,
or
what
have
you?
These
are
different,
different
ways
of
dealing
with.
How
do
you
communicate
from
one
system,
one
subsystem
to
the
other,
all
right,
so
that
brings
us
to
the
cargo
tracker
application
the
url
is
embedded
in
in
the
slide
deck.
A
I
will
now
show
you
give
you
a
brief
tour
of
the
application,
the
website
itself
for
the
application
and
show
you
a
little
bit
of
what
is
there
and
then
also
give
you
a
brief
tour
of
the
code.
Unfortunately,
I
can
do
that
without
ide,
without
command
line.
Without
anything
else
and
I'll
tell
you
in
a
moment
why
that
is
so:
here's
the
application,
or
rather
here's
the
main
website
for
for
cargo
tracker.
So
it
has
a
bunch
of
useful
resources
in
there.
A
Basically
there's
an
overview
that
covers
much
of
the
same
stuff
that
I
told
you
about
towards
the
beginning
of
the
presentation.
There's
the
goals
and
non-goals
of
our
project.
There
is
getting
started
code,
so
you
can
download
this
code
download
this
repository
and
get
it
started
and
running
in
your
own
local
environment
very
very
easily,
provided
you
have
a
java
environment.
All
you
need
to
do
is
run
this
maven
command
that
you
see
you
see
on
screen
at
the
moment.
A
It's
a
mvn,
clean
package,
cargo
run
and
that's
it
it'll
get
your
application
up
and
running.
You
can
also
get
it
running
and
get
it
running
in
your
ide.
You
just
need
pyra,
which
is
the
app
server
we
use
at
the
moment,
and
also
you
need
some
kind
of
maven
capable
ide
most
likely
you.
You
want
to
be
using
something
like
like
eclipse
or
intellij.
A
So
that's
how
you
that's
how
you
get
started
with
the
application.
Now
you
don't
actually
have
to
install
anything
in
your
on
in
locally
on
your
laptop.
If
you
don't
want
to,
in
fact,
I'm
not
going
I'm
going
to
show
you
how
not
to
do
that,
so
the
entire
application
is
actually
running
up
up
on
the
cloud
right
at
this
moment.
It's
running
on
a
kubernetes
cluster
I'll
show
you
a
github
action.
A
A
There's
a
background
information,
there's
a
nice
little
graphic
that
explains
again
the
evolution
of
going
from
the
j
to
e
pet
store
to
the
to
the
cargo
tracker
application.
Today,
again,
there's
an
explanation
of
the
basic
concepts
of
domain
driven
design
and
how
it
maps
to
jakarta
ie
concepts,
and
there
is
also
a
section
that
talks
about
what
are
all
the
jakarta
e
features
that
the
application
uses.
We're
not
really
a
jakarta
e
demo
application.
A
But
you
know
we
do
use
a
fair
amount
of
of
jakarta
technologies.
There's
also
a
nice
documentation
section.
You
can
take
a
look
at
so
there's
good
things
like
explaining
to
you
the
basic
concepts
of
of
domain
driven
design
and
jakarta
e,
so
so
again,
sort
of
the
same
concepts
that
we
talked
about
previously
more
details
about
characterization,
okay,
so
taking
each
of
the
design
patterns
in
jakarta
and
see
how
they
map
to
in
cargo
tracker.
So
an
example
of
an
entity
is
cargo.
A
Okay,
we'll
see
that
you
know
I'll
show
you
that
in
a
moment
right
from
here
in
or
from
the
github
repo
there's
an
example
of
a
value
object.
So
leg
is,
is
an
example
of
a
value
object,
and
it's
explained
why
that
is
domain
events
aggregates.
So
this
is
the
cargo
aggregate
that
is
mapped
for
you
in
a
uml
diagram
and
explained
as
to
how
it
maps
to
domain
driven
design.
There's
some
examples
of
repositories,
examples
of
factories,
event,
handling
event,
factory
being
an
example.
A
Example
of
domain
services,
as
we
talked
about
routing
services,
is
one
of
the
key
verbs
in
our
domain
and
then
application
services
and
the
like,
there's,
also
an
explanation
of
layering.
Okay,
that
you
can
take
a
look
at
again.
That's
that
diagram
there
and
it
explains
to
you
how
each
of
the
layering
is
working
in
the
cargo
tracker
application
and
in
general,
the
the
concept
of
layering
is
explained
here
is
as
well,
including
the
question
of
answering
are
layers
actually
mandatory.
A
So
let's
take
a
quick,
take
a
quick
look
at
the
application,
then
we're
going
to
dive
into
the
code
and
in
the
remaining
time
that
we
have
so
here's
the
application
up
and
running.
As
you
can
see,
it
is
on
the
cloud
running
on
a
kubernetes
cluster
again
behind
the
scenes.
I'll
show
you
the
actions.
So
this
is
the
nightly
actions
that
are
deploying
this
application
to
the
kubernetes
public
kubernetes
cluster.
A
There's
several
interfaces
to
the
application,
as
as
I
talked
about
before,
the
application
is
just
tracking
shipments
of
cargo
across
the
globe.
So
there's
a
public
tracking
interface.
You
can
take
a
look
at
the
current
status
of
cargo
here.
It'll
tell
you
where
the
cargo
is
where
it
has
been,
what
the
handling
history
is
and
a
map
of
how
what
the
history
of
the
cargo
handling
is.
A
There's
an
administrative
interface
that
gives
you
a
dashboard
of
all
of
the
cargo
that
is
in
in
the
system.
Currently
there's
also
a
live
map
version
of
this,
so
you
can
take
a
look
at
the
details
of
each
cargo
and
where
its
current
status
is.
As
I
said,
this
is
live
so
this
as
changes
happen
in
the
system.
This
map
is
actually
updated
in
real
time
without
a
refresh
or
anything,
you
can
take
a
look
at.
Do
things
like
to
take
a
look
at
the
details
of
cargo.
A
You
can
book
new
cargo
here
as
well,
so
we
won't
go
through
this.
I
don't
think,
and
you
can
also
do
things
like
route
cargo.
So
if
you
have
a
cargo
that
is
booked,
you
can
go
ahead
and
route.
It
and
it'll
give
you
what
all
the
route
options
are
for
a
given
cargo
and
available
voyages
in
the
system.
So,
as
you
can
see
in
this
case,
there
are
four
different
options
that
I
could
select
to
and
commit
my
cargo
to
a
particular
itinerary.
A
There
is
also
a
event,
logger
interface
that
allows
you
to
say:
hey
what
do
you
want
to
do?
Changing
the
state
of
cargo,
so
you
could
say
hey.
I
want
this
cargo
loaded
or
unloaded,
or
what
have
you
or
claimed
in
a
particular
port,
and
this
is
what
changes
the
state
this
is
the
this
will
run
the
state
machine
of
the
of
the
domain
for
you,
if
you
will
so,
let's
begin
to
take
a
look
at
the
code
behind
the
application,
so
that
is
in.
A
I
think
the
easy
way
to
do
that
is
just
browsing
it
through
github.
Let
me
make
sure
I
have
the
font
set
appropriately.
I
think
I
do
so.
Here's
a
source
code,
there's
java.
This
is
the
main
java
model
object
model
that
I
have.
As
you
can
see,
there
are
two
different:
this
is
a
representation
of
the
bounded
context,
there's
two
of
them:
pathfinder
and
cargo
tracker
cargo
trigger
being
the
primary
one
going
into
cargo
trucker,
as
you
can
see
the
the
package
structure
of
the
application
models,
domain-driven
design
effectively
right.
A
So,
as
you
can
see,
there
is
the
application
layer
code
domain
layer,
code,
infrastructural
layer,
code,
interface,
layer
code
in
the
interface
layer
code.
You
will
have
various
things
like
each
of
each
mapping
the
different
interfaces
in
the
application,
so
this
is
the
booking
application,
the
handling
application,
the
tracking
application
and
the
like.
So
let's
take
a
look
at
the
handling
there'll,
be
a
file
based
batch
processing
interface,
a
mobile
interface
that
you
saw
and
then
a
restful
interface.
So
these
are
all
mapped
in
in
the
application.
A
We'll
take
a
look
at,
let's
take
a
closer
look
at
the
application
layer,
so
in
the
application
layer,
one
of
the
key
one
objects
are
the
booking
service.
Okay.
So,
as
you
can
see,
this
is
an
this.
Is
an
implementation
of
ejb
I'll
show
you
that
in
a
moment,
but
basically
this
is
the
primary
use
cases
in
the
application,
so
booking
new
cargo
requesting
possible
routes,
cargo,
assigning
a
cargo
to
our
route,
changing
destination,
changing
the
deadline.
So
if
you
look
at
the
implementation
of
this.
A
And
if
you
look
at
implementation
of
each
of
these
things,
they
basically
is
a
good
representation
is,
for
example,
let's
say
assigning
route
to
a
cargo,
so
this
is
basically
looking
up
the
cargo
from
the
using
the
repository
interface
assigning
the
route
to
the
cargo,
but
there
is
no
business
logic
in
the
application
layer.
The
business
logic
actually
resides
in
in
the
entity
itself,
so
it's
in
making
an
invocation
onto
the
cargo
object's
business
method
and
then
storing
the
cargo
out
in
the
repository.
A
So
it's
a
way
of
encapsulating
different
different
parts
of
the
repository.
Basically
booking
new
cargo
is
another
example:
creating
a
tracking
id,
creating
a
location
entity,
creating
another
location
before
the
destination,
creating
a
route
specification,
creating
the
actual
cargo
and
the
like.
So
it's
its
job
is
coordination.
A
So,
let's
take
a
look
at
a
quick
look
at
the
domain
model
itself.
So
if
you
look
at
look
at
the
domain,
there
are
several
parts
of
it:
there's
a
model
itself,
there's
a
service.
So
there
is
the
routing
service
that
we
talked
about
before
you
can
take
a
look
at
an
implementation
of
that.
If
you
look
at
the
model,
it
represents
the
aggregates
in
the
system.
Okay,
so
there's
the
cargo
aggregate,
the
handling
aggregate,
the
location
aggregate
and
the
voyage
aggregate.
A
The
cargo
aggregate,
as
you
can
imagine,
is
the
main
one.
Okay,
so
the
aggregate
entity
there
is
cargo,
but
there's
a
number
of
other
objects
that
are
part
of
this
part
of
this
aggregate
right.
So
there's
a
delivery.
Itinerary
leg
route
specification
all
of
these
things.
Similarly,
if
you
look
at
the
voyage
aggregate,
okay,
the
key
entity
there
is
voyage,
but
it
has
a
number
of
other
things
that
are
that
are
helping
that
part
of
the
that
part
of
the
domain
model.
So
these
are
your
aggregates
in
action.
A
Let's
take
a
look
at
the
cargo
entity,
okay,
so
the
cargo
entity,
as
you
can
imagine,
is
a
jpa
entity.
Okay,
there's
there's
the
jpa
entity,
annotation,
there's
behavior,
okay
and
state,
so
tracking
id
look,
origin,
dot,
specification
delivery.
This
is
all
data,
but
there's
also
behavior.
Okay,
so
those
are
the
setters
on
getters,
but
there
is
there's
a
specifying
new
route
assign
new
route
again.
This
is
mapping
the
behavior
of
of
this
object
of
this
object,
driving
delivery
progress.
A
A
It
is,
in
fact,
a
value
object
that
has
a
name,
and
that
has
an
embeddable
in
it.
It
had
there's
a
lot
of
business
logic
in
in
the
delivery
object
as
you'll
see
when
you
begin
to
take
a
look,
but
nonetheless
this
is
a
value
object.
It's
a
very
important
value
object
that
is
part
of
the
entity
model.
A
A
Okay,
as
you
can
see,
this
is
primarily
just
a
bunch
of
jpa
code,
a
bunch
of
jpql,
but
it
is
part
of
the
infrastructure
and
is
encapsulated
on
its
own.
Another
good
example
is
things
like
logging,
okay,
so
here's
a
logger
producer
that
is
used
all
across
the
application
in
different
layers,
but
it
is
encapsulated
into
its
own
layer
also,
and
it
is
encapsulated
into
its
own
object
in
in
as
part
of
the
infrastructure
layer.
A
A
Jakarta
e
is
a
very
good
fit
for
ddd.
I
would
say
one
of
the
better
fits
for
ddd
out
there
in
terms
of
technology
sets,
and
in
order
for
you
to
see
that
you
can
take
us
a
look
at
that
as
at
the
cargo
trucker
application
as
an
example
of
how
all
of
those
things
actually
are
put
together.
So
here's
some
resources
for
you
before
I
finish
up
here.
Obviously
there's
a
cargo
tracker
website
and
then
I've
included
a
number
of
resources
for
domain-driven
design
on
its
own.
A
Most
of
these
resources
are
free.
You
don't
have
to
pay
anything,
certainly
the
one
from
d-zone
and
info
queue.
Those
are
free
and
that
will
help
you
learn
more
about
domain
driven
design
beyond
what
I
have
the
bandwidth
to
to
tell
you
about
today,
and
if
you
want
to
learn
more
about
jakarta
ee,
there
is
a
few
sister
projects
to
cargo
tracker
to
do
that,
namely
the
tutorial
and
the
jakarta
examples
that
I
certainly
welcome
you
to
take
a
look
at
those
resources,
they're,
very
good
resources
to
begin
learning,
jakarta
e
on
its
own.