Shopware 6 uses the Symfony Dependency Injection component, so if you are familiar with Symfony services, Shopware 6 custom service development follows the same patterns. Services are defined in src/Resources/config/services.xml, registered with unique string IDs, and injected into controllers, subscribers, and other services via constructor arguments. This guide covers the full workflow from class creation to registration, decoration, and event subscription.

Shopware 6 custom service — DI container registration, constructor injection, decorator pattern and event subscribers by CodeAtoZ

A Shopware 6 custom service is a plain PHP class placed in src/Service/. Best practice is to extract an interface so the service can be mocked in unit tests and replaced via decoration. The class should have no static methods — all dependencies come through the constructor, managed by the DI container. Refer to the Shopware 6 custom service documentation for the official approach.

<?php declare(strict_types=1);

namespace MyPluginService;

use ShopwareCoreFrameworkContext;
use ShopwareCoreFrameworkDataAbstractionLayerEntityRepository;
use ShopwareCoreFrameworkDataAbstractionLayerSearchCriteria;

class ProductSyncService
{
    public function __construct(
        private readonly EntityRepository $productRepository,
        private readonly LoggerInterface $logger
    ) {}

    public function syncProduct(string $productId, Context $context): void
    {
        $criteria = new Criteria([$productId]);
        $product = $this->productRepository->search($criteria, $context)->first();
        // business logic here
        $this->logger->info('Product synced', ['id' => $productId]);
    }
}

Every Shopware 6 custom service must be registered in src/Resources/config/services.xml. The service ID is typically the fully-qualified class name. Dependencies are declared as constructor arguments referencing other service IDs. Always run bin/console cache:clear after editing services.xml — Shopware caches the DI container and will not pick up changes otherwise.

<?xml version="1.0" ?>
<container xmlns="http://symfony.com/schema/dic/services"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:schemaLocation="http://symfony.com/schema/dic/services
           http://symfony.com/schema/dic/services/services-1.0.xsd">
    <services>
        <service id="MyPluginServiceProductSyncService" public="false">
            <argument type="service" id="product.repository"/>
            <argument type="service" id="logger"/>
        </service>
    </services>
</container>

The decorator pattern lets you wrap an existing Shopware 6 custom service or core service without modifying it. Create a decorator class that implements the same interface and accepts the inner service as a constructor argument. Register it in services.xml with a decorates attribute. This is the recommended approach for extending core Shopware services — never edit core files directly. The Shopware 6 developer documentation covers decorator registration in detail.

• Event subscribers: implement EventSubscriberInterface and register with kernel.event_subscriber tag
• Return getSubscribedEvents() array mapping event class names to handler method names
• Inject your Shopware 6 custom service into the subscriber via constructor DI
• Verify registration: bin/console debug:container | grep MyPlugin
• Check Shopware 6 event subscriber documentation for all available system events

Our Shopware development team builds production plugins with full DI architecture, automated tests, and Shopware Extension Store compliance. If you need a Shopware 6 custom service layer for a complex integration, get in touch.