Max Yekaterynenko - Magento Architecture, Next Steps
0 likes425 views
Magento 2 brought new architecture solutions, which are completely different from Magento 1, more advanced and sometimes complex. The session had covered most important changes in Magento 2 core and share practices all Magento developers must follow.
Ad
More Related Content
What's hot (20)
Viewers also liked (20)
Ad
Similar to Max Yekaterynenko - Magento Architecture, Next Steps (20)
Ad
More from Meet Magento Italy (20)
Recently uploaded (20)
Max Yekaterynenko - Magento Architecture, Next Steps
- 3. Goals for Magento Platform • Improve platform performance • Reduce complexity • Increase code consistency • Reduce extension conflicts
- 4. Magento MVC & CQRS
- 5. Model-View-Controller https://framework.zend.co m MVC came from client applications
- 6. Fat client - MVC • Presentation is separate from Model • State modification is separate from retrieval
- 7. Command & Query Responsibility Segregation (CQRS)
- 8. Incorrect Server MVC • Separation of Presentation from Model is preserved • Violates HTTP (CQRS) • State modification is done by same infrastructure as state retrieval (violates CQRS)
- 9. Improved but still Incorrect Server MVC • Separation of Presentation from Model is preserved • Obeys HTTP • State modification is done by same infrastructure as state retrieval
- 10. Correct Server MVC • Separation of Presentation from Model is preserved • Obeys HTTP • State modification and retrieval is partly done by different infrastructures
- 11. Correct MVC with CQRS • Separation of Presentation from Model is preserved • Obeys HTTP • State modification and retrieval is done by different infrastructures
- 12. CQRS • Separate Query API & Command API • Command API – optimized for write, have business logic • Query API – optimized for read, cacheable • Query actualization through indexing
- 13. Persistence
- 14. Persistence class AbstractModel { /** * @deprecated */ public function save() // … /** * @deprecated */ public function delete() // … }
- 15. Persistence Persistence of entities should be separate from entities (element of DDD) $this->productResourceModel->save($product);
- 16. Service Interfaces class ProductRepository implements ProductRepositoryInterfac { public function createProduct (ProductInterface $product) { // logic } }
- 17. Data Interfaces interface ProductInterface { public function getSku(); public function setSku(); public function getName(); public function setName(); // only getters & setters }
- 18. Service Contract Service Contracts expose procedural API
- 19. Persistence • OOP does not work well with Microservices • No logic on models • Persistence – just mapping data transfer objects to DB
- 21. Request Flow Customer-agnostic content (all routes) Customer Data API (/sections/…)
- 22. Customer Data • No session usage in blocks • Only Sections Controller knows about session
- 25. Inheritance Problems • Misused in 99% of cases • Child depends on parent __construct() • Static coupling – can’t substitute/decorate parent • Performance problem: all parent dependencies are inherited • Product Model
- 26. Inheritance Based on APIs • Model -> DTOs • Resource Model -> Data Mapping • Collection -> Query API • Block -> Interface subtyping • Controller -> Interface subtyping • …
- 28. Classes vs Namespaces class IndexController { public function firstAction() { //… } public function secondAction() { //… } }
- 29. Classes vs Namespaces class IndexController { public function __construct($dependencyA, $dependencyB) //… public function firstAction() { $this->dependencyA->doSmth(); } public function secondAction() { $this->dependencyB->doSmth(); } }
- 30. Classes vs Namespaces • class First implements MagentoFrameworkAppActionInterface { public function __construct($dependencyA) //… public function execute() { $this->dependencyA->doSmth(); } }
- 32. Focus • Continue applying CQRS on framework level • Continue Micro-service-ready approach • Continue Moving session management to browser • Discourage Inheritance and abandon Inheritance-based APIs • Stop using classes as namespaces • Separate configuration from code
- 34. Team
- 35. Goals • Enable Community • Ease contribution • Transparency
- 36. Issues Upvote - Thumb Up GitHub Issues
- 37. Upvote - Thumb Up GitHub Issues
- 40. Thank you ! Q&A Max Yekaterynenko @maksek_ua [email protected]