Drupal 8 core concepts and architecture

1. Drupal core, modules, and themes
From an architectural standpoint, we can break up Drupal into three pieces--its core,
modules, and themes.
When we discuss Drupal 8 core, we can interpret it in two ways. A more restrictive
interpretation sees it as a functionality covered in all the code it ships with, without
modules and themes. The more widespread interpretation sees it as the total code base it
ships with (out of the box).

The core libraries are made up of code belonging to the Drupal project and those from the
wider PHP community, which Drupal borrows under open source licensing. This latter
approach is new in Drupal 8 and has been regarded by many as a positive shift toward
getting off the Drupal island and embracing outside libraries, frameworks, and
communities.
Essentially, the core libraries provide the functions and services used throughout Drupal.
Facilities for interacting with the database, translating between languages, sanitizing user
data, building forms, encoding data, and many such utilities are found in Drupal's core
libraries.
The modules (both core and contributed) are where most of the actual functionality and
business logic is. If enabled, they can provide functionality or extend the existing
functionality. Most of the core modules are needed and cannot be disabled due to their
importance in the standard Drupal installation. However, contributed ones can be installed
and uninstalled as needed.
The themes (both core and contributed) are an important part of the theme system and are
used in the presentation logic. They provide HTML templates within which content and
data can be rendered to the user, as well as CSS styling and even client-side scripting for
some nice visual interactions. Themes can extend other themes and can also contain some
PHP logic to process the data before being rendered.

2.Hooks, plugins, and events
Hooks are a very typical Drupal procedural concept that allows Drupal core and modules
to basically ask for data from other modules and themes (or expose it). By doing this, the
latter can provide a new functionality or alter the existing ones. It is the responsibility of the
code that calls the hook to make use of whatever the hook implementations return. The
format and interface for what the latter need to return is usually documented in the hook
documentation.
Concretely, hooks work by scanning installed modules and themes and looking for a
function that follows a specific naming pattern (in other words, a hook implementation). This
is, in most cases, in the following format--module_name_hook_name. Additionally, there
are also alter hooks, which have the word alter tacked on the end of the function name
and are used to change data passed as a reference to the hook implementation

In previous versions of Drupal, hooks were KING. Yes, I wrote this with capital letters, my
Caps Lock did not get stuck. This is because they were the way to add or extend a
functionality in modules. As such, they were the single most important aspect of Drupal
programming. In Drupal 8, however, although still important, they took a backseat to new
concepts, such as plugins and events.
In Drupal 8, I dare to say that plugins are king. Much of the functionalities that used to be
tied to Drupal via hooks is now added in through another Drupal typical concept--plugins
(not to be confused with WordPress plugins). Drupal 8 plugins are discoverable bits of the
functionality centralized by a manager and that are used for certain tasks and features. We
will see more about plugins and provide many examples later in the book.
A third extension point introduced in Drupal 8 is the event system. Unlike the first two,
however, this is not specific to Drupal, but is, in fact, the actual Symfony
EventDispatcher component (http:/ / symfony. com/ doc/ current/ components/ event_
dispatcher. html). Events are primarily used in Drupal to intercept certain actions or flows
in order to either stop or modify them. Many request to response tasks that were handled via
hooks in the past are now being handled by dispatching events to check whether any
modules are interested in, for example, delivering the response to the user.

3. Services and the dependency injection container
Another architecturally important element of Drupal 8 is the Symfony dependency injection
component (http:/ / symfony. com/ doc/ current/ components/ dependency_ injection. html),
concretely represented by the service container.
This component is a staple of modern OOP PHP programming and as such has become
foundational to Drupal 8. It allows us to create services that can be injected in various places
(and receive themselves services as dependencies). They are then used for the heavy
business logic of our functionality. Additionally, they are at times also used as an extension
point because the service container is able to collect certain services that are marked as
serving a specific purpose and use them automatically. In other words, simply by defining a
simple service, we can provide our own functionality or even change the existing logic.