Intro
Enterprise architects have to deal with complex solutions with many moving parts, typically using a number of technologies. Concerns will therefore centre around such issues as governance, reliability and robustness, workable and effective security and maintenance policies, scalability, and how all of these work between the parts and the whole. It’s for this reason that enterprise architects are sometimes (perhaps a little cruelly) described as the ‘town planners’ of the software architecture world.
This brings challenges when Drupal is presented as a component of such a solution, both in terms of general understanding due to lack of experience, but also in applying Drupal as a component part when it is far more widely used as a complete end-to-end platform. (For example, there is often great confusion about whether Drupal represents a front-end or a back-end component.)
In this series we will attempt to answer questions that enterprise architects often ask, such as:
• Where does Drupal store content?
• Where does Drupal store configuration?
• What is the schema like? How would I obtain an entity relationship diagram? And how do I import one into Drupal?
• How would I use stored procedures?
• If Drupal is processing business logic, how do I apply UML schemas?
We will first look at what Drupal is from the perspective of programming style and application architecture, where it sits conceptually on the framework/product spectrum, its aspect orientation and cross-cutting effects, and its approach to content.
We will then delve inside the box, looking at how code is organised and packaged. We will also look at how the database is used and how that relates to the whole.
Finally we will look at Drupal’s capabilities, going beyond content and taking in common topics like caching and testing.
What do architects need to know on first contact with Drupal?
In a nutshell
Drupal is a PHP application which typically runs in a LAMP environment. It can be run with other web servers and supports a number of databases, but it is generally recommended to stick with a common configuration, particularly on an enterprise system which will inevitably bring its own complexities. This means using MySQL as your database, and Apache (or possibly Nginx) for your web server.
In terms of application architecture, Drupal mainly uses procedural programming but is becoming increasingly object oriented. This is particularly so with Drupal 8, which relies on the popular Composer dependency manager for autoloading and delegates many library functions to the Symfony 2 framework. Drupal 8 also introduces namespacing, late static bindings, dependency injection, annotations, and plugins.
Symfony 2 is a very popular PHP component library and framework for developing websites or applications. Many large PHP projects use either the underlying component library or are built directly on the framework. These include Drupal 8, phpBB, Laravel, eZ Publish, Joomla, Magento, Piwik, Behat.
From the point of view of a solutions architect, Drupal is perhaps most easily understood initially as a fairly high level content framework (which out of the box comes with a minimal and possibly underwhelming demo).
PSR
An important change introduced in Drupal 8 was the adoption of the new PSR standard, allowing Drupal to use components from other PSR-compliant frameworks, thus accelerating development and gaining access to innovation across the whole PHP community.
Drupal 8 has made extensive use of this in adopting external libraries including Symfony, Composer, Guzzle, Doctrine, PHPUnit, and Twig.
Is Drupal a product or a framework?
Drupal can be tricky to describe well as it has traits of both a highly configurable product and a full application framework. Some people find it helpful to consider Drupal as a domain-specific framework.
Lego is often used as a metaphor for Drupal, with various relatively low-level component building blocks which while not much use in isolation can be reused and repurposed. Examples of these include:
• Entities (typically bits of content)
• Views (typically lists of content)
• Modules (bits of functionality which can be assembled into a solution and range broadly in scale from full apps to helper components)
This is a somewhat imperfect analogy as many systems are modular - what really sets Drupal apart is not only a very high degree of modularity, but the flexibility and power that come with the ability to extend these modules.
But having first described Drupal as a content framework, in fact many more areas of functionality are covered. The most notable for a solutions architect is perhaps the user module, which provides authentication, role-based access control, and extensible user profiles. The key point here is that while Drupal offers a level of flexibility and composability which we might usually associate with an application framework, it operates at a higher level than a general purpose web application framework such as Rails, Symfony, or Spring - and indeed Drupal 8 uses parts of Symfony as an underlying library.
While we will look at component pieces later in this series to get a feel for what's in the toolkit, there is inevitably a question of reductionism vs. holism when understanding and assessing the capability of frameworks and solutions. We see this in current debates around microservices and monolithic architectures.
In practice, Drupal needs to be considered as a whole due to its architectural characteristics, namely its event-driven hook system, as well as its range across what are often considered separate domains in enterprise architecture - e.g. content, media, users and business objects, social, commerce, event-based rules.
In the next part of this series we will take a deeper dive into some aspects which cut across the system...
