►
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
A
Okay,
yeah
I
hand
it
over
to
fabio
with
the
first
question,
I
guess.
B
Okay,
thanks
philip
for
for
joining,
and
it's
an
honor
to
have
you
here
in
the
call.
So
the
first
question
I
have
is:
what
are:
what
were
the
growing
pains
that
you
know
shopify
experienced
when,
when
you
decide
to
invest
into
componentization.
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
What
was
difficult,
of
course,
was
that
none
of
those
were
really
easily
measurable,
except
the
ci
stuff.
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
While
we
were
hiring
more
developers
like
we
were.
At
that
point,
I
think
I
can
probably
say
that
I
think
doubling
the
number
of
developers
every
year,
but
the
the
number
of
commits
on
the
codebase
was
plateauing.
B
Graph,
we
can
probably
have
a
look
as
well
like
what
that
would
look
like
so
the
next
question
to
overturn.
I
guess
I'm
sorry,
philip.
Do
you
want
to
add
well.
C
B
C
It's
it's
nice
to
be
able
to
show
some
kind
of
graph
and
numbers
to
to
show
that
this
these,
otherwise
just
maybe
subjective
things
are
actually
happening.
C
A
Okay,
I
I
think
the
next
two
questions
are
actually
related
because
I
have
like
I
was
not
directly
involved,
so
full
disclosure-
I
know
philly
from
shopify
and
therefore
I
was
kind
of
like
part
of
of
the
compensation
efforts,
because
I
had
to
contribute
to
it
and
I
have
seen
that
there
was
a
lot
of
organizational
pain
or
organizational
challenges
to
get
componentization
like
really
rolled
out
or
towards
that
ideal
state
that
everybody
was
dreaming
about,
and
so
after
a
couple
of
years-
and
you
have
done
this
for
a
couple
of
years-
I'm
kind
of
curious
like
do
you
think
it
was
worth
the
effort
and
to
to
go
to
start
with
componentization
and
and
why
was
it
worth
the
effort.
C
A
C
C
Now
I
think,
is,
is
a
raised
awareness
of
the
problem
and
possible
avenues
towards
a
solution
and
just
the
the
top
level
folder
structure
that
that
clearly
communicates
that
we
don't
want
this
to
be
just
the
one
blob
and
everything
else
is,
is-
is
very
unevenly
distributed
through
the
monolith,
so
that
the
problem
is
that
I
think
many
of
the
really
cool
technical
benefits
like
being
able
to
make
the
test
suite
a
lot
faster,
come
from
rolling
out
things
over
the
whole
code
base
and
we
haven't,
we
haven't
made
a
lot
of
progress
on
that.
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
We
never
got
to
that
either
and
other
things
that
we
were
aiming
for
was
to
just
have
separate
deployments
of
the
monolith
that
are
only
responsible
for
parts
of
the
api
which
we
also
didn't
get
to
so
there's
there's
lots
of
there's
lots
of,
and
we
can
maybe
talk
a
little
bit
about
why
we
didn't
get
to
that.
C
But
there's
lots
of
things
there
that
kind
of
were
always
dangling
in
the
distance
as
promising
the
the
promised
land
so
to
say,
but
it
turned
out
really
hard
to
achieve
because
yeah,
because
making
progress
in
the
part
of
the
code
base
wouldn't
really
get
us
a
lot
closer
to
them.
C
C
A
C
Makes
sense
yes
and-
and
I
I
think
like
that,
I
changed
my
opinion
on
the
the
best
approach
a
few
times
during
the
project,
and
I
mean
I
think,
the
the
blog
post,
I
think,
does
a
pretty
good
job
at
lining
that
out,
but.
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
Then
I
think
that's
fine,
but
I
I
think
we
can
skip
my
next
one
and
actually
like.
I
asked
fabio
to
ask
his
because
I
think
that
sounds.
That's
the
that's
very
related
to
what
you
were
just
saying.
B
Do
you
mean
about
the
still
related
to
the
challenges
or
just
jump
to
the
next
one?
I
think
we
kind
of
cover
that
as
well.
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
That
is
a
very
good
question.
We,
I
don't
think
we
had
up-to-date
numbers
on
that,
but
it
definitely
like
it.
It
didn't
continue
to
plateau.
So
at
some
point
it
started
going
up
again,
but
I
I
don't
know
like
how
well
did
it
scale
with
the
number
of
developers.
I
had
no
idea
about
that.
C
Yeah
yeah
go
ahead.
I
I
I
kind
of
didn't
want
to
use
that
metric
too
much,
because
I
didn't
want
people
to
optimize
for
it
right
I
mean
if
you.
E
Not
a
situation,
it's
very
easy
to
exactly
it's
very
easy
to
yeah,
I
kind
of
exploit
that
metric
yeah-
I
I
don't
know
and
because
I'm
also
thinking
there's
also
the
whole
flip
side
of
it,
which
is
that
I
mean
forgetting
about
commits
or
merge
requests
for
a
moment
like
if
there
is
some
extra
tooling
that
you
you
mentioned,
there
was
some.
E
I
don't
know
if
it
was
a
workflow
or
whether
it
was
enforced
through
tooling,
because
I
believe,
because
you
developed
a
puck
back
as
well
right,
so
I'm
just
wondering
did
that
have
any
impact
on
productivity,
because
as
soon
as
you
like
establish
these
boundaries
and
enforce
rules
of
course,
of
course
this
will
affect
my
workflow
as
a
developer
right.
E
So
I'm
just
wondering
if
there
was
like
a
time
as
well
where
productivity
might
have
actually
dipped,
because
people
suddenly
are
facing
all
of
these
extra
rules
that
you
know
some
people
might
even
try
to
work
around
them.
You
know
I
don't
know,
what's
going
to
happen,
so
I'm
interested
in
that.
C
Yeah
for
sure
that
that
well
I
mean
I
don't
have
numbers,
I
I
think
personally
and
I'm
I'm
ready
to
be
convinced
otherwise,
but
I'm
currently
think
the
best
metric
for
developer
productivity
is
developer
happiness,
which
is
also
very
hard
to
measure.
C
But
at
least
you
can
ask
people,
but
people
will
generally
know
if
they
are
productive
or
not,
and
if
we
go
by
that,
then
yes,
there
was
definitely
a
phase
where
people
were
less
productive
and
it
was
the
phase
where
we
we
came
out
with
really
specific
rules,
and
we
we
had
this
rule
that
there's
no.
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
The
first
pattern
was
that
we,
you
could
only
return
data
like
pure
data
from
from
calls
across
components,
and
then
there
was
a
fraction
of
people
that
wanted
to
be
able
to
use
to
return
objects
with
behavior,
which
kind
of
makes
sense,
if
you're,
using
an
object-oriented
language,
and
that
that
that
led
to
lots
of
friction.
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.
C
Had
this
systemic
knowledge
of
techniques,
software
design,
techniques,
yeah,
and
I
think,
especially
in
there
in
the
rails
world,
it's
not
super
common
to,
at
least
like
maybe
you
know
about
these
techniques,
but
you
don't
have
a
lot
of
practice
for
them.
E
E
That
you
mentioned
this.
Thank
you
like
yeah.
This
is
super
interesting
because
that
was
actually
one
concern
I
had
because
I
I
I
come
more
from
a
java
background
than
I
would
say
than
from
a
ruby
background.
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.
C
What's
it
called
dry
container,
I
think
as
a
dependency
injection
framework,
but
we
decided
to
not
adopt
a
framework
for
it,
because
it
seems
that
it
moves
us
too
far
away
from
like
how
other
people
write,
rails,
applications.
A
B
Yeah,
I
think
we
kind
of
touched
a
little
bit,
but
I
was
I
was
interested
interested
in
knowing
like
what
it
was.
Maybe
the
highest
positive
impact.
You
know
from
what
kind
of
factor-
and
we
read
you
register
as
kind
of
a
highest
positive
impact,
and
where
do
you
see
some
negative
impacts
overall.
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
With
documentation
and
so
on
and
type
signatures,
so
so
that
that's
those
are
the
those
are
kinds
of
benefits
that
we
got.
B
It
was
not
because
of
the
was
that
because
of
the
boundaries
and
that
you
have
created
around
the
checkout
component,
yeah.
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
We
did
create
some
some
more
stuff
that
we
probably
would
love
to
get
rid
of
now,
and
I
think
that
is
mainly
from
from
an
from
a
thing
that
we
did.
When
was
that
2019?
Maybe.
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
We
can
tell
now
how
well
componentized
component
is
and
then
we
can
rank
them
and
we
can.
We
can
gamify
right,
but
then
you
have
this
one
metric
that
everybody
optimizes
for
and
at
that
point
we
actually
we
dedicate
like.
There
was
every
larger.
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
C
No
ill
will,
if
you
give
people
a
score
and
tell
them
to
optimize
for
it,
they
will
do
it.
A
We
are
like
about
halfway
into
the
hour
and
I
think
we
have
a
few
more
questions.
Should
we
move
on.
B
B
You
touch
a
little
bit
on
the
in
on
the
process
of
breaking
out
components,
and
you
said
luckily,
you
tried
to
identify
one
component
that
everybody
should
follow
in
terms
of
practices
and
in
another
case
you
decide
to
dictate
some
rules
for
all
components.
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
And
so
yeah
so
in
some
cases
very
isolated
cases,
that's
what
people
did
anyway,
because
at
that
point,
when
we
introduced
awkward,
we
didn't
have
like
this
strict
set
of
rules
anymore
on
how
to
use
it.
But
I
I
think
that
is
it's
generally.
C
How
do
I
explain
this
so
because
there
wasn't
a
centralized
team
anymore
now
for
the
last
two
years.
There's
also
not
like
there's
not
as
clear
consensus
on
the
current
approach
anymore,
which
I.
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
So
it
was
a
good
fit
for
things
that
are
really
very
isolated
things
that
that
are
essentially
libraries,
but
maybe
not
maybe
too
specific
to
warrant
moving
out
into
a
separate
repository
if
they
are
only
used
in
the
monolith,
then
moving
out
into
a
separate
repository
kind
of
just
increases,
friction
and
and
having
the
gems
in
the
same
repository
eliminated,
eliminated,
versioning
concerns
and
so
on.
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?
B
You
know
it's
like
based
on
specific
themes
or
features
of
the
and
then
maybe
these
components
where,
because
you
can
imagine
the
smaller,
they
are
the
more
interaction
and
dependencies
there
is
to
manage.
C
Yeah
I
mean
there's
a
whole
separate
discussion,
probably
about
how
components
relate
to
teams
and
there's.
C
Stuff
there,
but
in
terms
of
how
many
yes,
I
think,
I
think,
that's
a
there's,
a
that's,
a
very
good
observation
to
say
that
you
just
have
more
like
the
it's
like
the
the
total
length
of
your
boundaries
increases
when
you
the
the
more
components
you
have
and
so
the
more
com,
so
we
separated
actually
the
concepts
of
components,
packages
for
for
reasons
that
I
will
talk
about
next,
okay,
I'll
I'll,
do
it
in
the
other
way
around
for
components,
I
always
thought
of
them
as
the
the
kind
of
the
main
navigation
to
the
code
base.
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
It's
the
same
is
the
same
level
in
the
in
the
hierarchy,
so
to
say
right,
it's
the
is
the
top
most
level
of
the
how
the
the
structure
of
the
product,
so
the
topmost
person
to
be
involved,
makes
makes
a
lot
of
sense.
C
Of
course,
it's
that's
less
clear
if
you
have,
if
you're
talking
about
architecture-
and
you
don't
have
an
like
a
hierarchy
of
architects-
which
you
probably
don't
want,
so
so
we,
but
we
still
try
to
follow
the
idea
and
then
have
like
have
a
group
of
interested
people
discuss
for
each
new
proposed
component,
like
we
had
a
set
of
guidelines,
what
we
generally
think
a
component
should
look
like
and
what
warrants
a
component
and
what
doesn't
and
then
every
time
somebody
wants
to
add
one
have
a
discussion
about
and
in
many
cases
the
result
of
the
discussion
was
this
shouldn't
be
a
new
component,
so
this,
I
think,
worked
reasonably
well.
C
We
still
ended
up
with
more
than
I
would
have
liked.
But
for
that
reason,
when
we,
when
we
started
introducing
pukweg,
we
said
that
if
you
want
something
that
is,
if
you
want
kind
of
a
smaller
unit
of
encapsulation,
it
doesn't.
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
Sure
yeah
thanks
for
doing
this,
so
this
has
been
a
really
interesting
discussion.
I
really
like
that.
You
fall
back
on
coupling
cohesion
as
as
first
principles.
D
I
also
think
those
underlie
everything
that
is
good
and
software,
both
at
the
micro
and
at
the
macro
level
and
solid,
is
also
a
really
good
thing
to
look
towards
in
an
object-oriented
paradigm,
but
it
was
also
really
interesting
how
he
pointed
out
if
people
that
don't
have
experience
in
a
certain
pattern
have
trouble
grasping
that
and,
as
I
think
you've
said,
have
trouble
sticking
to
it.
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
Yeah
I
I
would
like
to
know
more
about
those
cases
but
like
maybe
maybe
it
works
really
well,
I
I
would
just
be
surprised
if
they
didn't
run
into
some
problems
and
like
some
of
the
problems
that
we
ran
into,
were
second
order
problem,
so
the
problem
is
not
actually
rails,
but
the
problem
is
that
we
have
deep
integration
with
with
some
gems,
third-party
gems
that
build
on
the
philosophy
of
rails
and
cause
additional
problems
for
like
if
you,
if
you
divert
from
the
philosophy
of
rails,
but
so
so
two,
the
two
other
things
that
I'm
more
confident
in
talking
about
are.
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
C
And
later
decided
to
well
yeah.
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.
C
And
that
is
not
in
itself
a
problem,
but
it
might
be
really
hard
to
to
to
debug
on
the
publisher's
side,
then
so,
there's
ongoing
work
now
looking
into
asynchronous
messaging,
with
with
the
transactional
outbox
pattern,
which.
D
C
Transactional
outbox
so
so
yeah
that
that
allows
us
to
to
do
asynchronous.
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.
A
Okay,
I
just
wanna
like
we
have
five
more
minutes
left,
and
I
also
want
to
give
philip
the
chance
to
advertise
any
side
projects
hustle
slack
channels
that
he
hangs
out
and
you
should
probably
join
if
you
want
to
discuss
puck
work
and
domain
driven
design
and
all
the
other
good
things,
but
we
also
have
a
few
more
questions
left.
A
So
I
want
to
ask
philip
if
he
has
a
few
more
minutes
or
not
and
yeah,
and
give
him
like
a
few
minutes
to
talk
about
things
he
wants
to
talk
about,
and
otherwise
we
have
a
few
more
questions.
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.
E
C
Is
a
there
is
a
slag
instance
where
some
people
talk
about
modular,
ruby,
apps
I've
invited
harness,
I
think
harness
you
should
be
able
to
invite
other
people
now,
I'm
not
quite
sure,
yeah.
A
I
think
I
invited
fabio
and
maybe
matthias
I'm
not
sure.
C
So
there
have
been
some
interesting
conversations
in
there
for
sure
and
other
than
that
I
mostly
want
to
like.
I
I
do
think
the
the
the
general
there's
there's
something
useful
about
what
pacquiao
is
trying
to
achieve,
so
I
would
definitely
advertise
for
trying
it
out
yeah
if
you
haven't,
but
yeah.
A
I
have
posted
the
the
slack
workspace
in
the
chat,
so
for
those
who
are
curious,
you,
I
think
you
should
be
able
to
join
or
reach
out
to
me
in
gitlab
slack,
and
I
will
do
my
best
to
to
add
you
to
spam
to
spam,
philips
slack
instance
and
I'm
not
sure,
if
you're
even
sure,
if
it's
yours,
but
I
it's
for
me
too,
baby
yeah.
C
A
Cool
yeah,
we
are
better.
We
are
at
the
end
thanks
very
much
philip
for
joining
us
today.
Also,
thanks
for
the
participants
of
the
of
the
zoom
meeting,
I'm
going
to
end
the
recording
yet
and
yeah
forever
for
everyone
who
wants
to
stay
like
two
or
three
more
minutes.