The architecture decisions behind a site build will determine its maintainability, usability, robustness, and the time it takes to build it.

Every successful Drupal shop has at least one person who possesses the skill to take a complex set of requirements and create a simple and clear architecture plan. But this essential skill is difficult to teach and little discussed, as it requires a great deal of broad Drupal experience, and experience seeing the negative effects of bad architectures. Meanwhile it's easy to get started building complex sites in Drupal with little to no thought toward good architecture, creating a plethora of unmaintainable Franken-sites.

I propose that best practice in Drupal site architecture can be taught, and that its fundamental concepts should be understood by all site builders, themers, and developers. The philosophy that makes for good architecture is based on semantic meaning: the same concept for what makes for good markup, URLs, code, etc.

This session will give you an approach to thinking about architecture decisions: how to name things and how to use things consistently with their names.

A site with good semantic architecture will have little or no need for documentation for its administrators. It will be readily understood and improved by new team members or new teams it meets after you. It is likely to be upgraded and enhanced rather than to be scrapped and replaced by its owners.

I will go through many building block nouns of Drupal (think content types, user roles, Views displays, field formatters, path aliases, menus, image styles, Panels panes, Commerce products) and discuss how they should be named, used, and their common pitfalls.

Nearly all of this session will be useful across major versions of Drupal, focusing its examples on architecture patterns in modules which exist in (or are likely to be ported to) D8.