With the switch to using Symfony in Drupal 8 as part of it's core functionality we also have recieved access to a lot more powerful tools than previously available to Drupal developers. One of those very powerful and promising tools is the new Plugin API. The Plugin API system in Drupal 8 allows you to define and extend small pieces of functionality throughout your website. A big user of this new system is Commerce's API where many of the entities and payment handling mechanisms rely on the new Plugin API system. This means that as a developer creating organized code that extends contrib or core functionality has become easier. It has also become easier to create base line modules that you can also extend for your clients. This allows for creating base line things that you can use to create White label solutions.
At its core the new API has three primary components:
- Plugin Types - the central controlling class that provides the definition for how all of the other elements will interact with Drupal 8 and the other modules.
- Plugin Discovery - The second pary of the system is the Plugin discovery, this works very similar to how the old hook system did in Drupal 7, but with this new system things have been optimized more to take advantage of PHP mechanisms.
- Plugin Factory - The plugin factory is responsible for instantiating the Plugin(s) that are needed for various use cases.
In addition to the core elements of the system we also have access to Plugin Derivitives, Discovery Decorators, and Plugin Mappers these additional elements can also play a big part in developing custom plugins for a site.
Why use Plugins?
The new plugin system works very similar to how the native PHP interfaces behave the plugin system can then detect various implementations of a plugin type through PS3 / PS4 namespacing protocols as well as with metadata through the Annotation API. The question then becomes should your custom functionality be implemented as a Plugin or as a Service via Drupal 8's new Service API system.
With plugins we are looking to create a way to implement different behaviors based on a similar, common interface. Services on the other hand aim at implementing the same functionality and are interchangeable the difference only being how they handle things internally. As long as you keep those things in mind then deciding how you will do something should not be too troublesome.