Recipes as sustainable product architecture

A Drupal distribution remains maintainable when its capabilities are organised as small, explicit Recipes rather than one monolithic configuration export. Each Recipe describes a product responsibility, its dependencies, and the expected configuration. Teams can see which building blocks a project actually needs and review changes in isolation. Content models, demo records, and optional operational features remain independently testable. This makes updates easier and reduces side effects.

Compose capabilities deliberately

• Maintain domain-specific content types with their fields, views, and editorial rules as independent, repeatable capabilities
• Ship example content separately so production projects can start without demo records
• Enable optional features such as Canvas, workflows, or integrations only where their value and operation are understood
• Validate configuration, translations, and dependencies locally and on a fresh installation for every change

This separation does not replace product decisions, but it makes the responsibility and boundaries of every building block visible. Shared foundations remain lean while project-specific requirements are added through clearly named Recipes. For an update, every capability can be assessed, tested, and rolled back independently. Documented contracts for content, presentation, and operation keep implicit assumptions from moving back into the foundation. The result is a distribution that is not only installable, but can be understood and developed consistently across several projects.