Riccardo Tempesta. MageSpecialist

Transcription

1

2 Riccardo Tempesta MageSpecialist Magento Community Maintainer Magento Community Contributor Magento 1 Certified Developer Magento 2 Professional Developer

3 Beyond Software Development: Challenges and Architectures of MSI Project

4 What is MSI Project Multi Source Inventory

5 Multi Source Inventory - Introduction Enables to handle multiple stock sources in Magento

6 The first time I heard about this My first reaction: It is simple! Products Quantities Warehouses

7 Multi Source Inventory - Introduction

8 Multi Source Inventory - Introduction

9 Nothing takes 5 minutes One does not simply develop a Multi Source Inventory

10 Challenge: Effective model Understand the merchant requirements and apply them

11 Domain Driven Design Can the DDD help us?

12 Domain Driven Design Domain: A sphere of knowledge (the inventory in Magento) Model: A system of abstractions (how the inventory works in Magento) Context: A context in which a term has a specific meaning (what does «source» mean in the «catalog context») Ubiquitous Language: A common language the merchant can understand

13 Why do we need a common language? Programmer: n. [proh-gram-er] Someone who solves a problem you didn t know you had in a way you don t understand.

14 Build the reality in the virtual world Making it work is not enough. We should model the software on the reality and speak the same language as the merchant. Our software should be as much as possible the map of the real life territory.

15 New entities taken from real life to deal with New entities: Source: The «physical» products location (e.g.: Barcelona Storage) Stock: An aggregation of qty coming from different sources How they are connected: One product can be stored in one or more sources One source can be aggregate in one or more stocks One stock can be connected to one or more websites

16 Multi Source Inventory - Introduction

17 Multi Source Inventory - Introduction

18 Single source mode We must not affect usability for those merchants using one single source.

19 We should support the same experience as before

20 The default source The quantity will be stored in a «default source». Default source Other sources I may add tomorrow

21 The default source The quantity will be stored in a «default source». Default source «$isdefault» attribute? Other sources I may add tomorrow

22 Single source mode No, because: In the Inventory Domain there is not a «default source» business concept. But We need this because catalog should place the products somewhere.

23 Challenge: Bounded Contexts Where should I implement this?

24 DDD Inventory Bounded Context Catalog Bounded Context Requirement from catalog

25 DDD Inventory Bounded Context Catalog Bounded Context It should be defined here Requirement from catalog

26 Architecture: Modularity Define responsibilities

27 The default source problem Solution: Create a new «InventoryCatalog» module. It will handle the Inventory requirements that are in the Catalog bounded context.

28 The default source problem <?php namespace Magento\InventoryCatalog\Model; /** * Service returns Default Source Id «InventoryCatalog» module */ class DefaultSourceProvider implements DefaultSourceProviderInterface { /** */ public function getcode(): string { return 'default'; } }

29 The default source problem Old approach: Catalog Tight dependency Inventory

30 The default source problem DDD MSI approach: Inventory Catalog InventoryCatalog

31 Architecture: Headless first Define API calls before defining your code

32 Modules contract and upgrade resilience Separated API / SAPI modules: «Headless first» approach Inventory InventoryApi External module/app InventoryCatalog InventoryCatalogApi

33 API modules

34 User Interface Can the merchants and the users be considered as interface consumers? Yes, via user interface

35 Interface first Separated fronted / backend implementation InventoryAdminUi Admin user Inventory InventoryApi Frontend user InventoryFrontendUi

36 Interface first Each module should expose all its public functionalities via API only.

37 Other contexts should depend on API modules only { } "name": "magento/module-inventory-sales", "require": { "php": "~7.1.3 ~7.2.0", "magento/framework": "*", "magento/module-catalog-inventory": "*", "magento/module-catalog": "*", "magento/module-inventory-api": "*", "magento/module-inventory-catalog-api": "*", "magento/module-inventory-configuration-api": "*", "magento/module-inventory-reservations-api": "*", "magento/module-inventory-sales-api": "*", "magento/module-inventory-source-deduction-api": "*", "magento/module-sales-inventory": "*", "magento/module-store": "*", "magento/module-sales": "*" }, API modules when possible!

38 Tons of modules

39 Tons of modules

40 Tons of modules You can easily find the piece of code responsible for one operation. You can easily replace a «piece of engine».

41 Modules Armageddon Anton Krill s architecture vision of Magento2 Director of architecture at Magento

42 Adding one dependency A new dependency may result in a new module creation. We should avoid as much as possible new dependencies.

43 Every time you add a dependency, Anton cries This was his face when I removed one dependency

44 Challenge: The database What about the foreign keys dependency

45 Decoupling database Traditional database relation product entity Foreign key by numeric ID source item

46 Is a numeric ID correct? Does a numeric ID have any meaning in the merchant s domain?

47 Is a numeric ID correct? product id:1 product id:2 product id:42

48 Is a numeric ID correct? product id:1 product id:2 product id:42

49 Decoupling database Module A context Module B context product entity source item One module should not be depending on another module database implementation.

50 Simple solution Use «business keys» Also known as: «natural keys» Keys existing in the real world with a meaning in the domain

51 Use real world keys becomes product id:1 product SKU: «ABC»

52 Decoupling database Context A Context B product entity source item sku: ABC sku: DEF No database dependency sku: ABC sku: DEF

53 Decoupling database: Application level consistency <?php class SourceItemsDeleteInterfacePlugin { /** * Keep database consistency while a source item is removed * SourceItemsDeleteInterface $subject void $result array $sourceitems */ public function afterexecute( SourceItemsDeleteInterface $subject, $result, array $sourceitems ) { foreach ($sourceitems as $sourceitem) { SourceItemInterface $sourceitem */ $this->delete->execute($sourceitem->getsourcecode(), $sourceitem->getsku()); } } }

54 Inconsistency by design Write DB inconsistency proof code

55 Soft inconsistency Context A Context B product entity source item sku: ABC missing entry You should handle this scenario sku: ABC sku: DEF

56 Challenge: Reserving quantity Operations take time

57 Reservation: real life has not transactions 10 products

58 Reservation: real life has not transactions 10 products 2 product ordered Quantity is still 10 in the real life.

59 Reservation: real life has not transactions 8 products 2 product ordered 2 product shipped The quantity should be decreased now

60 Reservation: real life has not transactions 8 products 2 product ordered 2 product shipped This procedure may take time and meanwhile: we should not allow people to overbook we should not decrease the quantity

61 Strategy: Event sourcing + some CQRS Tracking the history

62 Reservation: event sourcing initial availability decrease availability: -2 deduct real quantity and compensate reservation

63 Reservation: event sourcing SKU Qty Reservation Operation ABC 10 0 Initial status Quantity: 10 Availability: 10

64 Reservation: event sourcing SKU Qty Reservation Operation ABC 10 0 Initial status ABC 10 2 Order placed Quantity: 10 Availability: 10 2 = 8

65 Reservation: event sourcing SKU Qty Reservation Operation ABC 10 0 Initial status ABC 10 2 Order placed ABC 8-2 Order shipped Quantity: 8 Availability: 8 (2 (-2)) = 8

66 Reservation: event sourcing SKU Qty Reservation Operation ABC 10 0 Initial status ABC 10 2 Order placed ABC 8-2 Order shipped Quantity: $qty Availability: $qty SUM($reservations)

67 Reservation: a simple CQRS architecture Write Quantity Read Availability projection Command Query

68 Architecture: The CQRS benefits Different representations

69 CQRS: Different representations You write here with one representation You read here with another representation Source items quantity projection Availability Reservations

70 CQRS: And different databases if needed Database 1 Database 3 Source items quantity Database 2 projection Availability Reservations

71 You saw just few examples

72 Only two people can simply develop MSI: Igor Miniailo Magento Architect

73 Only two people can simply develop MSI: Igor Miniailo Magento Architect Chuck Norris

74 And we didn t see Amazing architectures

75 Other interesting things on MSI Eventual consistency Asynchronous API Bulk API Single responsibility classes Validation chains Conditional chains Multidimensional indexing Configuration proxies

76 Other interesting things on MSI Eventual consistency Asynchronous API Bulk API Single responsibility classes Validation chains Conditional chains Multidimensional indexing Configuration proxies

77 Contributing MSI Growing with Magento

78 You can work together with the Magento architects Max Yekaterinenko Anton Krill Igor Miniailo And others

79 Weekly online meetings Youtube records

80 Contributing: Just step in

81 Thank you for your time Riccardo Tempesta (aka The Rick) GitHub: I always have time for you, I have no social life!

82