Code Customization and Extension techniques for Magento 2

1. Applying Code
Customizations to
Magento 2

2. Who am I?
Igor Miniailo

3. Interactions with Magento2
Code

4. Extension
UI Model
UI
Model
Service
Contracts
Service
Contracts
Vendor

5. Customization
UI Model
Model
Service
Contracts
Vendor

6. Customization Points

7. Customization points
Admin Configuration
Low Level Linking
High-level configuration (DSLs)
events.xml
routes.xml
routes.xml webapi.xml
acl.xml
di.xml
Object B Object C Object A
Object B
config.xml

8. Store Configuration

9. Store Configuration
• In admin application: Stores->Configuration
• Values stored in Database
• Configured in system.xml
• Default values in config.xml

10. High Level Configuration

11. Routing
High-level Configuration
Event Manager
events.xml
routes.xml

12. Application subsystems
AreaApplication
EntryPoint
Cron App
Web App
WebAPI
Admin
FrontendMedia App

13. Low Level linking

14. 1. Composability
2. Modularity

15. Composability

16. Composability
Split your code to lots of small
chunks and then compose them to
build your application

17. Dependency Injection
Dependencies are not located within object but are provided to that object by environment
namespace MagentoFrameworkEvent;
class Manager implements ManagerInterface
{
public function __construct(
Invoker $invoker,
Config $eventConfig,
$prefix = ''
) {
$this->_invoker = $invoker;
$this->_eventConfig = $eventConfig;
$this->_prefix = $prefix;
}
// some other code
}

18. Unit Tests
class ManagerTest extends PHPUnit_Framework_TestCase
{
protected function setUp()
{
$this->_invoker = $this->getMock('MagentoFrameworkEventInvoker');
$this->_eventConfigMock = $this->getMock('MagentoFrameworkEventConfig');
$this->_eventManager = new MagentoFrameworkEventManager(
$this->_invoker,
$this->_eventConfigMock
);
}
}

19. SOLID
1. Single responsibility – Lots of small objects
2. Open Closed - Each object has multiple extension points
3. Liskov Substitution – Polymorphism for composability
4. Interface Segregation – Granularity
5. Dependency Inversion – Decoupling. In particular, any
caller of an interface depends only on the interface, even
if a separate module implements it.

20. Modularity

21. SOLId
Module B
Module A
Implementation
Module B
Module A Implementation
Interface
Module C
Implementation
Module AB
Module AC
Impl
Impl
Coupled
Decoupled

22. Modules Definition
Modules serve as named containers for domain
object classes that are highly cohesive with one
another.
The goal should be low coupling between the
classes that are in different Modules

23. Simple rules for Module design
• Ensuring that Modules are largely independent
of others has the same benefit as loosely
coupled classes. This will make it easier to
maintain and refactor code inside the module.
• Do strive for acyclic dependencies on Modules
where coupling is necessary. Just unidirection

24. Service Contracts
And Compatible Customizations

25. Extensions Compatibility Challenges
 Interfaces may be changed in a new version
 Extensions may depend on optional modules which is turned off
 Extensions may depend on undocumented behavior
How to ensure that two extensions will be compatible in a new
version?

26. Challenges for Developer
How to understand what functionality of the extension is stable and
what is not?
How to implement extension in the way that it will keep backward
compatibility but can evolve?

27. Stable APIs
 Backward Compatible:
 Classes or Interfaces are not removed
 Methods of the classes keeps signature between versions
 Interfaces neither changes existing methods nor add new ones
 Explicit Interfaces
 No generic data types as “mixed”, “object” or “array”

28. Few ways to make promises in Magento 2
Semantic Versioning of the
modules makes dependencies
between modules explicit
{
"name": "magento/module-catalog-inventory",
"require": {
"magento/module-customer": "0.74.0-beta2"
},
"type": "magento2-module"
}
/**
* @api
*/
interface AuthorizationInterface
{
/**
* Check current user permission on resource and privilege
*
* @param string $resource
* @param string $privilege
* @return boolean
*/
public function isAllowed($resource, $privilege = null);
}
@api annotation identifies subset
of the methods with the stable APIs
Enforced by tools and static tests

29. http://alankent.me/2015/10/02/magento-2-
version-numbering-update/
MAGENTO 2 VERSION NUMBERING

30. Magento 1.x Domain Level API
 Model is an entry point to the Module
 Interface implicitly defined via the
database schema
 No single place for the business rules
They can be in:
 Controllers
 Models
 Helpers
 Templates
Model
Resource
Model
Client
getData()

31. Repositories
Service Contracts
Models
Resource
Models/Entity
Manager
Web API clients
M2 Module
Blocks TemplatesControllers
Other M2 Modules
Services
Data
Objects
Service Contracts

32. Domain Level API
Single way to define API for the business
feature
 Defines strong interface
 Single place to implement business rules
 All interactions with the module are safe to
go through the contracts: same behavior
guaranteed
Repositories
Service Contracts
Models
Resource
Models/Entity
Manager
M2 Module
Blocks TemplatesControllers
Services
Data
Objects

33. Service Contracts Interfaces
Service Contracts
Service
Interfaces
Data Interface
Data interfaces
 Defines data structures, used as input and
output types of the business operations
 Examples: Customer, Product, Region,
Currency, etc.
Service interfaces
 Defines business operations
 Examples: load, delete, save, change
password, etc.
They are just PHP Interfaces

34. More on Data Interfaces
 Has just setters and getters to describe
a data
 Reusable across different Service
interfaces
 Encapsulates all the data needed to
process service request
 Can be Serialized
 Annotations are used to extract the data

35. More on Service Interfaces
 Defines public operations supported by
the module
 Methods are independent and
stateless.
 Invocation of one method should not
affect the result of another
 Methods combined in interface by
cohesion principle
 Annotated with types information

36. Classes Implementing Data Interfaces
 It can be Model (NOT
Recommended):
 All the setters and getters should be
declared explicitly
 No magic methods
 It can be Any PHP class:
 Implements data interface and any
other methods
 It can be Data Object:
 Implements just methods from the
data interface
Models
Data
Objects
Data Interfaces

37. Implementation of Service Interfaces
 Resource Models (legacy, not
recommended):
 Used for persistence operations
 Implements load/save/delete
methods and accept Data Interface
as an input
 Entity Manager:
 Used for persistence operations
 ORM implementation
 Services:
 Implements operations and business
rules around them
Service Interfaces
Resource
Models/EntityM
anager
Services

38. Use Service Contracts
 Define dependency on service interface in the constructor
class CreateCustomer extends MagentoCustomerControllerAccount
{
public function __construct(
AccountManagementInterface $accountManagement
) {
$this->accountManagement = $accountManagement;
}
public function execute()
{
$customer = $this->getRequest()->getParam('customer');
$password = $this->getRequest()->getParam('password');
$redirectUrl = $this->getRequest()->getParam('redirect_url');
$customer = $this->accountManagement
->createAccount($customer, $password, $redirectUrl);
…
}
}

39. Re-Implement Service Contracts
 Define a preference in DI: it will point on a new implementation
 All the constructors will be injected with a new implementation
<preference for="MagentoCustomerApiAccountManagementInterface"
type="SomeVendorNewExtensionModelAccountManagement" />
<preference for="MagentoCustomerApiDataRegionInterface"
type="SomeVendorNewExtensionModelDataRegion" />

40. Customize Service Contracts
 Plugins is a way to add new behavior each time Service Interface
implementation is invoked
/**
* Plugin after create customer that updates any newsletter subscription that may have existed.
*
* @param CustomerRepositoryInterface $subject
* @param CustomerInterface $customer
* @return CustomerInterface
*/
public function afterSave(CustomerRepositoryInterface $subject, CustomerInterface $customer)
{
$this->subscriberFactory->create()->updateSubscription($customer->getId());
return $customer;
}

42. Extend Data Interfaces
 Extension Attributes is a way to Extend Data Interfaces from third-
party module
 Added via xml configuration, generated as an object
Review fields
Catalog
Inventory fields
Rating and
Reviews
Module Catalog
Inventory
Module
Product Data
Interface
Product fields

43. Generated Extension Attributes
<extension_attributes for="MagentoCatalogApiDataProductInterface">
<attribute
code="bundle_product_options"
type="MagentoBundleApiDataOptionInterface[]" />
</extension_attributes>
interface ProductExtensionInterface extends MagentoFrameworkApiExtensionAttributesInterface
{
/**
* @return MagentoBundleApiDataOptionInterface[]
*/
public function getBundleProductOptions();
/**
* @param MagentoBundleApiDataOptionInterface[] $bundleProductOptions
* @return $this
*/
public function setBundleProductOptions($bundleProductOptions);
...
}

44. Summary
 Magento 2.x gives stronger promises on public APIs
 Service Contracts are the way to define API for the Business features
 Service Contracts should be the single entry point to functionality of the
module
 Customizable via dependency injection, plugins and extension attributes
 Customizations become available for all the clients of Service Contracts

45. Thank you!
Igor Miniailo
iminiailo@magento.com
Q & A