My first session of Drupalcon run by Jeff Eaton,  sadly was stripped of all burrito analogies. But, lucky it was not stripped of great information about how the "Drupal Stack" is layered. Along with his overview of the five layers of Drupal, Jeff covered some practices to follow to make sure any development you do towards a Drupal application does it's best to keep the layers separate (when possible).

First a bit of history.  Jeff explained that in the past, when it was simpler times, Drupal was composed of three main layers:


- Contrib Modules

- Drupal Core.

Simple, straight forward.  The core layer, contained all of Drupals default functionality.  Contrib Modules, the extra functionality you threw onto your Drupal application. And the theme layer, the display and HMTL generation .

Now, things are not as simple, things have become more complicated and the layers have become muddled and more complex. In the simplest terms Jeff broke down what the current five layers of Drupal are.

The Products layer:

This is the layer that the end user sees, what is handed over to clients.  It is the "Drupal Product" you hand over to your clients. In Jeffs burrito analogies, it is the tortilla, it wraps everything.

The Features Layer:

The end functionality, what your drupal users actually interact with.  This is the layer that your users/clients care about, the features are what tehy see and use.

The "Building Tools" layer:

This is the layer where a Drupal product is built. It's composed of the different tools (modules) that developers/adminstrators use to build nodes, forum, image galleries, ect. "The Drupal Application", this is the first layer in the stack that your site visitors/content maintainers do not care about (in fact they will not care about any of the other layers).  This is the first layer that is for devs only.

The "Building Blocks" layer:

The code and architecture layer. This is the individual modules layer, weather it is a contributed module or your own custom developed module. this is the most important layer to developers, it's where their drupal code goes to be used in the building tools layer to build a Drupal application.

The "Web framework" layer:

The least "drupally", this is the layer of code that is simply needed to get a web application running. HTTP requests, database calls, sessions, caching, ect...

Ok so there are five layers , who care? Well as Jeff pointed out, all Drupal developers should care about the layers and developing within there respected layers. "Complexity means collissions".  the more muddled the work we produce, the harder it is to maintain, update and future proof.

If developers focus on writing there code/modules/applications with these five layers in mind it'll make it easier to contribute, share, produce code of better quality.  How to accomplish this? Follow a few rules:

Generic is hard:  the more generic of a problem you are trying to solve, the harder it is to implement. To combat this, when developing keep problems simple.  If you have a large problem you need to solve, break it down into simpler problems and solve them separately (separate modules)

Examples beat assumptions:  Do not assume what your module is going to be used for, instead provide examples of what it can be used for.  when you assume, you are limiting what other can do with your module. So do not assume what your module will be used for, but keep it open and provide examples of what it can be used for. Others will comeback to you with uses for your module, add-on modules that you might never even thought of.

Blur to optimize, isolate to reuse: It's true in the world that you will not always have time to develop a clean module that keeps the layers separate, there are times where you just need to get it done and built.  In these instances, build to optimize, get your code to run the best that it can.  But if you do have the time, build to isolate.  Keep the layers seperate, and build the best you can so that your code/module can be reused.