Awesome Architectures in Magento 2.3 - MM19PL

AWESOME
ARCHITECTURES IN
MAGENTO 2.3
Riccardo Tempesta
CTO MAGESPECIALIST
MAGENTO MASTER 2019
MAGENTO COMMUNITY MAINTAINER
TOP 5 MAGENTO CONTRIBUTOR 2018
#MM19PL - @RicTempesta

Awesome Architectures in Magento 2.3 – 16 September 2019 – Riccardo Tempesta #MM19PL - @RicTempesta
DISCLAIMER 1:
The next slides contain a personal
interpretation that may differ from the
official Magento architects position.

DISCLAIMER 2:
My english is bad, but you don’t want to
try my polish!

Why this speech?

Becoming a Magento2 developer
is not stressful at all
-- Mark, 23 years old

«confusion» comes from latin:
«cum + fusus»
It means:
«Bonded with» or «Fused with»

Magento 1
Another framework
Do not try to approach Magento2 as you were approaching Magento1
or any other «classical» framework

Magento2 is a very complex
software with a very large codebase

Developing process
Developer Codebase Instructions CPU

Developing process
Machines do not have any problem interpreting and running more code

Developing process
Machines do not have any problem interpreting and running more codeWe start having problems understanding
and maintaining a considerable amount of
code

Increasing the code size:
95% of time: reading to understand
5% of time: write new code
We are the bottleneck

We need to optimize the
95% of time spent in reading
and understaning our code

How can we avoid it?
•Add structures
•Raise abstractions
•Reduce cognitive load
•…

What are the tools?
•Methods
•Classes
•Modules
•Applications
•…

What are the tools?
•Methods
•Classes
•Modules
•Applications
•…
Interactions and relations between these is what we call: Software Architecture

Evolution of architectures
from 1990’s to 2010’s

1990’s
Spaghetti coding (aka Copy & Paste)

1990’s
2000’s
Lasagna coding (aka Layered Monolith)

1990’s
2000’s
Lasagna coding (aka Layered Monolith)
2010’s
Ravioli coding (aka Microservices)

the «Spaghetti coding era»

User Interface A blackbox working
somehow

… inside the box:
Code production over code maintainability
… everything coupled with everything

No architecture at all
• Hard to maintain
• High cognitive load
• Bad scalabilitycost
timeEvolution limit

the «Lasagna coding era»

Every upper layer depends
on the underneath layers
Software is built in layers
The layered monolith

HTML
PHP
DATABASE

Controller
Model
ResourceModel
Like most of the existing frameworks, Magento1 is here.

The layered approach
Customer Catalog Quote
Controller
Model
Resource model

Controller
Model
Resource model
Every functional area is developed following a «horizontal» model

Controller
Model
Resource model
But we need interactions across different areas

The drawback
The application becomes a N-layered monolyth
requiring every single layer to be working.
Only bing releases because we were not able to to
deploy each layer separately.
Unable to scale layers separately.

the «Ravioli coding era»

Microservices
The final application is a
composition
of multiple «small»
features.

Microservices
Each component can be
deployed separately.
Each component can be
scaled independently from
the whole application.

Where is Magento2 now?

Spaghetti Lasagna Ravioli

Spaghetti Lasagna Ravioli
Magento 1
Magento 2.0
Magento 2.1
Magento 2.2

Whaaaaaat?!?!

Something changed in
Magento 2.3 after one of
the most advanced
community projects: MSI

Igor Miniailo
Magento 2 Architect,
Magento / Adobe
@iminyaylo
Eugene Shakhsuvarov
Software Development
Engineer, Magento / Adobe
@ishakhsuvarov
https://github.com/magento/inventory
The Magento Inventory Project (aka MSI)

The service isolation

Controller
Model
Resource model
The Layered monolith approach:
Software is developed «horizontally»

Controller
Model
Resource model
In the service isolation model we consider each functional
area as an independent module
Software is developed «vertically»

Controller
Model
Resource model
But we still have a problem with modules requiring
acces to other modules information

Controller
Model
Resource model
Customer API Catalog API Quote API
We should split each module in:
• API module
• Implementation module
Note: This is an example, Magento2 modules implemenetation may differ

Modules interact with other modules via API only
Customer API
Customer
Catalog API
Catalog
Quote API
Quote

«API first» approach

API / Interface
API first

API / Interface
API first
Concrete module

•Single responsibility
•Open for extensions, Closed for modification
•Liskov substitution
•Interface segregation
•Dependency inversion
A functional area should depend on the abstraction of another functional area
and not on concrete its implementation.
The «D» of SOLID brought at functional area level

Functional area dependency inversion
MyModule
AnotherModuleAPI
AnotherModule
Depends on
Dependson

MyModule
AnotherModuleAPI
AnotherModule
Depends on
Dependson
Another advantage:
Can be replaced with a 3rd party implementation
if needed

Cross contexts interactions

Inventory
In the old way:
They would have been depending on each other
We would have to modify «Sales» and «Inventory» accordingly their needs
Mutual dependency
Sales

Decoupled dependency
Inventory
SalesInventorySales
There is no more direct dependency
between «Sales» and «Inventory»

Decoupled dependency
Inventory
SalesInventorySales
There is no more direct dependency
between «Sales» and «Inventory»
Plugin to «Sales» to
modifiy/add what
we need

We need «smaller» classes

•Single responsibility
•Open for extensions, Closed for modification
•Liskov substitution
•Interface segregation
•Dependency inversion
A class has a single «atomic» responsibility and must be easy to replace.
This is why old Magento1 «Helpers» should not be used anymore.
The «S» of SOLID

Divide et impera!
The rule:
You should be able to
understand the specific
responsibility and
behavior of a class by
simply reading its name.
«If you have problems naming your class, then you probably need a refactor!»
-- The Rick

When the responsibility is an action
<?php
…
class GetProductIdsBySkus implements GetProductIdsBySkusInterface
{
…
public function execute(array $skus): array
{
$idsBySkus = $this->productResource->getProductsIdsBySkus($skus);
$notFoundedSkus = array_diff($skus, array_keys($idsBySkus));
…
return $idsBySkus;
}
…
}
You have a single public method class and its name should contain a verb.

The single responsibility corollary
Class A extends B
Class B extends C
Class B
Class C
DI
Class A
Composition over extension

The future…

Anton Kril’s architecture vision of Magento2
Director of architecture at Magento and Master of the Universe

The Modulegeddon!

OMG! So many modules…
More than 40 for Inventory only

First reaction…

Second reaction… (or near death experience)

Then you see the light!

You see all the advantages:
•Fully modular system
•Full service isolation
•Clear code writing
•Classes and responsibilities are easy to find
•Each module or class is easy to replace
•Easy to handle in a structured teamwork
•No more «god modules» made of hundreds of classes

Oh wait! We forgot something!

Database!

Controller
Model
Resource model
Customer API Catalog API Quote API
Database Isolation
In the «vertical» approach, tables could be on different databases!

The foreign key problem
Inventory area Catalog area
Source item
Product IDProduct ID
Foreign key
Product entity

The foreign key problem
Inventory area Catalog area
Product SKUProduct SKU
No DB dependency
And use of business keys
Source item Product entity

Mind the CAP theorem

The CAP theorem
•Consistency
•Availability
•Partitioning

The CAP theorem
•Consistency
•Availability
•Partitioning
You can have only 2

The CAP theorem
We need partitioning because our
functional areas are vertically splitted.
We need availability because we are
building an e-commerce solution.
So we cannot be immediately
consistent.

The eventual consistency

The CRUD approach (if we had consistency)
Write data Read same data
We have: immediate consistency

In a partitioned (or distributed) system
Write data
We have: eventual consistency
Read potentially oudated data

CQS: Command-Query Separation

CQS: Command
Example:
A hypothetical «save» (or «create») method, should not return the newly created object ID.
Use of business keys is recommended in this case
Modifies the DB (or application state) and does not return anything

CQS: Query
Does not modify the database (or application state)

CQRS: Command-Query
Responsibility Segregation

Different read/write logic
Write data (with a representation) Read data (with another representation)

The inventory example
Write quantity Read salable quantityWrite reservations

Good examples

Where to find good examples
• https://github.com/magento/inventory
• https://github.com/magento/security-package/pull/2
Inventory project (aka MSI) Notifier project

Magento is an open source Community
To be involved in the Magento evolution:
Join the Magento EngCom Slack Channel
magentocommeng.slack.com
#appdesign
magentocommeng.slack.com
#msi

Thank you!
Riccardo Tempesta (aka The Rick)
MageSpecialist
@RicTempesta
riccardo.tempesta@magespecialist.it
#MM19PL

Awesome Architectures in Magento 2.3 - MM19PL

Awesome Architectures in Magento 2.3 - MM19PL

Recommended

Recommended

More Related Content

Similar to Awesome Architectures in Magento 2.3 - MM19PL

Similar to Awesome Architectures in Magento 2.3 - MM19PL (20)

Recently uploaded

Recently uploaded (20)

Awesome Architectures in Magento 2.3 - MM19PL