How domain-driven design can help your next Drupal project
If you think back, you can probably remember that moment. The proverbial light bulb clicks on and a smile forms that won't go away, even though you're just staring at the computer screen. Everything finally clicks into place and the power of Drupal unmasks in front of you.
Most Drupal developers I know have had a moment like this after learning about Content Construction Kit (CCK) and Views. A new way of working with the web is unfurled and hard problems seem simple. In no time at all, every feature request and user story is filtered through the lens of the tools and hand.
Why you need to design your API
Everything seems simple enough at first, but after a few more iterations you've implemented custom validations via hook_node_validate and you're saving custom data via hook_node_update and hook_node_insert which ends up loading in hook_node_load. Since the code started out simple enough, you never bothered to design an API to the feature, just using node_load() and other functions to access your data. Before you know it you're trying to explain to a frustrated co-worker where the scattered code lives and what queries to copy so they can load the correct data set since there is no API function that provides the desired functionality.
What happened to the joy of that light bulb moment?