►
Description
Ortelius Microservice Visionaries 2021 - In this session Aditi Agarwal will define why a domain driven design (DDD) is important to building a shared service architecture. This session will give a basic definition of DDD and demonstrate how Ortelius helps facilitate this methodology through Domains.
A
A
Before
we
jump
on
straight
away
to
the
topic,
let
me
introduce
myself.
My
name
is
aditya
garwal
and
I
am
currently
pursuing
my
graduation
in
computer
science.
Currently
I'm
doing
an
internship
at
cisco
as
site,
reliability,
engineer
and
I
have
increased
an
open
source
community,
which
is
one
of
the
reason
I
got
connected
to
this
other
community.
A
You
can
connect
me
at
my
various
social
handles
twitter
linkedin
and
get
a
profile
all
right.
So
before
I
introduce
you
what
is
open
source
whatever
it
is
written
here,
I
would
like
to
make
you
familiarize
with
the
topic
which
we
are
going
to
discuss
today.
So
in
this
session
we
will
define
why
a
domain
driven
design
is
important
to
building
a
shared
service
architecture
and
demonstrate
how
otds
helps
facilitate
this
methodology
through
domains.
A
A
A
Monolithic
architecture
is
basically
a
traditional
architectural
style
in
which
we
build
our
application
as
a
single
unit,
and
it
is
also
scalable,
but
in
terms
of
scaling,
I
can
say
it
is
more
resource
occupying,
for
example,
let's
take
the
e-commerce
application
example.
We
have
a
sale
going
on
live
in
our
application,
and
customers
are
heading
on
to
my
catalog
service.
Very
often
they
are
trying
to
see
what
are
the
products
I
am
offering
to
them.
What
is
the
sale?
What
are
the
prices
and
so
on?
A
So
my
catalog
service
is
having
more
traffic
than
my
order
and
the
payment
service.
So,
in
order
to
serve
more
and
more
customers,
I
need
to
scale
my
application
for
the
catalog
service
only
but
in
case
of
monolithic
architecture,
since
it
is
a
single
unit
of
application
build
in
a
single
bar
or
jar
file,
we
cannot
scale
a
single
unit
of
service.
We
have
to
scale
the
whole
application
together.
We
cannot
scale
an
any
individual
service,
so
in
that
case
it
becomes
more
resource.
A
So
moving
on
to
the
micro
service
structure,
now,
let's
see
what
is
microservice
architecture,
so
what
are
microservices
microservices
are
small
and
autonomous
services
that
are
built
together
that
work
together.
What
is
autonomous
autonomous
is
something
which
is
self-covered,
which
take
cares
of
his
own
of
its
own.
We
do
not
have
to
really
intervene
into
the
whole
functionality
of
it
or
anything.
A
So
in
the
microservice
architecture
we
can
say
the
microservices
are
loosely
coupled
with
each
other
loosely
coupled
in
the
sense
when
you
have
a
service
which
is
independent
of
its
own,
which
is
not
depending
on
any
other
services
for
its
functionality,
and
we
can
make
changes
to
that
services
and
it
will
not
be
affected
by
any
other
services.
Microservices
key
component
is
that
it
is
reusable
what
is
the
advantage
of
making
an
architecture
which
cannot
reuse
its
functionalities
whenever
needed?
We?
A
A
We
can
create
a
microservice
for
a
specific
function
and
in
case
if
our
another
application
needs
the
same
functionality,
we
can
reuse
that
microservice.
Now
the
topic
is
domain
driven
design
so
to
implement
microservice
architecture.
We
need
a
kind
of
design
to
be
made
so
domain
driven
design,
helps
us
to
categorize
and
share
our
microservices
across
teams,
since
our
micro
services
has
are
built
by
small
teams.
A
So
it
is
much
easier
to
share
those
micro
services
among
different
teams
so
that
they
can
reuse
them
and
recompose
them,
and
also
we
see
our
organization
in
terms
of
problem
and
solution
spaces,
so
domain
driven
design
basically
divides
our
organization
into
two
spaces
that
is
problem
space
and
solution
space.
As
in
the
picture
we
can
see,
there
is
a
problem
space
and
there
is
a
solution
space.
So,
firstly,
using
the
problem
space,
we
try
to
understand
the
problem,
the
problem
to
which
the
solution
will
be
provided
using
domain
driven
design.
A
It
does
not
go
deep,
deep
dive
into
the
software
thing,
so
we
firstly
make
a
roadmap
of
our
problem
that
this
is
the
specific
problem.
This
is
the
use
case
which
we
have
to
implement
and
using
this
use
case,
we
have
to
develop
a
solution
in
corresponding
to
that
so
solution.
Space
is
something
which
we
design.
According
to
our
problem
space
in
the
solution
space,
we
have
a
term
called
bounded
context.
Bounded
context
is
a
boundary
within
which
our
solution
lies.
Here
we
talk
about
the
software
architecture
like
in
the
case
of
problem
space.
A
We
were
talking
about
the
business
architecture
in
the
solution
space.
We
relate
that
with
the
software
architecture,
and
it
is
also
linked
to
the
business
for
serving
the
problem
space
so
solution
space
has
few
terminologies
that
is
bounded
context,
domain
models,
ubiquitous
language
and
context
maps.
So,
let's
try
to
under
that
understand
these.
A
So
here
in
the
left
picture,
as
we
can
see,
let
us
try
to
visualize
the
problem
space
using
this
picture.
For
example,
I
have
this
complete
picture.
As
my
domain,
let's
take
my
organization,
name
is
xyz,
so
my
domain
name
is
xyz
and
in
my
domain
I
have
these
two
subdomains,
which
is
warehouse
and
finance.
A
So
now,
if
we
try
to
look
at
it
with
the
perspective
of
solution
space,
then
how
can
we
look
at
it?
We
have
this
complete
context,
which
can
be
referred
to
as
a
context
map
inside
which
we
have
these
two
context,
which
can
be
used
or
termed
and
bounded
context.
For
example,
my
finance
department
is
a
bounded
context
which
has
a
boundary
of
finance
department
only
inside
this
bounded
context.
I
have
my
own
ubiquitous
language
and
I
have
my
own
domain
model.
A
So
what
is
a
domain
model
domain
model
is
basically
implemented
within
its
bounded
context.
For
example,
we
have
a
whole
domain
model
or
we
design
a
domain
model
for
our
finance,
bounded
context
and
the
language
or
the
communication
using
which
we
design
a
model
that
is
called
ubiquitous.
Language
ubiquitous
language
is
something
like
the
common
communication
that
we
can
have
with
the
client
and
as
a
developer.
A
So
I
might
not
have
the
knowledge
of
those
business
terms,
so
we
must
have
a
common
communication
which
we
both
are
able
to
understand
and
get
that.
So
for
that
purpose
we
use
ubiquitous
language,
which
is
constrained
in
a
bounded
context.
Only
each
bounded
context
has
its
own
domain
model
and
that
domain
model
is
created
using
a
ubiquitous
common
ubiquitous
language,
okay.
So
this
is
a
whole
view
of
this
and
inside
and
since
we
have
these
two
bounded
context
inside
this
whole
context.
A
So
context
map
is
something
which
tells
us
about
the
overall
picture
of
our
overall
picture
of
our
complete
domain.
For
example,
this
complete
picture
has
two
bounded
context,
so
my
context
map
is
having
two
bounded
contexts
right
now,
but
as
it
is
said
that
the
more
smaller
and
the
easier
the
picture
should
be,
it
will
be
more
easy
to
understand.
So
in
the
terms
of
domain
driven
design,
it
is
said
the
bounded
context
should
be
kept
as
small
and
as
easy
to
understand
as
possible.
A
So
we
can
further
segregate
or
nest
our
bounded
context
into
these
terminologies.
For
example.
I
have
this
warehouse,
which
I
told
you
about
as
a
whole
bounded
context,
but
to
understand
it
in
a
more
convenient
way
and
to
handle
it
as
a
more
grammar
granular
approach.
I
can
further
create
founded
context
of
all
these
components
as
well,
for
example,
instead
of
creating
warehouse
as
a
whole
bounded
context,
I
create
trolley
as
a
separate
bounded
context,
picker
as
separate
picking
order
as
separate
and
so
on.
A
So
here
you
can
see
that
then
this
trolley
this
speaker
this
picking
order
each
one
of
these
will
have
their
own
ubiquitous
language
and
their
own
domain
model.
So
what
is
the
advantage
of
this?
So
in
the
domain
driven
design,
it
is
expected,
and
it
is
advised
to
have
smallest
bounded
context
as
possible
so
as
to
make
more
easier
and
convenient
microservices,
because
inside
this
whole
bounded
context.
A
If
I
take
into
picture,
I
have
to
create
multiple
microservices
and
I
have
to
take
into
consideration
a
ubiquitous
language
which
is
which
can
be
understood
by
the
stock
report,
company
valuation
and
general
ledger
all
of
these
things,
these
three
things.
So
what?
If
I
create
a
bounded
context
of
stock
report
only
then
I
do
not
have
to
include
general
ledger
and
the
company
valuation
in
it.
Then
that
would
be
more
easy
for
me
to
understand
and
for
client
to
understand.
A
A
A
I
hope
you
get
a
broader
view
of
domain
driven
design
till
now,
which
is
designed
using
domain
driven
design.
We
have
three
layers
which
are
independent
for
each
microservice,
so,
as
I
have
already
discussed,
that
aim
should
be
to
keep
microservice
bounded
context
relatively
small,
so
it
is
more
easy
to
design
a
bounded
context,
which
is
comparatively
small
and
the
layer
design
which
should
be
independent
for
each
microservices.
Are
these
each
microservice
has
three
layer
that
is
application,
layer,
domain
model,
layer
and
infrastructure
layer.
A
So
what
is
the
main
model
layer
domain
model
layer
is
the
heart
of
business
software.
It
is
responsible
for
tracking
all
the
data
and
the
behavior
of
our
service.
It
is
something
like
we
have,
so
we
have
a
service
which
is
designed
as
a
class
library
and
inside
that
class
library.
We
already
have
defined
all
the
methods
and
logic
which
are
need
to
be
performed.
It
basically
drives
the
other.
Two
layers,
that
is,
the
application
and
the
infrastructure
layer.
So
what
is
application
layer?
A
Application
layer
basically
tells
what
is
the
job
that
exactly
needs
to
be
done?
For
example,
I
have
a
web
api
interface.
I
need
to
create
a
front
end
for
my
application,
so
that
thing
my
application
layer
will
decide
and
the
infrastructure
layer
infrastructure
layer
is
responsible
for
keeping
the
data
the
data
to
its
database,
persistent
data.
Basically
until
now
we
have
all
the
data
in
our
memory.
So
now
we
need
to
keep
them
in
a
persistent
storage.
A
You
using
any
database
or
any
persistent
store,
so
infrastructure
layer
will
basically
connect
my
front
end
application
or
my
application
layer
to
a
persistent
storage,
for
example,
a
storage
engine.
Whenever
we
go
to
google
or
we
go
to
any
search
engine,
we
type
a
data
which
we
need
to
see
or
we
need
to
get
so
from.
Where
does
it
fetch
the
data?
It
also
fetches
the
data
from
its
persistent
storage,
so
that
is
the
role
of
infrastructure
layer.
A
Now,
if
we
see
that
dependencies
between
layers,
what
are
the
dependencies
between
these
three
layers,
then
we
can
clearly
see
that
domain
model
layer
is
irrespective
it
is
not
dependable
on
any
of
the
two
layers,
since
it
is
the
heart
of
the
domain,
and
it
is
the
heart
of
the
business
software,
it
does
not
depend
on
any
of
the
layer.
It
is
only
responsible
for
implementing
the
domain
entities,
aggregate
routes
and
value
objects,
while
application
layer
is
something
which
is
dependent
on
both
the
main
model
layer
and
the
infrastructure
layer.
A
The
main
model
layer
has
to
be
dependable
because
application
layer,
after
all
the
main
mod,
has
to
has
to
be
dependent
on
domain
model
layer,
because
it
is
the
heart
of
the
software
and
domain
model.
Layer
needs
to
know
about
all
the
up
layers
that
are
implemented
in
the
microservice
design
and
also
application
layer
is
dependent
on
infrastructure
layer
because,
after
all,
we
designed
a
back
end.
We
design
a
front
end
of
our
application
so
from
where
it
will
fetch
the
data.
So
that
is
the
place
where
our
database
hides.
A
So
our
database
resides
in
infrastructure
layer,
so
application
layer
has
to
be
dependent
on
the
infrastructure
layer
and
we
can
see
that
infrastructure
layer
is
only
dependent
on
the
domain
model
layer.
So
it
does
not
need
to
be
dependent
on
the
application
layer
because
it
is
responsible
for
only
reciting
the
persistent
data,
so
our
infrastructure
layer
is
dependent
on
domain
model
layer
which
keeps
the
record
of
the
infrastructure
layer
as
well.
A
So
there
arise
the
need
of
microservice
configuration
management
platform.
I
know
it's
quite
a
long
term
to
understand,
but
if
we
break
down
into
small
small
parts,
then
we
can
see.
Microservice
is
something
which
is
a
topic
and
configuration
management
platform
is
something
which
provides
us
to
manage
this
complete
context.
So
I
hope
now
you
would
be
able
to
get
this.
A
Our
mission
at
rotarius
is
to
simplify
the
adoption
of
microservices
through
a
world-class
microservice
management
platform.
So
so
what
does
ortelius
do
exactly?
Others
helps
us
to
visualize
all
the
microservices.
We
have
in
our
application
all
the
versions
of
the
microservices
we
have
in
our
application.
A
We
can
track
the
microservices,
whether
if
any
microservices
town
or
any
thing
is
breaking
up
there,
and
we
can
also
share
microservices
across
the
clusters,
and
others
is
also
based
upon
domain
driven
design,
which
we
have
already
talked
about,
which
was
the
key
reason
for
making
it
easier
to
share
and
organize
micro
services
across
teams
so
for
understanding
the
concept
of
domains
in
others,
we
have
something
called
others
domain
catalog.
As
from
the
picture
we
can
see,
this
is
the
dashboard
of
the
others
and
inside
which
we
have
a
section
called
domains.
A
So
this
is
the
domain
catalog
inside
the
tds,
and
this
domain
catalog
is
designed
to
make
microservices
publishing,
sharing
and
easy
so
microservices
we
use
the
microservices.
So
how
do
we
publish
them?
Where
do
we
publish
them?
And
how
do
we
aware
the
developers
that
are
microservices
has
been
published
and
how
d?
How
do
the
developers
actually
get
to
see
where
are
these
published
and
how
can
they
share
these
microservices
inside
their
applications?
So
all
these
things
things
can
be
done
inside
the
domain.
A
Catalog
of
the
ortelius
developers
can
consume
these
microservices
without
actually
creating
their
own
deployment.
Logic,
as
I
have,
as
I
have
already
talked
about
the
reuse
functionality
of
the
micro
services,
so
others
provides
us
this
functionality
that
we
can
actually
consume
the
pre-created
micro
services
if
they
serve
our
application
as
well.
We
do
not
have
to
really
create
microservice
again
and
again,
so
it
also
provides
microservice.
Versioning
solution
informs
about
the
new
version
to
all
the
linked
applications.
A
For
example,
if
I
have
an
application
which
is
currently
using
three
micro
services
and
one
of
the
microservice
needs
to
get
updated
to
a
new
version,
so
that
application
will
be
informed
as
soon
as
my
microservice
gets
updated
and
will
it
will
be
linked
to
the
new
version
of
the
application
of
the
microservice,
not
the
old
version.
Similarly,
if
that
microservice
is
used
by
any
other
application,
then
that
application
will
also
be
informed.
This
is
the
whole
picture
of
the
ots.
It
follows
a
top
to
down
structure
in
domain
catalog.
A
A
So
ortelius
domains
there
are
various
types
of
ordinance
domains
in
our
otalia's.
First
one
is
side
domain,
so
this
is
the
highest
level
of
domain,
which
I
am
talking
about
so
like
this.
We
can
see
here
the
global
term
written
here.
So
this
is
the
site
domain,
the
highest
level
of
domain
and
the
default
domain.
So
in
others
we
provide
two
types
of
functionalities:
one
is
for
the
sas
users.
Our
rotaries
product
can
be
used
by
software,
can
be
used
as
software
as
a
service
and
also
as
on-prem
tool.
A
So
for
the
sas
users,
this
site
domain
is
defaulted
to
the
company
name,
so
we
can
rename
your
site
domain
if
needed,
and
in
the
case
of
on-premise
installation,
the
default
site
domain
name
is
global,
so
I
have,
I
am
currently
using
the
on-prem
version,
so
in
my
case
it
is
showing
the
global
link,
but
I
can
also
change
that
if
I
need
so
anything
defined
to
this
level
can
be
shared
across
lower
level
sub
domain.
So
whatever
the
functionalities
or
invents
or
environments
and
tasks.
A
A
Next,
we
have
catalog
subdomains.
These
domains
are
used
to
organize
reusable
components
such
as
microservices,
so
inside
catalog
domains
we
publish
our
micro
services
and
at
this
level
we
can
create
as
many
sub
domains
as
we
need
to
represent
our
company
or
our
component
organization
based
on
the
solution
space.
So,
basically,
according
to
the
organization
and
according
to
the
problem
space
of
our
organization,
we
can
create
a
catalog
sub
domain
which
will
publish
our
microservices.
A
According
to
the
solution
space,
we
need,
for
example,
security
services,
purchase
processing
data
access
ad
services.
These
are
all
the
sub
domains
which
I
have
inside
my
site
domain.
A
catalog
domain
does
not
contain
lifecycle
domains.
So
I'll
explain
this
later
on
project
sub
domain.
So
next
we
have
a
sub
domain
called
project
subdomains.
A
So
what
is
project
subdomain?
This
is
a
sub
domain
to
represent
your
software
application
and
its
lifecycle.
So
initially
we
talked
about
catalog,
subdomain
and
site
domain,
which
can
together
be
taken
as
a
problem
space
part
so
like
in
the
case
of
problem
space.
We
had
domain
and
sub
domains.
So
from
the
picture
of
ortelius,
we
can
convey
that
site
domain
is
something
which
resembles
the
whole
domain.
A
Catalog
subdomains
is
something
which
further
divides
that
domain
into
sub
domains,
and
then
project
domains
is
something
which
will
be
actually
responsible
for
creating
our
software
application
and
its
lifecycle.
Software
project
subdomain
is
served
also
as
the
parent
domain
for
our
lifecycle
domain.
A
sub
domain
defined
for
any
application
may
need
a
continuous
delivery
life
cycle.
A
So
whenever
we
create
any
software
application
that
software
application
will
be
having
its
own
life
cycle,
so
from
the
time
it
is
created
from
the
time
it
is
being
tested
from
the
time
it
has
been
deployed
and
any
versioning,
if
has
to
be
there,
so
everything
is
included
in
that
continuous
delivery
life
cycle,
so
it
for
to
define
this
thing.
We
need
to
select
all
sub
domains
or
life
cycle,
which
is
an
option
there.
When
we
create
a
subdomain,
then
it
has
so.
A
If
we
check
this
option,
then
we
are
create
the
then
we
are
justifying
that
my
project
sub
domains
will
also
be
my
lifecycle
domains.
So
this
means
that
any
sub
domain
can
not
include
any
additional
sub
domains
and
will
be
used
to
represent
stages
of
the
pipeline
with
specific
environments
assigned.
So
this
will
clearly
means
that
now
you
cannot
create
any
further
sub
domains
for
this
project.
This
project
will
be
considered
as
the
complete
life
cycle
for
your
software
application,
so
any
versioning.
A
If
you
have
to
do
and
any
updates,
if
you
have
to
do,
then
you
will
be
doing
in
this
sub
domain
only
you
cannot
create
any
other
additional
sub
domain,
so
the
child
domain
of
this
project
domain
is
lifecycle
subdomain.
It
is
the
lowest
level
of
subdomain.
It
is
available
when
you
have
the
parent
domain
project
subdomain
and
which
is
which
is
taked
as
all
sub
domains
are
life
cycle.
A
I
will
be
showing
you
this
point
in
the
demonstration
of
the
others,
these
sub
domains
map
to
each
stage
in
continuous
delivery
pipeline.
So
when
we
declare
a
continuous
delivery
pipeline,
this
sub
domains
represent
a
single
stage
of
your
life
cycle,
so
at
which
stage
your
sub
domain
is
basically,
whether
you
have
it
in
the
development
stage.
You
have
it
in
the
testing
stage
or
you
have
it
in
the
production
stage.
A
They
often
have
specific
environments
and
tasks
assigned
for
interaction
with
your
containers,
delivery
orchestration
engine.
So
if
we
have
to
differentiate
it
from
the
other
subdomains,
we
usually
have
tags
attached
to
it
so
that
make
it
makes
easier
to
identify
the
different
kinds
of
subdomains.
So
those
tags
can
be
attached
in
the
form
of
environment
that
we
are
using
like
production,
testing
or
development
or
any
of
the
tasks
which
has
to
be
assigned.
A
A
Here
we
have
different
micro
services,
for
example,
I
have
a
front
front-end
microservice,
which
will
be
responsible
for
the
front-end
application
of
my
complete
microservice
architecture,
and
this
domain
is
further
divided
into
two
sub-domains,
that
is
the
purchase,
processing
domain
and
the
store
services
domain,
and
these
two
services
have
their
further
sub
domains
that
is
purchase.
Processing
contains
shipping,
microservice
payment,
microservice,
currency,
microservice
and
checkout
microservice
and
store
service
domain
also
has
product
catalog,
ad
service
card
service
and
email
service.
A
So
all
these
sub
domains
are
categorized
into
my
hipster
application,
with
components
so
using
the
project
domain
project
subdomain,
we
have,
we
can
see
all
these
microservices,
which
are
there
in
the
sub
domains.
So,
as
we
can
see
now
we
have
these
seven
micro
services
as
a
whole
in
my
application,
and
we
can
also
see
a
picture
of
the
hipster
environments
that
we
have
so
that
if
we
have
to
differentiate
a
life
cycle
domain
from
another
life
cycle
domain,
we
can
attach
these
environments
to
them.
A
A
A
Here
I
am
logging
in
to
my
other
dashboard.
This
is
the
on-prem
version
of
the
otelias
dashboard,
and
this
is
the
domain
section
as
we
see
so
this
is
the
domain
catalog
of
the
others.
This
is
the
sunburst
map,
which
I
was
talking
about,
which
resembles
all
the
domains
which
I
am
having
in
my
hotelious
dashboard.
This
is
the
global
domain.
Since
I
have
on-prem
version
of
the
audelius,
then
I
am
having
this
global
domain,
which
is
further
divided
into
multiple
sub-domains,
for
example,
this
project,
one
my
pipeline
and
so
on.
A
These
are
all
the
sub
domains
and
inside
these
sub
domains
I
have
further
domains
further
sub
domains
which
can
be
considered
as
my
project
domains.
So
these
this
is
the
development
project.
This
is
the
testing
project.
This
is
the
integration
project
and
so
on.
So
if
we
want
to
see
the
details
of
this
application
or
this
domain,
we
can
get
a
picture
of
it
full
domain.
My
complete
domain
name
is
global
domain.
A
Currently,
I
am
under
my
global
domain
section,
so
it
is
showing
the
full
domain
as
global,
and
we
also
have
the
facility
of
giving
the
access
of
the
owner
has
admin
or
sub
domains
which
are
listed
out
here,
and
then
we
have
access
control
thing,
which
is
something.
So
what
are
the
access
controls
for
my
these
domains?
Who
can
see
it?
Who
can
change
it?
Who
can
read
it?
Who
can
write
it?
A
A
Now
we
can
see
that
the
host
name
has
also
been
changed
earlier.
It
was
deployment
engine.
Now
it
is
our
proxy.
Now
we
have
further
subdomains
inside
it,
that
is,
development,
testing
integration
production.
So
these
are
all
the
details
for
this.
If
I
go
beyond,
then
we
can
see
again.
These
details
get
changed
now.
My
full
domain
changed
to
global
dot
my
pipeline,
so
this
is
the
thing
to
note
that
all
the
domains
in
others
are
resembled
as
objects,
and
these
objects
are
resembled
as
domain,
which
are
distinguished
by
a
period.