- The speaker discusses their experience contributing to the Magento Multi-Source Inventory (MSI) project, noting the learning opportunities and satisfaction of helping others. - They describe how the Command Query Responsibility Segregation (CQRS) and Event Sourcing patterns were applied to MSI to separate read and write operations, improving performance and flexibility. - The key lessons are that simplification through separation of concerns can be better than unification, and that software design is an important skill beyond just coding.

1. #MM18PL
@aleron75
The lessons I learned
contributing to
#MagentoMSI
The lessons I learned
contributing to
#MagentoMSI

2. #MM18PL#MM18PL
@aleron75
Nice to meet you!
Alessandro Ronchi
@aleron75
I believe in passion, innovation,
and continuous improvement.
#COO #Developer @Bitbull_it
#MagentoContributor
These are the key values that drive me during
my daily job as COO and Developer at
Bitbull and as Magento maintainer and
contributor.
If you like it, please follow me.
Me in brief:
- Magento since 2009
- M1 certified dev and M2 solution specialist
- Author of M1 book
- Magento Master 2017
- Magento Top 50 Contributor 2017
- Magento Maintainer since 2018

3. #MM18PL#MM18PL
@aleron75
Long story short
Hey, did you just edit the core?
Yes, we can
Thanks to the Magento Community
Engineering team, Magento truly embraced
the open source spirit becoming open to
contributions and becoming a real
Community-driven platform.
Nowadays, it’s a very well known story so I
want to focus mainly on what motivates me
to contribute to Magento.

4. #MM18PL#MM18PL
@aleron75
WHY?
Now the big question: why to contribute.
There are great learning opportunities we
get by joining such a project; we have the
privilege to work directly with Magento
engineers and other smart members of its
community.
And that would be enough to motivate us.
But a recent episode made me think about an
additional side effect that now motivates
me at least as well: gratitude.

5. #MM18PL#MM18PL
@aleron75
Some weeks ago, on Twitter...
Chris Snedaker
@df2002
@aleron75, @philwinkle happen to
be a couple amazing people who
have helped this situation... and
probably don’t realize it.
So thanks to you two as well
Some days ago, Chris wrote this message,
thanking Philip Jackson and me for
something we did that helped him a lot.
He was answering to a message of
appreciation by his boss about how he
handled a situation during a meeting with a
customer of theirs.
And he was right: I had no clue why he was
thanking me. I wasn’t even sure to know him
at all.

6. #MM18PL#MM18PL
@aleron75
Some days before, on Slack...
But then I realized that some days before, I
answered a question by this guy in the MSI
Slack Channel.
I just gave a simple advice and example
about how to implement something on MSI
and I didn’t realize that it was so important
for him until his tweet, that made my day.
So, learning is great, but being useful to
someone else is even greater. Someone
even says that it’s the secret of happiness.

7. #MM18PL
@aleron75
Learn & Give Back
So this is my first take away: contributing means
having great opportunities to learn and the
privilege to help others, other than
ourselves.

8. #MM18PL#MM18PL
@aleron75
#MagentoMSI
I expect that many of you have at least heard
about Multi-Source Inventory but let me
briefly introduce it.

9. #MM18PL#MM18PL
@aleron75
KICK OFF
Sep 2013
May 2017
MM-DE hackathon
MSI – Story & Roadmap
MSI was an internal Magento project whose
first requirement was documented on
September 2013 but its development was
never accomplished.
The Community-driven project was kickstarted
during the contribution day of MM-DE
organized by Firegento in Leipzig on May
2017.
I joined in July 2017.

10. #MM18PL#MM18PL
@aleron75
MSI – Story & Roadmap
KICK OFF
20 May 2017
MM-DE hackathon
MILESTONE I
MVP
Magento 2.3
Three milestones were defined.
The first milestone consists of the minimum
set of functionality (MVP) to let merchants
natively manage multiple stock locations.
It is packed into Magento 2.3, that will be
officially released… I guess very soon.

11. #MM18PL#MM18PL
@aleron75
MSI – Story & Roadmap
KICK OFF
20 May 2017
MM-DE hackathon
MILESTONE I
MVP
Magento 2.3
MILESTONE II
config & mass actions
Magento 2.3.x
The second milestone has already been
developed and contains improvements
related to configuration and mass
inventory actions.
It will be part of Magento 2.3.something, that
means, part of one of the more frequent
patch updates.

12. #MM18PL#MM18PL
@aleron75
MSI – Story & Roadmap
KICK OFF
20 May 2017
MM-DE hackathon
MILESTONE I
MVP
Magento 2.3
MILESTONE III
improvements
Magento 2.x
MILESTONE II
config & mass actions
Magento 2.3.x
The third milestone includes the rest of the
product backlog, that means, a set of
improvements part of which, I guess, will be
driven by user feedback.

13. #MM18PL#MM18PL
@aleron75
KICK OFF
20 May 2017
MM-DE hackathon
MILESTONE I
MVP
Magento 2.3
MILESTONE II
config & mass actions
Magento 2.3.x
MILESTONE III
improvements
Magento 2.x
MSI – Story & Roadmap
Very Important Note: MSI is and will remain a
freely available feature of Magento Open
Source.

14. #MM18PL#MM18PL
@aleron75
#Community
At date, more than 60 ppl and 16 agencies
contributed over time submitting ~700 PRs.
Big project: at date it represents more than
12% of the entire Magento codebase.
Considered a reference for:
- best development practices
- insight of future Magento architecture
- good documentation

15. #MM18PL#MM18PL
@aleron75
Not technical… yet
It’s time to be more technical.
About the lessons learned, I used to talk a lot
about Domain-Driven Design in my previous
presentations but it’s a very intense topic and I
don’t have much time.
Thus, I’ll talk about how we applied the concepts
from CQRS and Event Sourcing to MSI.

16. #MM18PL#MM18PL
@aleron75
Before starting, a necessary disclaimer.
Once we experience the benefits of new
patterns or technologies, we are tempted to
use them everywhere.
There can be some drawbacks or simply “no
additional benefits” with what we will see and
we should always take them into account
instead of applying them blindly.

17. #MM18PL#MM18PL
@aleron75
CQRS
First topic is the architectural pattern named
Command-Query Responsibility Segregation.

18. #MM18PL#MM18PL
@aleron75
The beginning: CQS
Bertrand Meyer
@Bertrand_Meyer
Queries return results,
but never change the state.
Commands change the state,
but never return values.
Let’s start from the beginning, that is, from CQS,
introduced by Betrand Meyer in the 1990s.
CQS stands for Command-Query Separation
and it’s an implementation pattern requiring
us to avoid assigning both read and write
responsibility to the same method of a class.

19. #MM18PL#MM18PL
@aleron75
A code snippet is worth a thousand words.
This is an example of code that doesn’t apply
the CQS pattern.
I’m pretty sure that every one of us tends to
avoid such kind of code but don’t give it
always for granted...

20. #MM18PL#MM18PL
@aleron75
This is real code taken from Magento 2 that
doesn’t apply CQS: this method returns a
value (so it’s a query) but it’s also a command
because changes the state of the system,
creating a directory if it doesn’t exist.

21. #MM18PL#MM18PL
@aleron75
Just let me give credits to the guy formerly
known as “Riccardo Tempesta”, nowadays
called The Rick, for pointing me to this
example.

22. #MM18PL#MM18PL
@aleron75
This, instead, is what Meyer means: you can
see in this class we have methods that return
data (queries) separated from methods that
write data (commands) and change the state.

23. #MM18PL#MM18PL
@aleron75
The evolution: CQRS
Greg Young
@gregyoung
Separate systems that represent
the state of the application from
those that change it.
So what’s CQRS? CQRS stands for Command-
Query Responsibility Segregation and despite
the similar name, the difference is remarkable:
it is an architectural pattern.
The responsibility is not only split at method
level but at the model level.
That’s why we talk about segregation.

24. #MM18PL#MM18PL
@aleron75
Again, small code examples are worth a
thousand words.
Here we have two separate classes, one for
reading and one for writing.
Note that the storages used by these two
models can be different even if they don’t
necessarily have to be.

25. #MM18PL#MM18PL
@aleron75
And this is a diagram of how we applied this
paradigm in MSI.
A source is typically a physical place where our
goods are stored, like a warehouse, a depot, a
brick & mortar store.
A source item is an entity through which we
write product availability, changing the state
of the system (typically a backend operation)

26. #MM18PL#MM18PL
@aleron75
A stock is the aggregation of different sources
that determines the total availability of a
product across different sources.
A stock item is an entity through which we read
product availability (typically a frontend
operation)

27. #MM18PL#MM18PL
@aleron75
Data consistency b/w backend and frontend is
delegated to an indexation process, called
projection in CQRS terminology.

28. #MM18PL#MM18PL
@aleron75
CQRS: benefits
Single responsibility
Domain simplification
Better resources assignment
CQRS gives us a better understanding of what
is responsible for changing the state of a
system.
This separation brings to domain simplification:
a single model is no more responsible for both
operations, thus they can be assigned to two
simpler models which are also simpler to
adapt to business changes.
Furthermore, since we separate the systems
that write and read, in situations where, for
example, read operations are more frequent
than write ones, we can better assign
resources and scale our application properly.

29. #MM18PL#MM18PL
@aleron75
CQRS: drawbacks
More analysis
Duplication handling
Eventual consistency
CQRS is not a universal solution.
Applying this pattern comes with some
drawbacks and we should always take them into
account when deciding whether to apply it or not
to our application:
- more analysis due to the additional
complication
- duplication handling
- eventual consistency (avoid in transactions)

30. #MM18PL
@aleron75
Simplify vs Unify
Here we come to the second takeaway I want to
leave you: even if duplication handling is listed
among the things to look-out, duplication also
brings simplification or, put differently, lets us
avoid the coupling given by unification.
CQRS and DDD advocate for simplification
over unification.

31. #MM18PL#MM18PL
@aleron75
Event Sourcing
Second topic is another architectural pattern
known as Event Sourcing.

32. #MM18PL#MM18PL
@aleron75
Event Sourcing
Martin Fowler
@martinfowler
Capture all changes to an
application state as a sequence of
events.
ES is an architectural pattern that can be very
useful in some circumstances as we will see.
According to Event Sourcing, we store the state
of a system by persisting a sequence of
events that brought us there.
This way not only we can determine the state of
the system at any time but we also have an
insight of how we got there.

33. #MM18PL#MM18PL
@aleron75
Check-out in Magento 2.2
I think the best way of understanding the
benefits of such an approach is seeing it
applied.
This is how Checkout works in Magento 2.2
(and 1.x as well).
Each time we place an order, the product
stocks are updated. That means, stock item
records related to the products we are
purchasing are locked with a SELECT… FOR
UPDATE statement.
That means: users purchasing at least one
same items must wait. And you know that the
worst moment to block users is checkout.

34. #MM18PL#MM18PL
@aleron75
Check-out in Magento 2.3
This is how checkout works in Magento 2.3
thanks to ES: each time we place an order,
some product reservations are appended and
that’s it.
No lock.
No wait.
No “conversion killer” code.

35. #MM18PL#MM18PL
@aleron75
An “only” choice
To be honest, this was the only choice we had.
Since determining from which source to ship
items could be a time-consuming activity, we
couldn’t do that during checkout.
We had to move it from placing the order to the
fulfilling phase.
When an order is placed, we only needed to
record the information of the qty to reserve,
without updating the inventory in real-time.

36. #MM18PL#MM18PL
@aleron75
Event store
product qty updated
in source: ­2
Product reservations are append-only events
that record the information about the product
qty that need to be incremented or
decremented, depending on the situation.
When product qty is updated in source, product
reservation is compensated.

37. #MM18PL#MM18PL
@aleron75
Data consistency
The salable quantity of a product is calculated
by taking reservations into account and
keeping product availability consistent and
protected from overselling.

38. #MM18PL#MM18PL
@aleron75
Event Sourcing: benefits
Immutability
Performance improvement
Valuable information
I think that at this point the benefits of applying a
pattern like ES are clear but let’s recap:
- thanks to their immutable nature, events are
append-only operations
- since those records are never updated, we
don’t have locks on them
- since we keep track of all the events related to
product quantity, a brand new set of inventory
information can be extracted for business
analysis

39. #MM18PL#MM18PL
@aleron75
Event Sourcing: drawbacks
Seriously?
Sincerely, I had to perform a search to list some
drawbacks of ES.

40. #MM18PL#MM18PL
@aleron75
Event Sourcing: drawbacks
Not well known
More analysis
More disk space
Well, despite it was introduced in 2005 it is still a
not very well known pattern.
As it happens for CQRS, it requires more
analysis.
And yes, it requires more disk space, deal with
it.

41. #MM18PL
@aleron75
Coding !== SW Design
And here is the third and last takeaway I want to
leave you.
As we have seen, some changes in the design
of our software can bring huge benefits.
Sooner or later, in our development career, we
must understand the difference between
writing code and designing software.
No matter if you are in your 20s or 40s, there is
always something new to learn, so never stop
improving.

42. #MM18PL
@aleron75
Thank you!Thank you!
Thank you, for the time you spent listening,
watching, or reading this presentation.
And big thanks also go to :
- The MCE team and all the folks contributing to
Magento 2 and MSI – tw + gh
- Lori Krell for the beautiful icons and for writing
the great MSI User Guide - tw
- Holger Wolterdorf’s presentation for CQRS
and ES inspiration - tw
If you have any questions, feel free to reach me
on Twitter or Slack.