►
From YouTube: Modular Monolith AMA w/ Philip Müller
Description
GitLab folks are working on a proposal on how to decompose the monolith into modules. This AMA with Philip Müller was an open discussion and informal knowledge exchange around modularizing large-scale codebase.
For more information, please see this GitLab issue:
https://gitlab.com/gitlab-org/gitlab/-/issues/365293
B
C
Yeah,
I
think
this
is
probably
the
same
like
it's
it's
the
typical
stuff.
It's
like
it
was
hard
to
onboard
developers.
It
was
getting
harder
to
onboard
developers,
it
was
getting
harder
to
ship
things
in
general,
but
it
was
especially
getting
harder
to
ship
sting
things
without
breaking
other
stuff
and.
C
Is
is
like
implement
like
not
like
a
detail
of
that,
for
example,
the
test
suite
got
really
slow
and
flaky,
and
and
that
kind
of
stuff
I've
I've
just
actually
skimmed.
The
the
gitlab
proposal,
split
kit,
lab
monitored
into
components,
and
I
think,
like
the
the
paints
that
are
in
there
are
very
similar
to
the
paints
that
we
had.
C
Kind
of
following
along
at
that
point
and
joined
in
later,
but
what
they
did
to
kind
of
argue
for
the
project
in
the
beginning
was
well.
They
they
gave
the
list
of
these
problems,
but
they
also
had
a
graph
that
showed
that
just
the
number
of
commits,
like
the
number
of
commits
on
the
code
base,
was
actually
plateauing.
C
B
C
B
C
C
A
C
C
Shopify
hasn't
made
a
lot
of
progress
on
that.
As
far
as
I
can
tell
from
my
position
today,
so
like
one
of
the
goals
in
the
beginning
was
that
we
would
be
able
to
have
a
completely
separate
test
suite
component
so
that,
like
we,
we
would
know
which
code
to
load
to
test
a
certain
component.
So
I
mean
there
are
two,
I
think,
useful
approaches
to
this
either
to
say
I
if
I
want
to
test
component
a,
I
only
want
to
load
component
a
like.
I
want
to
test
it
in
total
isolation,.
C
We
we
decided
against
that
pretty
early
because
it
requires
so
much
plugging
things
in
at
runtime
and
dependency
injection,
which
we
knew.
We
were
not
very
good
at
that
point
very
good
at
at
that
point.
So
what
we
were
aiming
for
was
like
as
a
relatively
sparse
dependency
graph
or
we
can
say.
Okay.
If
we
want
to
test
this
component,
we
load-
I
don't
know
five
to
ten
other
components,
maybe
but
not
the
whole
code
base.
We
we
had
at
some
point.
C
We
we
had
between
30
and
40
components,
which
was
much
more
than
I
thought
we
should
have,
but
yeah.
That
was
the
number
that
we
that
we
had
and
and
yeah.
So
so
we
never
got
to
that
level
of
isolation
that
we
could
actually
do
that.
Splitting
up
the
test,
suite
and
similar
with
other
things
where
it
would
have
been
nice,
like
a
certain
level
of
isolation,
would
have
enabled
us
to
just
have
a
separate
database
by
component.
C
C
A
C
In
the
end,
so
we
we,
we
also
had
in
the
in
the
early
days
of
componentization
the
the
group
of
people
that
started
the
work
were
of
the
opinion
that
it
would
be
a
good
idea
to
take
a
small
part
of
the
code
base
and
get
it
into
an
exemplary
state
and
then
hope
that
people
will
just
see
that
and
and
understand
that
it's
obviously
better
than
what
we
had
in
other
parts
of
the
code
base
and
copy
it.
And
that
way
it
would
spread.
C
So
we
tried
that
I
do
think
we
learned
stuff
from
it,
but
it
didn't
spread.
So
then.
The
first
thing
that
I
did
when
I
took
over
the
effort
was
to
kind
of
jump
to
the
other
extreme
and
say
we
need
to.
We
need
to
kind
of
almost
like
not
dictate,
but
but
communicate
from
from
a
central
team
that
everything
is
going
to
be
done
like
this
now.
But
then
the
problem
with
that
was
you,
like.
C
A
centralized
team
cannot
know
enough
about
all
aspects
of
the
code
base
to
really
make
good
recommendations,
and
if
you
take
too
much
autonomy
away
from
people,
they
will
think
less
and
just
do
whatever
they
are
told,
and
then
that
might
not
actually
be
a
good
idea
in
all
cases,
and
it's
it.
It
turned
out
to
be
a
pretty
bad
idea
in
some
cases.
C
So
I
now
think
that
the
the
there
is
a
there's,
probably
a
middle
ground.
That
is
good
where,
where
teams
keep
autonomy
a
lot
of
autonomy
about
how
they
do
things,
but
there
are
there's,
there's
some
basic
alignment
facilitated
by
some
kind
of
centralized
entity,
and
maybe
maybe
that's
just
simple
things
like
these-
are
the
components
and
we
don't
want
like
we
want
that
dependency
graph
to
not
have
cycles.
Maybe
that's
just
the
that's
the
level
of
of
like
rules
and
then
everything
is
autonomous.
C
It's
probably
not
exactly
that.
I
haven't
had
the
opportunity
to
really
try
to
put
that
into
practice
in
well
in
in
in
a
larger
way.
We
only
started
doing
that,
and
then
we
resolved
the
team
a
few
months
later,
but
yeah.
I
think
I'm
not
I'm
not
sure
which
question
I'm
answering
now.
Sorry,
if
I'm
rambling.
A
B
A
E
Actually,
I
wanted
to
unpack
this
a
bit
more
because
I
had
a
similar
question
and
because
we
talked
about
this,
is
you
know,
yeah
quantifying
this
problem,
which
is
really
hard
like.
We
realized
that
as
well
and
yeah,
it's
funny
that
you
mentioned
commits
and
how
it's
not
a
great
metric
for
productivity.
When
I
joined
gitlab,
I
was
kind
of
surprised
to
see
that
we
used
a
similar
metric.
E
We
use
merge,
requests
not
commits
directly,
but
we
measured
like
throughput
and
it's
not
the
only
metric
we
use,
obviously,
but
but
it's
some
kind
of
proxy
for
productivity
at
gitlab.
It's
the
number
of
changes
we
make
to
the
monolith.
So
we
use
it's.
It's
a
it's
a
company-wide
kpis,
the
number
of
merge
requests
per
like
vertical
that
we
have
a
group
even
and
then
section.
Would
we
aggregate
this
into
some
kind
of
headline
figure
and
yeah?
So
so
it
is
comparable
to
that
commit
figure
you
mentioned
earlier,
so
I'm
curious
now.
E
C
C
E
C
You
can't
have
an
active
record
relationship
between
two
components,
for
example
at
all
you
just
can't
and
and
a
few
other
really
hard
and
specific
rules
like
if
you,
if
you
do
want
to
expose
functionality
on
one
component
to
reuse
on
another
component.
You
have
to
do
it
in
exactly
this
way
right,
and
I
mean
the
advantage
of
that
was
that
we
could
automatically
generate
documentation
from
it.
But
it
turned
out
that
the
pattern
wasn't
a
good
fit
for
all
cases
and
some
people
really
violently
disagreed
with
it
and
like,
for
example.
C
C
I
think,
overall,
the
the
the
from
what
I
heard
people
thought
that
it
was
helpful,
but
there
were
certainly
like
especially
people
with
less
context
and
like
if
you,
if
you
have
people
that
have
never
done
dependency
inversion,
for
example,
and
they
they
they,
they
parkvac
tells
them
that
they
can't
have
a
dependency
between
two
things.
They
might
at
first
not
know
how
to
work
around
it,
so
there's
yeah.
C
This
is
also
something
that
we
discovered
that
if
you
want
to
make
this
kind
of
change,
you
kind
of
need
a
broad
foundation
of
software
engineering,
knowledge
and
yeah.
Surprisingly,
we
we
didn't
always
have
that,
like
we,
we
hired
people
that
were
maybe
good
at
at
writing
a
certain
kinds
of
code,
but
not,
then
necessarily
not.
E
E
E
So
I
definitely
found
that
because
ruby
is
such
a
malleable
language,
dependency
inversion,
especially
things
like
the
independency
injection
frameworks
or
like
techniques
that
you
use
to
implement
the
dependent
version
they're,
not
as
widespread
in
ruby,
but
there's
also
a
reason
which
is
outside
of
these
architectural
discussions,
like
one
big
advantage,
is
to
make
a
component
more
testable
right,
but
in
ruby
there's
a
lot
of
like
kind
of
workarounds
in
the
language
itself
right.
It's
super
easy
to
like
stop
out
the
constructor.
E
For
instance
right
you
can't
like
in
java
you
have
to
like
rewrite
bytecode.
You
know
at
runtime
to
do
that.
It's
like
super
hard,
so
so
it
makes
a
lot
of
sense
to
implement
against
interfaces
and
aesthetically
type
language,
but
in
ruby
that
is
less
of
a
problem.
So
I
think
people
just
you,
know
they're
happy
to
stuff
out
everything
in
the
test
and
then
say:
okay,
I'm
done
yeah.
So
so
yeah,
that's
super
interesting
yeah.
C
It's
it's!
It's
a
yes!
This
is
a
good
point
because
of
course,
there's
there's
a
there's
kind
of
a
cultural
mismatch
to
doing
something
like
this
in
the
ruby
world,
and
I
just
recently
read,
I
think,
an
old
blog
post
by
dhh
about
how
dependency
injection
is
something
that
you
just
don't
do
in
ruby,
because
you
can't
stop
everything
and
it's
much
better
to
do
that.
But
I
like,
I
think,
a
lot
of
people
still
treat
ruby
as
as
like
a
scripting
language.
Essentially.
D
C
You
want
like
you,
you
want
to
be
like
if
you,
if
you
write
small
pieces
of
software,
I
don't
I
I
do
think
you
want
to
be
able
to
take
as
many
shortcuts
as
possible,
but
at
some
point
it's
just
better
to
be
explicit,
and
of
course
this
is.
This
is
a
trade-off
and
what
so,
what
we
tried
to
do.
For
example,
we
looked
at.
B
C
Okay,
so
I'll
try
to
answer
both
questions
positive
and
negative.
I
think
positive.
I
partially
already
answered
the
like.
I
think
that
the
main
benefits
are
the
the
the
top
level
structure
of
the
code
base
and
the
fact
that
the
organization
has
learned
has
gotten
better
at
doing
this
kind
of
stuff.
There
was
also
concrete
examples
where,
for
example,
we
we,
we
rebuilt
large
parts
of
the
checkout
like
more
or
less
the
like
one
of.
E
C
Two
most
important
parts
of
the
shopify
system.
I
guess
online
store
and
check
out
and
we
had
lots
of
functionality
around
the
code
base,
that
kind
of
plugged
into
checkout
and
that
we
then
needed
to
reuse
in
the
new
implementation,
and
I
like
we,
I
got
a
lot
of
comments
from
people
saying.
Oh,
this
was
a
lot
easier
to
reuse
than
what
I
expected,
because
it
was.
It
wasn't
just
some
method
somewhere
in
the
negative
record
model,
but
it
was
actually
exposed
as
reusable
functionality.
C
So
so
one
one
example
was
like
people
working
on
checkout
at
some
point
were
thinking
okay.
So
how
do
we
get
tax
tax
calculation
into
the
into
the
checkout?
Now
they
looked
at
the
code
base,
there
was
actually
a
component
called
taxes,
and
then
there
was.
It
was
clear
where
to
find
the
public
interface
of
that
component,
and-
and
so
it
had
a
few
well
well
documented
entry
points
that
were
like
calculate
the
taxes.
C
B
C
So
then,
you
also
asked
about
inside
yeah
the
negative
side.
Yes
well,
okay,
so
so
one
thing
we
already
mentioned
that
then
at
times,
yes,
the
productivity
did
go
down.
Of
course
I
mean
there
was
a
lot
of
time
spent
on
this.
That
is,
that
is
a
cost.
That
is
easy
to
forget.
We,
we
did
have
a
centralized
team
on
it,
which
wasn't
ever
really
huge.
C
Well
at
some
point
for
a
few
months,
I
think
we
had
maybe
eight
people
working
on
it
or
so,
but
that
was
kind
of
an
exception.
There
was
one
team
that
didn't
have
anything
else
to
do
at
the
time
and
joined
the
effort,
but
other
than
that
it
was
mostly.
It
was
three
people
so
for
an
organization
of
shopify
size.
It
wasn't
wasn't
that
huge
of
an
investment
in
terms
of
dedicated
people.
C
This
this
was
something
that
always
bothered
me.
A
lot
was
how
hard
it
was
to
actually
iterate
on
the
monolith
like
if
we,
if
we
had
an
idea
to
roll
it
out
of
a
significant
part
of
the
monolith,
was
like
not
something
that
you
could
actually
do
to
try
it
out
because,
like
it
was
so
much
work
to
roll
it
out
that
that
was
implementing
it
like.
C
There
wasn't
really
a
way
to
prototype
ideas
very
well,
and
then,
if
we
found
out
that
something
didn't
work,
it
was
usually
when
it
was
already
rolled
out,
and
then
it
was
hard
to
revert
so
for
the
things
that
didn't
work.
We
certainly
or
shopify
certainly
still
has
code
around.
That
is
now
in
a
worse
state
than
it
was
before,
and
I
don't
think
it's
a
lot
but
yeah
that
that
kind
of
stuff
exists
for
sure
we
we
did.
C
C
We
were
like
reasonably
confident
of
the
these
rules
that
we
that
we,
that
we
thought
everybody
should
follow
and
and
then
we
will
we
build
a
wedge
to.
I
think
I
mentioned
that
in
the
blog
post,
as
I
mentioned
in
the
earlier
blog
post
as
as
a
tool.
Well,
it
was
all
or
like
originally,
it
was
like
an
introspection
tool
to
just
understand
the
code
base
better
and
the
way
the
application
works.
But
then,
at
that
point
we
turned
into
a
scoring
tool,
and
we
said
okay,
so
we
we
can.
C
C
Point
I
think
it
was
well
for
each
component.
There
was
a
supposed
to
be
one
person
over
a
course
of
a
few
months
to
try
to
increase
the
score
specifically,
so
we
we,
we
made
it
very
explicit
that
we
want
to
increase
the
score,
and
I
think
that
again
went
a
little
bit
too
far
in
in
in
one
direction
and
and
that's
where
a
lot
of
code
was
written.
There
was
sub-optimal
because
there
was
an
explicit
mandate
to
improve
the
score
right.
C
D
A
B
B
What
kind
of
process
did
you
what
you
call
increment?
Of
course,
did
you
end
up
settling
in
for
for
for
breaking
out
the
demand
on
it?
Did
you
start,
for
example,
to
set
some
some
invisible
boundaries
and
then
slowly
enforce
these
boundaries
between
components?
Or
did
you
start
to
make
everything
private
and
then,
and
you
know,
work
over
the
the
violations
from
backward?
For
example,
in
that
case,
you
were
using
backward.
C
C
The
last
thing
I've
heard
was
that
there
was
talk
about
removing
the
privacy
enforcement
from
puck
back,
which
is
also
an
idea
that
I
brought
up
a
few
times,
because
I
think
it's
it's
it's
a
little
misleading
like
it
is
the
the
easier
of
the
two
like.
If
you
look
at
privacy
and
dependencies,
if
you,
if
you
have
a
privacy
conflict,
you
can
just
say
so,
like
component
a
is
component
calling
component
b
to
do
something,
but
it's
reaching
in
the
implementation
details.
Okay.
So
how
do
we
resolve
this?
C
C
C
C
To
talk
about
what
is
the
current
approach,
it's
kind
of
in
an
amalgamation
of
of
previous
approaches
and
the
last
state
that
we
left
it
in
before
we
resolved
the
team.
So
the
last
thing
that
we
did
two
years
ago
was
to
really
double
down
on
the
on
the
dependency
stuff,
because
I
I
think
that
is
something
where
people
with
more
context.
Oh
yeah,
that's
also
an
interesting
problem.
Like
no
note,
everybody
has
the
same
amount
of
understanding
of
how
the
overall
system
works
right.
C
So
what
you
kind
of
you
want
is
you
want
to
enable
people
that
have
more
context,
communicate
their
contacts
and
people
that
have
less
context?
And
I
think
that
is
something
that
defining
dependencies
works
really
well
for
because
it
it
encodes
a
really
a
deeper
understanding
of
the
system.
But
we
and
it's.
C
So
this
is,
I
think,
like
like
my
current
opinion
is
that
it
makes
sense
to
have
that
kind
of
system.
I
don't
know
if
it
has
to
be
puck
back
or
maybe
something
similar
or
maybe
something
different,
but
that
that
allows
people
with
more
context
that
are
still
it's.
It's
it's
a
more
distributed
group
than
a
centralized
team.
They
have
more
context
on
the
like
certain
areas
of
the
of
the
monolith
too
to
to
define
parts
of
the
architecture.
So
that
would
be.
C
C
I
think
the
decision
needs
to
be
more
a
little
more
local,
not
per
pr
but
a
little
more
local.
So
you
can
have
these
strategic
people
that
are
interested
in
defining
and
have
the
context
for
defining
dependencies
between
components
and
then
those
that
definition.
That
is
it's
kind
of
an
architecture
definition.
B
C
We
did
that
too,
yes,
and
I
do
think
it
can
be
well.
I
kind
of
I
would
like
to
unify
both
approaches.
I
have
to
say,
like
have
gems
and
park
packages
unified,
because
they
are
very
similar
things,
but
they
have
slightly
different
capabilities,
and
so
we
started
extracting
the
gems
before
we
had
parkvark,
but
I
do
think
it
still
makes
sense,
because
gems
are
optimized
for
this
use
case
where
they
well.
C
C
C
A
completely
separate
test
suite
that
was
really
comp.
It
tested
the
code
in
complete
isolation,
which
is
something
that
we
never
achieved
with
components,
and
I
think
it's
way
harder
with
components
so
yeah.
I
think
we
used
it
to
a
a
very
good
effect
in
these
cases
where
things
were
conceptually
isolated
and
in
some
cases
what
we
did
was
we
used
pugback
to
isolate
the
code
within
the
monolith
to
see
like
like
take
a
chunk
of
code.
That
shouldn't
depend
on
the
monolith
and,
of
course
it
does
if
it's
old
enough.
C
B
Okay,
thank
you.
Okay,
we
are
almost.
We
have
almost
15
minutes
left,
so
I'm
kind
of
see
if
there
is
any
other
questions
more
important.
You
you
said
earlier,
I'm
gonna
bring
this
up
this
question,
so
you
said
earlier
that
in
shopify
I
had
30
to
40
components
and-
and
it's
like
way
more
than
what
you
expected
and
what
kind
of
you
know
guidelines
did
you
did
you
use
to
draw
lines
between
components?
C
So
if
you
were
to
d
like
the
code
basis,
is
the
ui
that
developers
use
to
change
the
code
base
right
and
if
you
think
about
designing
a
good
ui,
you
wouldn't
have
a
main
navigation
with
40
items.
You
just
won't-
and
this
is
the
comparison
that
I
made,
which
is
of
course
very
specific.
Is
that
the
shopify
admin
that
merchants
use
to
administer
a
store?
C
Has
I
don't
know
how
many
items,
but
it's
I
think
it's
less
than
10,
maybe
it's
10.,
and
why
is
that
with
a
large
company?
Why
does
it
like?
Why
doesn't
everybody
just
use
like
add
entries
to
that
and
for
a
long
time
I
don't
know
that
that's
still
the
case,
but
for
a
long
time
toby.
The
ceo
had
like
previous,
like
personally,
signed
off
all
additions
to
the
main
navigation,
which
I
think
makes
perfect
sense.
C
C
Sense
to
add
a
component
because
of
this
requirement
of
like
the
overall
set
of
components
should
still
make
up
for
a
good
introduction
to
the
code
base
and
the
larger
the
number
that
there
was
it
is
at
that
task.
So
then,
we
just
started
nesting
packages
within
components
which
also
made
a
lot
of
sense
because
most
of
the
newly
proposed
components
kind
of
overlapped
with
existing
ones.
C
D
D
If
it's
not
enforced,
you
know
some
way,
and
I
think
that
article
by
dhh
is
is
a
really
good
example
of
that
you
know
he
said
we,
we
don't
need
dependency,
injection
and
ruby,
because
we
can
mock
anything
and
but
the
concerns
that
a
macro
scale
or
greenfield
project
are
much
different
than
a
million
line
project,
and
what
I'm
getting
at
is
the
is
there
other
ways
that
might
be
easier
to
achieve
these
same
goals?
For
example,
the
d
in
solid
is
dependency
injection
and
rails
explicitly
by
dhh.
D
D
So
another
way
to
achieve
loose.
Coupling
and
high
cohesion
is
an
event
source
system
and
I
think
that's
another
area
where
people,
if
they
don't
have
experience
in
a
system,
that's
architected
that
way
they
can't
conceive
of
how
that
would
work-
and
I
know
you
may
not
have
experienced
in
this
yourself-
and
definitely
I
haven't-
maybe
used
that
much
at
shopify.
D
C
C
D
C
I
think
this
would
have
been
an
even
larger
culture
shift
to
to
to
go
to
event
sourcing,
and
so
it
would
have
been.
It
would
have
been
more
work
and
more
like
just
a
larger
distance
to
cover
on
the
cultural
level,
but
also
just
on
the
on
the
level
of
refactoring
code,
like
we
at
that
point
had
a
huge
application
that
was
built
on
on
the
assumption
that
that
we
just
have
mutable
roles
in
the
database
and
that's
and
that's
how
the
application
works.
C
Still,
I
still
think
this
might
have
been
a
good
idea,
because
it's
so
easy,
it's
so
easy
to
do
and
you
you
can
actually
like
in
terms
of
refactoring.
You
can
take
something
that
is
more
like
a
command
pattern
right
now,
one
component
telling
another
component
what
to
do
and
refactor
it
into
into
an
eventing
pattern
without
actually
changing
the
behavior
of
the
application
at
all,
which
is
not
possible.
If
you
do
asynchronous
eventing
right.
C
So
I
still
think
that
is
a
probably
useful
approach.
We
we
didn't
go
for
that,
mostly
because
there
was
a
sufficiently
large
number
of
people.
That
said,
this
doesn't
decouple
things
enough,
and
there
were
mostly
concerns
that,
if
you,
if
you
add
too
many
subscribers
in
in
a
synchronous,
pops
up
mechanism,
you
would
slow
down
the
publisher.
D
C
But
still
have
similar
expectations
around
reliability
of
the
mechanism
as
if
it
was
as
if
we
were
doing
synchronous,
communication
and
then
yeah.
That
also
has
the
advantage
of
opening
up
the
the
mechanism
to
reuse
across
applications,
which
is
increasingly
a
concern
at
shopify
I
mean
it's
a
company
of
many
monoliths
now.
C
Yeah
yeah,
so
I
do
think
I
do
think
eventing
and
publishing
subscribe
mechanisms
are
absolutely
super
useful
in
this
space
event.
Sourcing
might
be
a
good
technique.
I
don't
know
how
realistic
it
is
to
really
take
a
large
existing
code
base
and
kind
of
convert
it
to
event
sourcing
or
how
useful
it
is
to
partially
do
so.
C
D
C
Always
enjoy
this,
the
the
conversations
what
I
get
out
of
this
conversation,
mostly
is-
I
mean
just
I
just
enjoy
the
conversation
in
general,
but
also
just
hearing
like
hearing
hearing
how
other
people
think
about
it
is
very
interesting
to
me.
I
don't
at
this
point,
have
anything
to
advertise.
I
think,
but.