Services MUST be used as objects, they are never static
A single service MUST consist of one class only
Services MUST be located in a
Service/directory and MUST end with
Service instances MAY hold state, but SHOULD be stateless
Services MAY use configuration, but SHOULD not
Services MAY have multiple entry points, but SHOULD have only one
Services SHOULD NOT be singletons
A “service” in this context is meant as the relatively short-sighted
process of putting a class into a
Service/ subfolder and calling
WhateverService. It does not have too much to do with the
DDD Service context, which is broader. This section is just about which
scope can be expected for classes residing in a Service folder within
From this point of view, services in TYPO3 world are a relatively slim class construct that encapsulates a specific concern. It is too big for a small static method, it may hold state, but it is still just a relatively small scope. Each service consists typically of only a single class. A bigger construct with interfaces, multiple sub classes is not called a service anymore.
The above MAY and SHOULD mean that a single service MAY do a single one or two of them, but if for instance a service is relatively big, has many entry points, keeps state and depends on configuration, this is too much and is a sign it should be modeled in a different and more dedicated and more disjoint way.
The main risk with service classes is that they pile up to a conglomeration of helper stuff classes that are hanging around without good motivation. It is important that a service class should not be a bin for something that just does not fit to a different better place within the scope of a specific extension.
Small and straight scope with useful helpers
It is a singleton, but that is feasible in this case
Not modeled in a sane way, this should be within
Far too complex, class abstraction and extending classes