Decoupling Drupal modules into PHP libraries: a Commerce 2.x primer

For a while now we've been talking about what Drupal has received from the Symfony ecosystem, and how that is changing the life of an ordinary Drupal developer for the better. But cooperation is not a one way street, and it's time to start talking about what the Drupal community can put back into the Symfony ecosystem. And there's no doubt we have a lot to offer.

A year ago we started the development of Commerce 2.x. Instead of starting with Drupal code, we first created generic PHP libraries that handle generic eCommerce problems such as price storage and formatting, discount and tax handling, address management, and more. We then started building the Drupal layer on top. These new libraries have already started influencing the Symfony ecosystem, influencing a rewrite of symfony/intl as well as increased cooperation with the Symfony eCommerce solutions. Let's talk about what we've learned.

What we'll discuss:

• Candidates for decoupling. Which functionality makes sense as a library outside of Drupal, and which doesn't. How to recognize it.
• The effect such decoupling has on the Drupal codebase, problems and how to avoid them.
• Translating between Drupal and Symfony concepts. Entity API vs Doctrine. Pluggins vs tagged services. Different form implementations.
• Common pitfalls on both sides of the fence.
• The benefits of doing all the extra work in the first place.

We'll be using the Commerce 2.x libraries as an example,  covering the what, the how, and the why.