Model Your Data with Drupal and Domain-driven Design

On of the things I've blogged about recently when talking about my upcoming book Model Your Data with Drupal is domain-driven design. While domain-driven design is important and something that I hope to touch on in the future, I've decided it's too much to cover in one book, and I'm refocusing Model Your Data with Drupal on basic object oriented principles.

If you want to know more about this decision and what will be covered in Model Your Data with Drupal, read on.

On studying complex subjects

There are a lot of ways to approach learning a complex, layered subject. You could just dive right in and see if there are any gaps in your foundational knowledge and work backwards to fill in those gaps. Others (like myself) like to try to figure out the best starting place before diving in and work incrementally, building a solid base of foundational knowledge that can be used as a platform for deeper learning. Of course there are advantages and disadvantages to both methods, but I often find that even though I'm inclined to work slowly and try to start at the beginning, I often get farther more quickly when I try to dive into advanced subjects and see what I'm lacking along the way.

Punching above your weight isn't a new idea, and if I had the time and patience to work through it, that's exactly how I would structure Model Your Data with Drupal. But it's not a perfect world, and I ran into some problems along the way. Basically I was trying to leave out too many layers in the software development layer cake. Most people really like cake, so that seemed like a pretty bad idea.

A tasty layer cake of software development

"What is this software development layer cake?" you may ask. It's simply the layers of foundational knowledge that build upon one another. Take this example from my recent presentation on Object Oriented (OO) Design Patterns for Drupal 8:

In this example, more foundational material is at the bottom, (even though basics such as understanding syntax, data structures, control structures, etc have been left out):

OO Basics: The features that define what makes a system or program object oriented: Abstraction, Encapsulation, Polymorphism, Inheritance

OO Principles: The axioms or best practices, these are to OO programming, what principles likes Don't repeat yourself are to procedural or functional programming: Encapsulate what varies, program to interfaces, favor composition over inheritance, strive for loosely coupled designs, depend on abstractions, etc.

OO Patterns: Finally, all of the above basics and principles give us a series of patterns that come naturally, such as decorator, factory, observer, strategy, facade, singleton, etc.

When you put these all together you get something like this:

Enter domain-driven design

This seems simple enough, even though it covers lots of ground. But you may be asking, where does domain-driven design come into this? Is it foundational, or another layer on the top of the cake?

Yes. It's a bit of both, domain-driven design is a process that informs patterns and principles, but it's also something that builds on all of the above, since it requires familiarity with the patterns and principles before you can speak fluently about a project. That doesn't seem like such a hard requirement until you consider that one of the main tenants of domain-driven design is ubiquitous language for bringing developers, engineers, analysts, and domain experts together.

The current

The problem I kept running into while working on Model Your Data with Drupal, was that it was hard to explain the high level concepts of domain-driven design, while also covering the low-level nitty gritty of writing PHP for Drupal. Putting myself in the readers position, it seemed like there was plenty of material for the top and bottom levels of the cake, without much in between.

Because of this, I've decided to put the discussions of domain-driven design and Drupal on hold for now. Model Your Data with Drupal will instead focus on basic object oriented principles and a few patterns, where applicable. If you're reading this book, you should be able to get something that you can easily apply to real world projects, without too much extra fluff, and refocusing this will make the book more clear and easier to understand and put into practice.

The future

The other major factor for this change is that Drupal 8 is looming in the future, with massive changes coming for every Drupal developer. You may have heard about it's sweeping changes, with tons of object oriented systems and dependency injection everywhere. These changes are going to make it easier than ever to apply objected oriented principles to your Drupal projects and modules. Because of this it's going to be easier to describe OO principles and domain-driven design in context of Drupal 8.

Want to learn more?

If you're interested in learning more about the book, you can read more or sign up for the mail list at Model Your Data with Drupal.