Commit cb986131 authored by Nedjo Rogers's avatar Nedjo Rogers

Issue #15: Remove architecture-decisions page

parent 51c9959a
# Technical Architecture
From March 15 discussion: Major decisions outstanding re distribution architecture
## Major decision areas:
Shared fields vs. each feature has a distinct set of fields.
* Option 1: Use distro prefix in field names
* Pro - consistent
* Con - unique to that feature
* Option 2: Decide which fields to share, put those in a base feature that is required by other features
* Pro - clean reusabilty of fields
* Con - Need that base feature in order for specific features to work
* Option 3: Use distinct fields (eg: prefix every field by content type)
* Pro - Easy for features to work independently
* Con - Fields that use the same data are still different
* Option 4: Avoid concept of a single base feature, but put each specific shared field (view mode, role) in its own
* Pro - Clean reusability, minimum unneeded features
* Con - More overhead to develop, more confusing to other developers/users
## Other decisions
* User roles
* Naming conventions (for fields, css classes, etc.)
* Layout approach (Display Suite, templates, etc.)
* Mauricio's experience, based on using Panopoly-based distro, is that relying on core is in the end easier for end users.
* Process for assessing/adopting/using contrib modules
* Theming approach: base theme?
* Role of design: up front?
* Review process? What constitutes signoff? Forks and pull requests?
* Might want to review Backdrop's decision making policies
* Maybe basic GitHub like workflow: new features go in feature branches, pull requests
## Shared configuration
(An extended commentary by Nedjo)
### Background
To begin, two points.
First, I appreciate the thoughtful comments and contributions on the call today. I think we're starting from a strong shared commitment to finding a well thought out starting place. I'm going to argue for the above "Option 2" (that shared components including field storages should go, for now, into a base feature), but I see the good points made for other positions!
Second, I've been working on what's needed for interoperable distributions for more years than I care to remember now ;) Rosemary and I began work on Open Outreach in 2010. Some notes along the way:
* My [2012 article for Linux Journal on writing interoperable distributions](
* [Attempts to rationalize the scattershot naming of shared components](
* Sections of an [interview I did with Tag1]( (where I contract part time).
I've also immersed myself in several relevant coding initiatives for Drupal 8 ([Features](, [Configuration Share](, and so on) with an [explicit aim of building in interoperability]( So, while I want to ensure we're making a good start with Drutopia, I also want to draw on and learn from years of thinking and hands on experience.
### Shared components
On our March 15, 2016 call we dove right into field storages, but it's worth taking as step back to look at the broader question about shared configuration in general.
In a general sense, shared configuration is what _Drutopia is all about_. Rather than building configuration on a one-off basis for a given site, Drutopia aims to enable pooling of configuration--among multiple sites and also among multiple distributions. From the Drutopia proposal:
> To enable pooled solutions, a key focus needs to be on shared configuration.
So, from a broad perspective, shared configuration is not a problem to be avoided but an aim to be embraced.
Yes, individual features should be interoperable. But that should not be at the expense of pooling solutions. Instead, where appropriate and feasible, we should provide shared configuration elements that can be reused.
Take view modes for example. If it's arguable whether a given content type should share fields with other content types, the case for view modes is probably a lot less so. We want a consistent set of view modes to be used site-wide. More than that, we want different features to use the same view modes (whether or not the features were produced for the same distribution). So we need to share at least _some_ configuration among multiple features.
And doing so explicitly is important. If we leave shared configuration to the whim of individual features, we end up with the scattershot approach that's characterized Drupal 7.
To a certain extent, Drupal core is a model here. Core modules provide shared configuration items for use site-wide. Some examples:
* Body field (, provided by Node module.
* Medium image style (, provided by Image module.
* Footer menu (, provided by System module.
* Full view mode for node (core.entity_view_mode.node.full), provided by Node module.
Some examples of configuration types that may be needed across multiple features:
* Date format
* Field storage
* Form mode
* Image style
* Menu
* Role
* Taxonomy vocabulary
* View mode
### Not _if_ but _how_ and _where_
So it's probably not so much a question of _whether_ we need to provide shared configuration, but _how_.
I'd like to start with the principle that a site built with features (potentially, drawn from multiple distributions) should be as much as possible like any other well designed site.
So in building out our distribution, we should start with an exercise similar to that completed by many shops for a major site build. See for example the still relevant [build spec Larry Garfield shared]( some time back. A _build spec_ captures what's needed to build the site, beginning with the elements needed site wide.
It's true that, if I build out a blog content type and give it the machine name _blog_ it will conflict with a different _blog_ content type provided by a different feature or distribution. But that's a good thing. We should never end up with a site that has two different blog content types, whatever their machine names.
### Iterative approach
Back to the main argument for avoiding shared configuration items: conflicting dependencies.
This is a real issue. For details, see the project page for [Configuration Share]( and the section on Drupal 8 in the [Tag1 interview I linked to above](
But we should not resort to atomization to avoid the issue (every feature defines all its own roles, menus, view modes, field storages, etc.).
Instead, I'm suggesting an iterative approach.
We start with a "Drutopia Core" feature, a repository for shared configuration.
Then, when it's ready, we move to Configuration Share or equivalent, which allows us to provide a library of shared configuration that can be used by multiple features and distributions.
\ No newline at end of file
......@@ -54,7 +54,6 @@ Drutopia's main documentation is organized into a few sections:
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment