Simple rule:
- If you need to alter data at runtime → plugin.
- If you need to react to an event → observer.
Safe plugin example:
```
public function afterGet($subject, $result) {
$result['custom_field'] = 'value';
return $result;
}
```
Observer example to persist data:
```
public function execute(\\Magento\\Framework\\Event\\Observer $observer) {
$quote = $observer->getEvent()->getQuote();
// persist attributes
}
```
Mixing both without criteria often duplicates queries and breaks tests.
Best practices:
- Avoid `around` when `after` is enough.
- If data is persisted, do it once—not on every step.
- Document which module touches checkout so the flow stays readable.
In enterprise environments, checkout is where revenue breaks first. Less magic, more control.
- If you need to alter data at runtime → plugin.
- If you need to react to an event → observer.
Safe plugin example:
```
public function afterGet($subject, $result) {
$result['custom_field'] = 'value';
return $result;
}
```
Observer example to persist data:
```
public function execute(\\Magento\\Framework\\Event\\Observer $observer) {
$quote = $observer->getEvent()->getQuote();
// persist attributes
}
```
Mixing both without criteria often duplicates queries and breaks tests.
Best practices:
- Avoid `around` when `after` is enough.
- If data is persisted, do it once—not on every step.
- Document which module touches checkout so the flow stays readable.
In enterprise environments, checkout is where revenue breaks first. Less magic, more control.
Comments