16. @RicTempesta - #mm19de
… inside the box:
… everything coupled with everything
Code production over code maintainability
17. @RicTempesta - #mm19de
Fragile architecture
Touching a single piece has unpredictable consequences
Hard to evolve and maintain
18. @RicTempesta - #mm19de
Why?
• No standards at that time
• Industry was asking for a fast software
development
• Most of the people did not think about
maintenance of the code being released
22. @RicTempesta - #mm19de
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.
Layered monolith… the drawback
23. @RicTempesta - #mm19de
Softwares became more complex
and modular, but we could not
scale each module independently.
Some modules could became
bottlenecks for scalability.
Magento 1 is a good example.
Layered monolith… the drawback
25. @RicTempesta - #mm19de
The final application is a
composition
of multiple «small» features.
Microservices approach:
26. @RicTempesta - #mm19de
We treat every single
component like an
independent application.
Microservices approach:
27. @RicTempesta - #mm19de
Each component can be
deployed separately.
Each component can be
scaled independently from
the whole application.
Microservices approach:
33. @RicTempesta - #mm19de
Today’s condition:
• Magento1 legacy
• Modules, but not modularity
• «God modules»
• Modules depending on other modules
implementation rather than abstraction
Typical of layered monolyths
34. @RicTempesta - #mm19de
Service isolation goals:
REPLACEABILITY:
Ability to replace a component with 3° party services
INDEPENDENT SCALABILITY and RELEASE:
Ability to scale and deploy each component separately
EVOLUTION:
Ability to evolve each component independently
37. @RicTempesta - #mm19de
Let’s divide Magento in Bounded Contexts
Catalog
Inventory
CustomerCheckout …
We consider each Bonded Context as isolated
and potentially replaceable
Another
Inventory
39. @RicTempesta - #mm19de
The MSI example integrating «sales»
SalesInventory
Interacting with other bounded contexts:
We need to add/change something in the «Sales» bounded context
to make «Sales» correctly working with «Inventory»
40. @RicTempesta - #mm19de
The MSI example integrating «sales»
SalesInventory
In the old Magento 1 world:
They would have been depending on each other
We would have to modify «Sales» and «Inventory» accordingly their needs
Mutual dependency
41. @RicTempesta - #mm19de
The MSI example integrating «sales»
SalesInventory
We want to achieve service isolation
They should not have a mutual dependency
Mutual dependency
42. @RicTempesta - #mm19de
Decoupled dependency
Sales
Inventory
InventorySales
When an interaction is required outside
the bounded context, an additional module
should be created.
«Inventory» is now isolated from «Sales».
Plugin to «Sales»
to modifiy/add
what we need
43. To make all of this work, we need
SOLID principles as base
44. @RicTempesta - #mm19de
• Single responsibility
• Open for extensions, Closed for modification
• Liskov substitution
• Interface segregation
• Dependency inversion
SOLID principles
45. @RicTempesta - #mm19de
• Single responsibility
• Open for extensions, Closed for modification
• Liskov substitution
• Interface segregation
• Dependency inversion
SOLID principles
Clear since Magento 1
46. @RicTempesta - #mm19de
• Single responsibility
• Open for extensions, Closed for modification
• Liskov substitution
• Interface segregation
• Dependency inversion
SOLID principles
47. @RicTempesta - #mm19de
• Single responsibility
• Open for extensions, Closed for modification
• Liskov substitution
• Interface segregation
• Dependency inversion
SOLID principles
48. @RicTempesta - #mm19de
Single responsibility classes
The rule is:
You should be able to
understand the specific
responsibility and
behavior of a class by
simply reading its
name.
Split responsibilities into multiple classes
49. @RicTempesta - #mm19de
Single responsibility
<?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;
}
…
}
A class has a single «atomic» responsibility and must be easy to replace.
This is why Magento «Helpers» should not be used anymore.
50. @RicTempesta - #mm19de
Single responsibility corollary
Composition over extension:
Class A extends B
Class B extends C
Class A
Class B
Class C
DI
51. @RicTempesta - #mm19de
Interface segregation
Break into multiple interfaces and let a single class extends multiple interface.
a.k.a: “The single responsibility principles for interfaces”.
Interface A
Interface B
MyClass implements A, B
52. @RicTempesta - #mm19de
Dependency inversion
Depend on abstractions and not on concretions
MyClass
Interface
Concrete class
Depends on
57. @RicTempesta - #mm19de
Bring abstraction at module level
AnotherModule
MyModuleApi
By creating a module API, we define its abstraction.
Other modules should be depending on abstractions only.
MyModule
Easy to replace with 3°
party implementations
65. @RicTempesta - #mm19de
Why is so amazing:
• 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
69. @RicTempesta - #mm19de
Inventory DB
Inventory context Catalog context
Source item Product entity
SKU SKU
Catalog DB
Use of business keys
No DB dependency
70. CQRS and Eventual Consistency
in modules isolation
The «salability» example
73. @RicTempesta - #mm19de
Mind the CAP theorem
Our system must be
available and
distributed.
So, we need to be
eventually consistent.
74. @RicTempesta - #mm19de
What you read is not what you write
Write representation A Read representation B
projection
Each context may have a different representation of the required information.
They can be also logically isolated other than technically isolated.
Potentially separated databases
75. @RicTempesta - #mm19de
What you read is not what you write
Write representation A Read representation B
projection
Projection takes time, so you can read an outdated information
that is going to be evtually consistent
76. @RicTempesta - #mm19de
The reservation mechanism
SKU Qty Reservation Operation
ABC 10 0 Initial status
ABC 10 2 Order placed
ABC 8 -2 Order shipped
… … … …
Because nothing is immediate in the real life
Stock quantity: SUM($sourcesQuantity)
Salable quantity: SUM($sourcesQuantity) – SUM($reservations)
80. @RicTempesta - #mm19de
To be involved in the Magento evolution:
Join the Application design channel in the Magento Community Engineering Slack Channel
magentocommeng.slack.com
#appdesign
