►
From YouTube: CQRS and Event Sourcing by examples of Magento MSI
Description
Agenda:
- N-layered architecture
- SOLID
- CQS
- CQRS
- Microservice architecture
- CQRS in Magento 2
- MSI Architecture
- Command/Query segregation in MSI (Stock/Source)
- Reservation mechanism as a way of Event-Sourcing in MSI
- Headless MSI
Useful Links:
Magento Technical Guidelines: https://devdocs.magento.com/guides/v2.2/coding-standards/technical-guidelines.html
CAP Theorem: https://en.wikipedia.org/wiki/CAP_theorem
Starbucks does not use two-phase commit: http://www.enterpriseintegrationpatterns.com/docs/IEEE_Software_Design_2PC.pdf
CQRS by Martin Fowler: https://martinfowler.com/bliki/CQRS.html
Greg Young - CQRS and Event Sourcing: https://www.youtube.com/watch?v=JHGkaShoyNs
Conway's law: https://en.wikipedia.org/wiki/Conway%27s_law
Task-Based UI: https://cqrs.wordpress.com/documents/task-based-ui/
Domain Driven Design by Eric Evans: https://books.google.com.ua/books/about/Domain_driven_Design.html?id=xColAAPGubgC&printsec=frontcover&source=kp_read_button&redir_esc=y#v=onepage&q&f=false
Eventual Consistency: https://en.wikipedia.org/wiki/Eventual_consistency
DDD Quickly: https://www.infoq.com/minibooks/domain-driven-design-quickly
A
A
A
A
So
in
our
case,
we
we
have
all
namespaces
with
her
own
structure
where,
where
we
collected
all
the
corresponding
classes
and
all
of
this
corresponding
classes
were
responsible
for
particular
particular
business
function
and
the
main
the
main
characteristic
of
the
N
layer
at
architectures,
that
all
the
requests,
both
read,
request
and
write.
Requests
coming
from
client
come
from
clients
actually
were
passing
through
all
the
all
the
layers
of
our
system.
So
we
did
not.
A
We
did
not
have
any.
We
still
don't
have
difference
of
processing,
written
write
request
and
both
read
and
write.
Requests
going
through
the
same
layers
of
magenta
architecture
comes
through
the
representation
alrea
layer
coming
through
the
business
logic,
layer
and
the
data
access
layer.
Moreover,
we
have
the
same
entities.
For
example,
we
ever
have
the
same
model,
which
will
process
both
read
and
a
write
request.
A
We
introduced
more
and
more
business
logic
inside
and
they
became
kind
of
kind
of
this
ring
of
the
Sauron
from
Lord
of
the
Rings.
So
this
became
really
monolithic,
Allah
and
in
magenta
in
magenta
we
introduced
a
dependency
injection
and
the
dependency
injection
actually
introduced
made
made
explicit
a
lot
of
stuff
which
were
implicit
before
that,
so
nothing
stays
buried
forever
and
introduced
in
magenta,
and
we
made
all
the
classes
to
say
explicitly
what
was
the
external
dependencies.
A
Also
of
some
object,
orient
object,
oriented
principle,
and
here
you
can
see
the
contract
and
the
earth
constructor
of
one
of
one
of
the
models
we
have.
We
have
my
codebase
and
actually
we
had
the
same
issue
in
magenta
one,
but
since
magenta
to
this
issue
became
more
evident,
came
more
visible
and
people
who
who
used
to
work
with
magenta
one,
were
really
really
curious
and
really
excited
seeing
seeing
these
contracts
in
magenta
two,
but
actually
the
same.
A
The
same
dependency
madness
we
have
in
magenta
Wow
the
one
exception
that
this
dependency
were
not
evident
and
the
contract
was
not
was
not
truly
declared
by
by
entities
and
actually
the
same
big
ball
of
mud.
So
big
ball
of
mud
is
a
is
a
fray
frays
which
which
is
usually
used
by
Martin
Fowler.
So
we
we
got
the
same
big
ball
of
mud
as
a
inter
linkage
of
our
components
so
and
interlink
egde
of
our
modules,
so
not
just
on
the
level
of
classes,
but
also
on
the
level
of
modulus
and
starting
certain.
A
A
We
also
introduced
it
performance
problems
because,
as
you
probably
know,
in
magenta,
we
have
constructor
dependency.
Only
we
don't
have
setter
dependency,
they
don't
have
property
dependency.
We
have
constructor
dependency
only
and,
as
you
can
see,
for
example,
this
this
object.
We
accept
so
many
parameters
actually
for
us,
it
means
for
our
dependency
injection
mechanism
for
our
object
manager.
Actually,
it
means
that
all
these
external
dependencies
should
be
created
before
before.
We
will
actually
create
create
this
object,
and
not
just
all
this
dependency,
but
also
the
pendency
of
this
dependency
also
should
be
created
beforehand.
A
Moreover,
dependency
of
dependency
of
dependency
should
be
created,
so
we
need
to
create
quite
a
lot
of
objects
just
to
create
this
particular
object,
and
we
are
not
sure
that
all
of
this
all
of
these
dependencies
would
be
used,
and
this
is
actually
the
kid
for
us,
because
for
some
of
the
scenarios,
we
did
not
use
many
of
the
external
dependencies
for
some
of
these
scenarios,
but
because
we
use
a
constructor
dependency,
constructor
dependency
injection.
We
need
to
recreate
follow
the
external
objects,
and
that
actually
is
the
reason
why,
in
magenta,
early
stages
of
magenta.
A
A
We
decided
to
strictly
follow
solid
principles
and
actually
solid.
It
came
for
us
as
a
rescue
and
actually
one
of
the
rule.
The
first,
the
first
letter
in
a
in
solid,
actually
responsible
for
singular,
stands,
build
the
principle
and
this
the
constructor
of
the
class
I
was
I
was
shown
you
two
slides
before
that
is
actually.
This
is
the
object
which
can
be
considered
as
a
Swiss
Army
knife,
because
probably
this
this
object.
A
This
model
is
the
really
heavy
weight
and
is
overloaded
with
additional
logic,
and
probably
it
makes
sense
to
decouple
that
object
and
create
several
several
other
independent
object
which
can
be
used
for
each
particular
business
case,
but
not
not
to
introduce
the
got
got
object
and
require
it
in
any
any
situation
when
most
of
the
external
resources
even
know
needed
to
process
particular
quest.
So
we
start
to
follow
the
similar
responsibilities
and,
of
course,
all
other
letters
in
a
solid
and.
A
And
we
declared
that
object.
Decomposition
must
follow
the
solid
principle
for
the
old
newly
created
code
and
for
all
the
code
refactoring
which
we
have.
We
must
follow
the
solid
principles,
and
actually
that
was
the
first
item
we
added
to
the
guideline
and
I
really
recommend
you
to
when
you
write
your
own
logic,
whether
your
Magento
developer,
whether
your
extension
developer
or
your
system,
integrator
I,
really
recommend
you
at
least
to
get
a
awareness
and
read
magenta
technical
guidelines,
because
in
this
document
it's
not
really
a
big
one.
A
We
we
describe
all
the
high-level
architectural
recommendation,
how
we
recommend
you
to
write
the
code
and
what
design
principles
we
recommend
you
to
follow.
And
after
that,
we
also
considered
that
the
cqs
principle
could
be
used
as
well,
because
the
cqs
principle
is
a
he's,
the
one
which
which
really
good
correspond
to
object
to
all
P
or
D
and
solid
and
the
cqs
principle.
The
common
queries
separation
is,
is
not
wearing
you.
So
this
will.
A
A
We
user
have
queries
or
comment
functions
so,
for
example,
in
this
case
you
can
see
that
we
have
a
user
account
and
we
have
a
query
which
is
is
active
which
just
returns
the
state,
so
it
returns
the
state
but
actually
does
not
affect
the
state,
and
we
have
a
comment
activate
which
which
actually
changed
the
state
so
activate
makes
the
state
active,
but
it
does
not
return
the
state,
so
it
returns
void,
which
is
pretty
common,
pretty
common
for
all
the
comment
operation.
So
here
on
the
slide,
you
can
see
the
main
the
main.
A
And
here
we
come
to
the
CQRS,
which
is
looks
like
just
one
more
letter
added
to
the
cqs,
but
actually
it's
little
bit
more
than
just
one
more
letter.
So
the
CQRS
stands
for
the
common
queries
from
stability
segregation
and,
if
you'll
see
our
modules
technical
got
the
guidelines
one
more
time,
you'll
actually
see
that
application
should
be
structured
in
compliance
with
the
secure
as
principal.
So
we
apply
the
secure
as
principal
and
we
recommend,
because
you
see
that
if
we,
if
a
man
when
we
mentioned
solid,
we
use
masks
but
a
reference.
A
The
CQRS
we
are.
We
are
using
shoot
here,
so
we
we
are
really
recommend
to
use
the
secures
as
an
as
a
way
to
segregate
boundaries
of
application
when,
when
developers
and
when
magenta
developers
would
be
structuring
and
structuring
the
application,
what
it
would,
what
actually
CQRS
means
so
referent
to
greg
young
so
greg
young
is
a
guy
who
introduced
the
term
chic
urs.
So
he
mentioned
that
secure
s
is
two
objects
where
there
previously
was
just
one.
So
it's
very
very
easy.
Nothing
can
be
simpler
than
that.
A
So
in
traditional
approach
we
had
like
in
magenta
in
magenta
one
we
had
a
traditional
approach
like
a
street
figher
architecture
and
everything
goes
in
and
out
through
the
one
through
the
one
entry
points.
There
is
one
entry
point
and
all
the
classes
are
used
in
a
CQ
CQ
s.
We
still
use
three
point
on
the
level
of
class,
but
we
have
for
a
different
method,
some
of
them
responsible
for
common
processing,
another
responsible
for
query
processing
with
a
secure
s,
as
Greg
mentioned.
A
A
Responsible
for
command
implementation,
another
one
responsible
for
Aquarians
augmentation,
the
really
simple
design
approach,
so
CQRS
as
simple
as
to
draw
and
hold
so
you
just
need
to
draw
some
circles,
and
after
that
you
drove
the
rest
of
the
whole.
Actually,
it's
not
so
easy
to
implement
proper
secure,
a
solution.
A
Probably
it's
not
so
easy
as
to
draw
and
hole
and
actually
the
reason
why
it's
not
so
easy,
because
a
client
they're
secure
is
you
shouldn't?
You
should
think
about
the
design
of
the
the
main
model?
First.
So
if
you
are
familiar,
if
you
at
least,
if
you
don't
familiar
with
the
domain
driven
design
book
written
by
Eric,
Evans
I
really
recommend
you
to
stop
listening
this
presentation
and
read
this
book
beforehand
and
after
that,
continue
watching
my
presentation
on
YouTube,
because
it
would
be
recorded
and
uploaded
to
YouTube,
but
I
hope.
A
You
are
already
familiar,
because
this
this
big
blue
book
could
be
considered
as
a
Bible,
because
it's
introduced
quite
a
lot
of
a
lot
of
basic
understanding.
How
to
write
really
really
how
to
write
software
for
really
big
and
sophisticated
domains
as,
for
example,
ecommerce
and
the
actually,
when
we,
when
we
want
to
build
a
security
system,
we
need
to
first
to
think
about
our
design
about
our
the
main
design
and
what
what
the
main
operation
and
the
main
processes
we
we
have
in
our
you
know
now
system.
A
So
on
this
diagram.
Actually,
you
see
that
how
how
this
segregation
happens,
that,
for
example,
we
have
a
magenta,
UI
and
all
the
Commons
will
we
go
to
particular
part
of
the
application.
This
particular
part
is
where
you
would
you
would
have
the
men
driven
design,
so
there's
gonna
be
some
common
creation,
and
this
common
creation
would
be
processed
by
the
main
model,
and
we
would
we
would
have
there
some
pretty
sophisticated
validation
mechanism.
A
We
would
have
there
pretty
sophisticated
domain
models
and
quite
a
lot
of
quite
a
lot
of
objects,
processing
this
request
and
afterwards,
the
result
of
this,
this
particular
business
transaction
would
be
persistent,
would
be
persisted
in
in
a
durable
database.
In
our
case,
it's
gonna
be
my
secure
database,
and
here
we
here
how
we
process
a
comment
and
the
another
word
in
another
scenario
we
can
just
you
know
we
could
be
interesting
to
grab
the
data
and
actually
this
this
is
so-called
read.
A
Scenarios
and
the
reach
scenarios
are
much
more
frequently
to
occur
than
as
and
the
scenarios
when
we
need
to
affect
the
data
when
we
need
to
persist
data
so
because
usually
the
principle
of
Parata
so
80
on
20
works
here.
So
we
have
much
more
reached
queries,
comparing
with
write
queries
on
on
e-commerce
stores.
That's
why,
but
for
query
and
for
querying
data.
Actually
we
no
need
to
have
really
sophisticated
and
big
the
main
model.
So
all
we
need
to
do
is
just
to
grab
some
data
from
from
database.
A
Actually
it
could
be
even
database
which
is
optimized
for
reading,
so
it
could
be
in
one
going
to
be,
for
example,
but
not
a
relational
database.
It
could
be,
it
could
be
Sphinx,
it
could
be
elasticsearch,
it
could
be
ready
and
we
can
just
grab
the
data
and
not
drop
this
data
with
really
sophisticated
domain
models,
because
all
we
all
we
need
to
do
you
just
retrieve
the
data
out
of
let's
say
out
of
MongoDB
and
pull
this
data
to
to
our
template,
just
to
provide
an
ability
to
render
data.
A
We
now
need
that
all
the
validation
step
here,
because
we
consider
that
all
our
data,
which
is
stored
in
a
database
is
already
valid
in
a
valid
state.
So
we
just
need
to
apply
the
validation
step
at
the
time
when
we
going
to
apply
some
modification
to
the
data.
So
we
need
to
apply
this
at
the
time
of
the
common
process,
but
not
at
the
time
of
the
query.
Processor.
A
That's
why
we
see
here
that
that's
why
we
see
here
that
query
model
is
really
tiny,
comparing
with
the
common
model,
which
is
pretty
big
one
and
sophisticated
and
very
source
consuming,
and
actually
that's
not
even
all.
So
when
we
are
talking
about
the
CQRS
we
need
to
apply.
We
need
to
consider
that
common
works
with
business
intent,
not
just
a
record,
so
we
are
not
considering.
A
We
are
not
considering
our
operation
and
we
are
not
considering
our
system
as
the
Book
of
Records
so
because
we
are
concerned
with
the
business
intent
and
we
have
where
heaven
and
process
and
all
the
business
operation
and
business
requests,
but
not
working
kind
of
with
the
table
of
record
where
we
change
changing
some
attributes.
So
all
the
data,
menu
and
modification
happen
in
the
system
happen
as
a
result
of
business
transaction.
A
That's
actually
why
Krueger
Crafts
style
is
not
recommended
and
not
compatible
with
the
SecureAuth
and
how
how
you
can
consider
that
what
you'll
actually
get.
If
you
will
decide
not
to
use
karate
style
of
operation,
everything
will
change
in
your
application,
starting
from
the
API,
because
you
would
not
have
something
as
repository,
for
example,
in
our
case,
because
our
repository
actually
created
for
crowd
operation,
but
the
main
difference
would
be
even
in
interface,
so
user
interface
would
be
really
affected.
A
If
you
decide
not
to
use
not
to
use
crud
but
decide
to
use
secure
s
approach,
because
your
user
interface
will
actually
represent
the
business
but
not,
but
not
all
the
particular
changes
in
attributes
which
merchants
can
apply
for
all
the
possible
entities.
So
let's
consider
an
example.
So
here
you
can
see
the
crowd
base
UI,
where
there
is
some
sound
form
which
provides
an
ability
to
to
change.
A
For
example,
it
could
be
drear
a
ticket
and
it's
possible
just
to
edit
all
possible
attributes
of
the
JIRA
tickets,
starting
from
title
description
assigned
to
attribute
and
assign
it-
and
here
is
how
you
can
you
can
update
all
the
possible
attributes.
This
is
actually
pretty
similar
to
magenta
grids.
We
have
an
admin
panel
because
actually
magenta
grids
consider
the
entity
as
a
as
a
record
in
database
and
provide
you
more
fancy
way
for
our
merchants
to
change
the
attribute.
But
actually
the
idea
is
pitch
is
the
same,
so
we
consider
actually
you
I
represent.
A
This
approach
is
called
like
forms
over
data,
so
our
UI
is
just
more
fancy
UI
over
the
over
the
regulation
of
database
way
how
the
attributes
could
be
changed
in
a
table
and
the
contrary
to
contrary
to
the
crowd
base.
Ui,
we
can
have
a
task
base
UI
in
in
a
task
base.
Ui
the
they
seem.
The
similar
tasks
can
be
implemented,
like
let's
say
different
buttons,
and
each
button
represent
particular
action.
So
here
here
we
can
assign
people
to
the
task
or
we
can
complete
the
task
or
we
can
make
some
editing.
A
So
this
is
a
totally
different
way
how
the
UI
could
be
represented.
If
we
decided
not
to
use
a
crowd
UI
in
favor
to
use
the
CQRS
UI
and
the
very
good
example
of
the
task
based
UI
or
how
the
guys
in
microsoft
call
it
inductive
user
interface
is
a
is
a
control
panel
in
Windows,
because
if
they
just
just
imagine
what
what
the
disaster
is
gonna
be.
A
If,
if
in
the
window,
they
are
in
muck,
for
example,
they
propose
not
to
to
change
the
some
particular
setting
based
on
based
on
see
your
own
users
intent,
but
just
provided
some
kind
of
tables
where,
where
users
supposed
to
find
the
proper
attribute
and
manually
change
it,
it
would
be
disaster.
But
now
heaven
is
a
intent,
for
example,
to
change
the
Sun
setting
off
my
sound
card
just
to
make
make
the
sound
louder.
A
The
same
result
but
I'm
following
by
my
intention-
and
here
we
come
as
I
already
mentioned,
and
I
show
you
when
I
show
you
how
the
common
for
assigning
a
sign
in
customer
for
particular
ticket
could
be
created.
I
mentioned
that
the
ticket
could
be
processed
at
synchronously
and
when
we
are
talking
about
a
synchronous
process
and
when
we
are
talking
about.
A
This
merchant
who
cared
for
more
more
transactions,
then
comparing
with
with
those
merchants
who
who
used
magenta
one.
So
actually,
this
introduced
for
us
additional
technical
requirements,
requirements
for
scalability.
First
of
all,
and
if
you
are
talking
about
magenta
one
architecture,
magenta
one
architecture,
it
was
an
layered,
as
we
already
discussed
architecture
based
on
a
seat
compatibility.
So
you
can
see
here
what
it
actually
means.
A
That
means
that
in
magenta
one
we
used
to
have
strong
consistency
and
strong
availability,
and
actually
would
would
cap
serum
says
that
he
there
are
consistency,
availability
and
partition,
tolerance,
and
you
can
choose
just
two
of
these
properties
and
it's
not
possible
to
get
three
of
them.
There
is
no
intersection
of
an
overlapping
of
three
of
these
circles.
A
There
is,
there
is
impossible
to
get
just
an
overlapping
between
two
of
them
and
you
can
see
that
having
a
system
with
strong
consistency
and
availability,
actually
you
lose
their
partition,
tolerance,
what
it
means
that
magenta
one
can't
effectively
scale,
and
we
will
we'll
talk
a
little
bit
more
about
scalability
later.
But
what
is
important
for
us
here
at
this
stage
that
scalability
was
was
about
an
excellent
one
and
usually
scalability
for
Magento
one,
and
actually
we
we.
A
It
was
pretty
because
Kimo
when
a
replication,
especially
master-slave
replication,
was
used,
and
there
was
one
master
and
many
slaves,
but
when
it
comes
to
scalability
of
master,
so
the
scalability
of
the
part
which
is
supposed
to
affect
the
data,
our
Comment
operation.
It
was
also
a
problem
and
now.
A
In
Magento
to
is
well,
it
was
made
a
decision
to
go
towards
towards
the
base
verdict,
so
the
what
was
it
actually
a
seed?
So
I
see
this
atomicity
consistency,
isolation
and
durability.
So
actually,
this
is
most
most
of
the
properties
of
the
transactional
system
in
a
relational
database
management
system.
A
We
check
whether
that
transaction
completed
on
all
of
the
notes,
so
it's
pretty
pretty
sophisticated
and
we
will
do
have
a
lot
of
network
communication
with
this
process.
So,
as
a
result,
more
than
modern
distributed
system
started
not
to
rely
on
the
consistency
but
to
choose
a
partition,
tolerance
and
availability.
A
Actually,
this
is
this
is
a
reference
to
a
pretty
dated
dated
design
article,
but
it's
really
really
actual
in
the
nowadays.
So
you
can
you
gonna
read
it
still
and
the
name
of
their
article,
Starbucks
Starbucks,
doesn't
use
it
to
face
committee.
Actually,
the
article
tries
to
show
that
this
is
actually
mentality
of
most
of
software
developers.
That
a
seed
is
the
only
correct
way
to
have
the
data
consistency,
but
in
most
of
businesses.
A
Eventual
consistency
is
more
natural
and
more
proper
way
of
doing
things
and,
for
example,
Starbucks
was
taken
as
an
example,
where
were
client,
make
an
order,
and
and
a
guy
on
a
cash
on
a
cash
desk
who
could
receive
this
order
immediately,
provide
and
immediately
transfer
this
order
to
barista
who
start
making
a
coffee,
and
there
is
potentially
situation
when
the
client
will
change
his
opinion
and
he
will
decide
to
order
not
a
lot
but
cappuccino.
For
example,.
B
A
Barista
will
will
switch
to
end
them
and
a
guy
who
received
an
order
will
switch
to
barista
immediately
and
ask
to
prepare
not
a
lot
about
cappuccino
and
probably
barista.
We
would
be
already
in
the
middle
of
process
making
of
making
water,
and
this
water
would
be
potentially
even
spoiled,
if
not
after
no,
but
nobody
after
this
guy
will
decide
to
order
a
lot.
But
still
this
is
a
business
model
where
the
eventual
consistency
and
the
possibility
to
lose
some
data
works
perfectly
well
for
real
business.
A
So
just
imagine
what
would
be
if
client,
who
makes
an
order,
will,
let's
say,
open
a
transaction
to
the
guy
who
receive
that
order.
That
guy
who
receives
that
order
transmit
this
request
to
barista
and
the
system
would
be
blocked
until
the
time
when
barista
will
finish
the
cappuccino,
for
example,
and
provided
cappuccino
to
a
guy
who,
on
a
cash
desk
and
after
that,
the
guy
who
actually
order
the
culture.
A
So
the
whole
system
would
be
blocked
for
quite
a
long
time
and
that
would
would
be
would
prevent
for
all
the
for
all
the
clients
who
were
waiting
in
the
queue
to
make
to
make
an
order,
and
now,
let's
consider
how
the
CQRS
applicable
for
the
net
and
network
transaction
and
how
they
secure
s
could
be
applied
over
there
HTTP.
So
we
have
the
the
get
safe
request
for
query
and
we
have
the
post
put
delete
and
part
not
safe
request
for
comment.
A
So
securest
works
perfectly
well
with
with
restful
architecture,
but,
moreover,
it
is
pretty
interesting
because
if
we
consider
the
crud
operation
and
the
legs
secure
s,
so
currently
we
make
the
we
make
the
change
of
the
data.
With
the
poot
query.
We
make
the
removal
of
the
entity
with
delete
query
and
we
create
the
entity
with
the
post.
Query
post
comment,
but
applying
the
security
principle
you
can.
A
You
can
actually
end
up
with
zone
the
post
query,
because
you
will
just
create
a
comment,
and
that
could
be
a
comment
for
a
result
and
the
result
of
that
common
would
be
to
remove
entity
or
to
update
entity
or
to
create
entity.
But
actually
what
do
you
do
from
the
from
the
HTTP
endpoint?
You
just
create
a
comment,
so
the
CQRS
Debbie
I
could
be
slightly
different,
comparing
to
what
we
used
to
have
with
a
cross
web
api
under
sakura-san
MVC.
A
So
you
used
to
have
such
such
implementation
of
an
MVC
in
magenta
one
when
we
help
when
we
had
the
only
entry
point,
controller
and
the
same
controller
was
used
for
both
query
operation
and
for
comment
operation.
Moreover,
in
in
a
query
operation,
we
manipulate
it
with
the
same
models
because
we
did
not
differentiate.
We
didn't
secure
gate
models
for
query
and
for
comment.
A
User
can
retrieve
retrieve
the
representation
of
this
entity,
and
so
now,
instead
of
one
query,
we
our
client
supposed
to
have
two
different
queries:
post
query
for
updating
the
data
and
afterwards,
following
the
redirect
link,
we
we
can
retrieve
the
representation
of
state
of
this
particular
entity.
And
now
we
started
to
follow
this
MVC
approach.
And
if
you
use
this
MVC
approach,
we
consider
it
as
a
correct
one
and
if
you
follow
it,
this
guy,
who
is
our
director
of
all
architect,
architects
and
who
represent
their
architectural
organization,
would
be
really
satisfied.
A
A
A
Is
so
so
less
because,
probably
you
you
forgot
about
some
transaction,
or
maybe
your
your
wife
made
some
transaction
with
your
credit
card
and
you
are
just
unaware
about
these
transactions
so
and
all
of
this
all
of
this
state
is
built
upon
all
the
transaction
mate
and
the
idea
that
this
transaction-
never
this
events
and
never
never
removed
from
this
system,
and
so
this
is
actually
the
process
which
can
be
gathered,
appliance
a
secure
s
and
the
even
sourcing.
So
we
have
a
history,
you
can
rebuild
the
state
for
every
given
point
of
time.
A
You
have
a
high
scalability,
because
all
the
operation,
all
the
all
your
transaction,
is
append-only
and
you
no
need
anymore
to
make
really
big
computational
logic
at
the
time,
for
example,
at
the
time,
for
example,
when
one
client,
when
customer
making
order
placement,
because
before
that
or
the
replacement
was
and
actually
still
is,
a
big
big
heavy
operation,
because
we
need
to
make
a
lot
of
checks,
etc.
And
after
that
we
need
to
initiate
payment
transaction.
A
Low
latency
writes
and
allows
asynchronous
processing
and
actually
synchronous
us
an
ability
to
postpone
all
the
heavy
computation
when
the
when
the
when
the
client,
when
the
customer
will
already
leave,
leaves
aside.
So
we
process
the
payment,
for
example,
and
afterwards
we
start
processing
all
the
heavy
computational
operations
afterwards.
A
Application
of
the
multi
service
architecture
in
the
Animus
MSI
and
the
micro
services
is
the
next
step
towards
of
magenta
to
development
and
magenta
to
design.
So
that's
why
it's
really
important
to
understand
the
way
where
a
magenta
2
is
going
and
the
micro
service
architecture
can
be
considered
as
an
alternative
way
of
building
application
to
Manolis
and
magenta.
As
we
already
discussed,
magenta
one
was
was
a
really
good
example
of
an
analytical
system.
So
here
is
the
here
is
the
book
which
I
really
recommend
you
to
read.
A
If
you
want
to
to
make
a
deep
dive
into
the
into
the
micro
service
architecture
and
how
to
how
to
build
precisely
the
micro
service
architecture,
so
if
you're
talking
about
the
manalese
and
the
micro
service
from
the
especially
from
the
scalability
standpoint,
you
can
see
that,
for
example,
magenta
one
can
be
can
be
scaled,
just
replicating
the
whole
box
with
magenta
one.
So
we
even
if
we
have
the
bottleneck,
for
example,
energy
called
process.
A
We
still
would
to
deploy
the
who,
the
who
magenta
instance,
even
if
you
don't
really
need
some
resources,
for
example,
for
search
or
for
catalogue
or
for
reporting
we'll
still
need
to
deploy
all
of
the
books
with
with
a
home
agenda
representation,
because
this
is
how
magenta
wanna
scale.
But
if
we're
talking
about
micro-service
approach
here,
we
can
allocate
more
particular
resources
for
particular
particular
services,
which
should
be
scaled.
So
here
you
see
that
we
scale
particular
services
but
not
replicate
the
holdings
of
magenta.
A
A
Such
perspective,
because
because
merchants
will
pay
for
utilization
of
the
resources
and
when
we
are
talking
about
the
micro
service
approach
means
we
need
to
mention,
reconvey,
slow
and
actually
Conway's
law
is
really
important
for
there's.
Probably
this
is
a
ground
ground
base
rule
for
micro
services
and
the
the
Conway's
law
says
that
any
organization
that
designs
the
system
will
produce
a
design
whose
structure
is
a
copy
of
the
organization's
communication
structure.
A
And
you
probably
know
that
in
magenta
one
we,
our
organizational
structure
was
divided
on
layers
by
by
means
of
by
means
of
responsibilities
of
people.
So
we
had.
We
had
Quality
Assurance
engineer
represented
one
layer.
We
had
the
UI
specialist
represented
by
another
layer.
We
have
a
PHP
developers.
A
That
was
a
major
layer
because
we
mostly
have
HP
developers,
and
we
had
several
DBA
experts
and
all
the
PHP
developers
actually
were
responsible
for
different
parts
of
the
system
and
that
actually
made
a
result
of
producing
eventually
a
system
which
could
be
considered
a
big
ball
of
mud.
Because
we
have
quite
a
lot
of
internal
linkage
and
we
have
a
system
with
a
really
big
coupling
and
location
and.
A
That
that
was
an
actually
an
idea
to
make
a
cross-functional
teams,
and
that
was
a
step
made
in
Magento
internal
structure
and
magenta
internal
structure
start
to
represent
cross-functional
teams,
and
these
teams
are
responsible
for
particular
particular
functionality
in
the
system.
So
we
have
teams
responsible
for
four
different,
four
different
modulus
or
the
main
areas,
and
actually
such
structure
as
such
structure
supposed
to
create
the
correct
boundaries
and
correct
command
correct
dependencies
between
other
bit
even
other.
The
main.
A
The
main
boundaries,
for
example,
like
catalog
scout
inventory,
allows
that
supposed
to
supposed
to
introduce
the
correct
dependencies,
because
there
is
an
ownership
introduced,
introducing
a
level
of
teams.
So
a
group
of
specialists
who
understands
particular
domain
better
than
others
and
what
is
very,
very
important
from
the
micro
service
standpoint
that
each
the
micro
service
supposed
to
have
own
database.
A
A
A
It
could
be
warehouses,
it
could
be
brick-and-mortar
stores,
it
could
be
stimulus,
centers,
it
could
be
drop.
Shippers
and
the
request
for
MSI
gets
more
and
more
common
from
our
developers
from
our
merchants,
because
initially
we
get
this
request,
mostly
from
the
b2b
merchants,
but
but
for
recent
years,
because
a
Magento
started
to
be
oriented
starts
to
be
more
friendly
for
big
merchants.
We
started
to
get
the
request
for
MSI
even
for
b2b
to
see
signal.
That's
why
we
decided
to
implement
multi-source
inventory
as
a
part
of
the
b2c,
so
it
would
be.
A
It's
supposed
to
be
available
for
most
b2b
and
b2c
merchants,
and
actually
this
is
how
they
initial
initial
acceptance.
Criteria
for
MSI
story
looks
like
so
it's
a
merchant
I
wanted
to
manage
stock
in
multiple
locations
so
that
they
can
reflect
my
physical
inventory
in
magenta
without
extension
or
customization,
so
sounds,
sounds
simple,
but
that
was
just
the
beginning
of
a
really
long
story
which,
which
is
actually
still
still
continue
and
a
little
bit
of
history.
A
So
here
you
can
see
the
initial
epoch
because
usually
the
MSI,
the
the
first
name
for
a
messiah,
was
a
man
I
multi-node
inventory'
was
created
internally
and
the
internal
team,
whose
name
is
dragon,
was
tried
to
implement
MSI
three
times
in
a
row.
So
we
tried
to
implement
MSI's
three
times
in
a
row
and
because
of
different
issue.
A
We
postpone
this
process
three
times
in
a
row
and
afterwards
that
that
we
decided
to
make
a
implementation
with
the
help
of
community
contribution,
but
actually
the
main
problem
we
stuck
internally
was
that
performance
degradation
on
at
the
time
of
the
order.
Placement
which
can
be
controlled
at
all
as
computational
source
selection
could
be
very
time-consuming.
A
So
our
initial
implementation
was
made
the
way
that
we
introduced
the
source
selection
algorithm
so
that,
at
the
time
of
the
order,
placement
magenta
supposed
to
make
some
kind
of
the
calculation
and
provide
and
provide
the
provide,
the
sources
from
which
the
order
could
be
fulfilled
so
provide
the
sources.
So,
by
means
of
sources
we
can
call
warehouses
were
stores,
so
we
will
recall
this
entity
s
sources.
So,
at
the
time
of
the
order,
placement
magenta
provided
a
list
of
sources
which
was
supposed
to
be
used
for
order
fulfillment
and
for
the
sources
we
made.
A
We
made
the
stock
deduction
and
we
got
just
incredible
performance
degradation
because
heavier
taken
into
account,
for
example,
just
consider
that
you
have
one
one
item
in
the
quantity
of
two
in
a
shopping
cart,
and
there
are
two
warehouses
each
of
each
of
these
were
can
allocate
this
product.
So,
even
though
for
disease,
the
simplest
case,
there
are
three
variation:
how
this
product,
how
this
order
could
be
fulfilled.
A
So
we
can
make
the
who
delivery
of
two
pieces
of
these
products
from
the
warehouse
a
we
can
make
a
full
delivery
of
this
product
two
pieces
of
this
product
from
warehouse,
B
work.
We
can
split
and
make
a
delivery
of
one
piece
of
this
product
from
warehouse
a
and
another
piece
of
this
product
from
warehouse
B.
So
there
are
three
variation
was
the
simplest
case
and
if
just
imagine
what
will
happen
if
we
have
say
20
or
30
products
in
a
shopping
cart
and
we
have
tens
of
sources
created.
A
So
the
number
of
variation
is
just
just
incredible,
just
huge,
and
if
you're
talking
about
the
b2b,
when
the
shopping
cart
can
contain
up
to
hundreds
of
products,
the
number
of
variation
is
just
just
infinite,
so
it
wouldn't
be
possible
to
to
wait
to
the
end
of
checkout,
because
our
our
checkout
process
will
run
infinitely
and
probably
customary
ki
can
die
beforehand
before
we
will
process
an
order.
So
that's
why
we
we
understood
working
on
a
core,
that
a
seat
is
not
compatible
for
us.
A
Not
actually,
it
doesn't
work
for
us,
even
if
you
would
have
really
really
performed
friendly
algorithm.
We
would
not.
We
would
not
even
control
the
performance
degradation
we
introduced
at
the
time
of
Chicago,
but
for
us
it
was
really
important
not
to
introduce
any
performance
degradation
at
the
time
of
check
out,
because
checkout
should
be
much.
A
So,
just
to
show
that
missus
pretty
big
project
just
in
numbers,
so
we
we
had
70
different
individual
contributors
who
represent
16
different
agencies
and
who
submitted
for
us
six
more
than
six
hundred
coolest
small
technical
overview
and
the
size
of
the
project
so
currently
msi
is
contains.
33,
modulus
and
msi
represents
approximately
12%
of
the
cool
magenta
modulus
code
base,
so
just
to
make
a
short
introduction.
As
I
already
said
in
a
multi,
we
have
such
base
entity
which
represent
source
in
our
case
source
is
a
cool,
can
can
be
considered.
A
It
is
a
warehouse,
a
brick-and-mortar
store,
a
distribution
center
or
drop
shipper.
The
sources
are
combined
in
virtual
aggregation,
this
virtual
aggregation.
We
can
recall
stocks
and
the
stocks
our
sales
channels
when
we
say
the
sales
channel
in
Magento.
We
have
implementations
the
sales
channel
as
a
website,
but
potentially,
for
example,
for
b2b
the
sales
channel
can
represent
the
customer
group
or
in
a
project
where
we
export
the
catalog
data
to
Amazon.
A
For
example,
sales
channel
could
be
considered
as
a
catalog,
but
currently
out
of
the
box,
we
have
the
only
implementation
of
a
sales
channel
or
implemented
by
Magento
website,
so
any
sales
channel.
So
any
website
has
one
and
only
stock
assigned
to
it,
but,
along
with
that,
one
stock
can
be
reused
by
several
which
sell
several
websites
and.
A
In
in
in
technical
implementation,
our
stops
are
can
be
considered
as
an
index.
So,
for
example,
you
can
have
three
different
warehouses
like
warehouse,
one
warehouse
to
warehouse.
Three
and
all
of
these
warehouses
combine
together
for
this
particular
UK
UK
stock,
and
when
we
say
combine,
we
actually
mean
that
quantity
of
four
particular
product
with
the
would
be
just
would
be
just
summed
up
and
we
will
get
an
aggregated
quantity
for
this
particular
product
in
this
particular
stock
and.
A
Now
now
regarding
the
boundaries
and
now
regarding
the
what
what
actually
is
a
comment
and
query
operation
and
in
Amazon,
so
they
already
told
it-
was
not
possible
for
us
to
process
to
process
an
order
if
we
apply
the
source
selection
algorithm
the
time
of
the
order
place.
That's
why
we
decided.
Actually,
we
decided
to
follow
the.
A
So
this
is
actually
how
this
process
looks
like,
for
example,
let's
consider
we
have
two
warehouses.
This
warehouse
is
combined
combined
in
one
stock
and
we
have
five
quantity:
five
in
a
France
and
quantity,
ten
and
Italy
altogether.
We
have,
we
have
15
items
and
we
call
this
quantity
as
a
saleable
quantity,
and
there
is
no
any
reservation
yet
after
that
customer
comes
and
buy
five
products
and
what
we
do
we
just
greater
servation.
At
this
moment
we
don't
have
any
clue
from
which
warehouse
we
will
process
recorder.
A
Computational
logic
at
this
point
of
time,
all
we
do
is
just
create
append
on
the
reservation.
That's
why
the
order
placement
works
really
fast
and
we
are
not
affected
with
a
number
of
sources
assigned
to
this
stock,
because
at
the
at
the
order
placement
time
we
are
working
with
the
stock,
and
actually
this
means
that
our
system
is
agnostic
to
the
fact
whether
is
multi
stock,
a
single
stock
because
we
are
working
with
a
stock
and
the
stock
is
a
level
of
abstraction
and
it
hides
the
the
reality.
A
How
many
forces
we
have
under
the
hood.
So
you
see
that
we
just
created
a
reservation
in
our
saleable
quantity.
So
we
have
a
service
which
calculates
a
saleable
quantity
and
saleable
quantity,
provides
a
value
like
get
the
data
from
index
from
our
state
15
and
apply
the
reservation,
so
15
plus
-5
give
us
10,
so
the
saleable
quantities
10
and
now,
for
example,
the
customer
decided
to
return
three
items
of
this
product
and
taking
into
account
that
we
still
didn't
have,
did
not
have
a
decision
from
resources.
We
will
fulfill
the
order.
A
But
out
of
the
box
time,
do
we
have
priority
based
algorithm,
which
is
pretty
pretty
fast
to
run,
but
still
it
can
take
some
time.
That's
why
we
run
it
already
afterwards,
so
we
run
it
at
the
time
when,
when
water
already
placed-
and
the
moreover,
is
already
invoiced
so
the
one
who
will
wait
for
result
of
the
source,
selection,
algorithm,
urgent
or
admin,
but
not
client,
but
not
customer,
so
risk
is
we
create
the
compensation
or
reservation,
and
we
made
the
decision
that
order
would
be
fulfilled
from
friends.
A
So
we
update
the
quantity
for
french
warehouse
and,
as
a
result
of
it,
we
also
rebuild
the
index.
So
now
in
our
index
we
have
short
team
and
that's
why
we
had
to
create
a
compensation
reservation.
So
we
have
our
saleable
quantity
equation,
looks
like
13,
plus
-5,
Plus,
3
plus
2,
which
give
us
result
in
value
as
13,
and
then
we
have
a
process.
So
this
is
actually
how
our
reservation
look
like
in
a
in
a
system,
and
this
reservation
can
be
considered
as
a
event
log.
A
So
we
have
a
cron
job
to
clean
up
all
the
reservation,
but
also
we
consider
that
some
of
the
some
of
the
merchants
can
consider
consider
it
useful
to
to
save
this
reservation
and
not
remove
it
likely
like
in
a
typical,
even
sources
system,
but
potentially
potentially
here's
the
process
for
this
remote.
But
this
is
up
to
up
to
merchants
whether
they
need
to
around
the
this
cron
job
or
not,
because
a
reservation
is
taking
into
account
that
we
have
a
compensation.
Reservation
reservation
would
not
effects
in
the
type
since
that
time.
A
On
the
on
the
total
number
of
this
available
quantity.
Well,
you
see
that
we
get
back
to
the
previous
state,
so
our
step.
Nine
is
exactly
the
same
as
the
step
one,
and
this
is
how
the
eventual
consistency
work.
So
this
has
immediate
consistency
and
we
usually
go
with
a
seed,
but
our
our
system
get
into
the
consistent
state
after
some
time
like
on
a
step,
nine
and.
A
Here
here
the
examples
was
the
extension
point
on
MSI
and
also
another.
Another
very
important
part
mention
that
on
MSI
will
make
differentiation
between
modules,
so
we
make
a
segregation
between
API
modules
between
implementation,
so
modules,
which
contained
just
implementation
for
the
for
the
api's
and
also
we
make
irrigation
between
admitted
here
so
typically
for
such
module.
As
inventory,
we
have
for
such
functionalities
inventory.
We
have
four
different
modules:
inventory
API,
which
contains
all
the
all
the
service
layer
and
all
the
API
provided
by
inventory.
A
We
have
inventory
module
which
provide
the
implementation
of
business
logic,
physics,
chemistry,
API
interfaces.
We
have
admin
UI
and
so
the
UI
supposed
to
be
used
in
the
for
admin
hiring,
and
we
have
inventory
front
in
here.
So
the
main
idea
here
why
we
have
a
differentiation
between
admin,
UI
and
front.
So
probably
we
can
later
we
can
use
different
stack
of
technology
for
admin.
A
Ui
and
front-end
UI,
for
example,
for
frontier
I,
would
use
a
pw
a
stack
of
Technology
and
PW
a
studio,
but
for
admin
UI
we
would
still
use
the
UI
components,
because
we
already
have
quite
a
lot
of
your
components
like
Greed's
and
for
many
operations.
They
are
pretty
pretty
handy
and
that's
why
we
consider
that
potentially
possible
to
have
different
stack
of
technology
for
admin,
UI
and
front-end
di
this.
Why
we
make
a
segregation
on
the
level
of
modules
between
admin
area
and
fronting
area?
A
And
here
you
can
see
also
the
positive
outcome
of
this-
that
you
can
deploy
magenta
with
msi
as
a
headless
and
use
headless
msi
under
because,
for
example,
msi
is
such
functionality
so
inventory
such
functionality
when
merchant
usually
make
an
integration
with
an
external
earpiece
system,
and
they
no
need
to
utilize
any
UI
on
the
level
of
magenta
because
they
they
will
use.
Ui
means
this
third
party,
europe
Eastham
and
a
really
good
example
of
this
kind
of
integration
with
magenta
order
management
so
which
is
also
magenta
product
and
magenta
order.
A
Management
actually
doesn't
want
to
provide
any
any
source.
Manipulation
with
the
level
of
magenta,
so
all
the
manipulations
should
be
done
on
the
level
of
magenta
order
management.
That's
why,
for
example,
merchants
in
this
case
would
not
deploy,
deploy
modulus
with
admin
UI
at
all
and
because
all
the
admin
menu
creation
would
be
done
from
the
side
of
magenta
order
management.
That's
why
you
can
consider
msi
as
msi,
headless
plus
UI
and
the
war
headless
UI.
A
We
have
dependence
on
sales,
catalog,
catwalk,
inventory,
legacy
store
and
all
product
types,
but
if
you,
if
merchants
would
like
to
use
msi
UI,
which
is
also
provided
as
a
part
of
msi,
there
would
be
additional
dependency
on
UI
module
back
and
reports
directory
and
shipping.
So
it's
pretty
interesting-
and
here
you
see
the
street
for
a
diagram
of
the
micro
service,
implementation
of
msi
and
emergent.
B
A
Probably
we
already
out
of
time
so
I'm
sure
that
we
have
a
time
for
asking
question.
So
probably,
but
you
can
reach
me
by
email
or
in
Twitter
or
in
community
such
channel,
but
if
there
are
guys
who
are
not
in
a
hurry
and
the
health
question
and
ready
to
all
to
ask
them
now
feel
free
to
do
it
and
I
will
try
to
answer
I.
A
A
B
A
B
B
A
A
B
A
B
B
A
The
main
AG,
here's
that
MSO
inventory
there
are
a
lot
of
different
schemas
how's.
The
inventory
can
be
integrated
with
external
Europe
assistance.
For
some
of
this
integration,
magenta
can
be
considered
as
a
source
of
tools
for
order
management
for
other
for
other
synchronization
schema.
Even
might
winter
could
be
considered
as
a
source
of
truth
for
source
management
and
the
stock
management,
but
or
for
for
other
synchronization
human.
All
the
source
and
stock
management
can
be
a
responsibility
of
external
system.
A
So
in
this
case
we
no
need
to
provide
in
magenta
any
any
UI
which
provides
all
stock
manipulation,
because
in
this
case
we
need,
we
will
end
up
with
be
directional,
synchronization,
so
merging
supposed
to
send
data
to
your
piece
system
and
also
your
pieces,
the
rules
and
data
to
magenta.
So
it's
it's
very
complicated
to
support
the
B
direction
or
synchronization.
That's
why
we
provide
all
the
UI
for
all
the
admin
UI,
and
actually
we
would
not
make
any
differentiation
at
the
time
of
the
migration.
A
B
B
A
So
currently,
our
our
front
tent
works
with
not
sources
but
with
stock
instead.
So
when
we
place
order,
we
just
say
that
we
created
particular
servation
in
a
given
context.
You
know,
in
our
case,
it's
-5,
for
you
are,
is
Q
on
a
particular
sales
channel,
so
on
a
particular
website,
and
we
dis
actually
all
so
we
don't.
We
know
nothing
about
the
sources
which
would
be
used
underneath
and
we
get
the
awareness
of
sources
just
at
the
time
when
we
start
to
process
this
order.
A
So
replying
to
your
question,
actually
we
apply
source
selection
in
the
scope
of
the
order.
So
if
you
place
this
order
like
yeah,
so
just
a
measuring
here,
we
we
have
an
order
which
contains
two
products
and
the
first
one
was
bought
in
a
quantity
25.
Another
was
bought
in
a
quantity
of
10
and
there
are,
there
are
3
different
sources
from
which
this
product
could
be
could
be
delivered.
A
So,
actually,
here
on
this
stage,
we
will
already
place
an
order,
so
we
will
work
in
the
scope
of
this
particular
order
and
now
when
we
will
create
a
shipment,
so
the
shipment
document
has
a
limitation.
So
it's
supposed
to
have
one
row
and
one
two
points:
that's
why
we
will
create
a
here.
We
will
choose
a
source
file,
for
example
journal,
and
we
will
create
a
particular
shipment
for
each
particular
source.
A
B
A
A
So
if
we
consider
that,
for
example,
another
customer
comes
to
our
website
and
he
wants
to
buy
fifteen
items
of
this
product,
he
would
not
be
able
to
do
this
because
how
our
saleable
quantity
now
is
ten,
so
it
contains
15
plus
minus
five,
so
we
already
reserved
five
items
for
the
first
customer
who
placed
an
order.
First,
all.
B
A
B
A
So
actually,
there
is
no
like
proper
answer
to
your
question
because
it's
really
dependent
on
how
you
make
it
synchronization
with
external
system,
because
whether
you
a
world
and
not
to
make
a
synchronization
when
you
have
an
open
reservation,
because
you,
you
may
take
this
reservation
into
account
or
you
can
just
ignore
them.
So
this
you
are
in
charge
whether
to
take
them
into
account.