Drupal Architecture ~ An architectural vision

There are many factors that we may prevent reuse of a component.

From purely aesthetic reasons, functional aspects, need for innovation.

Getting to decide whether to reuse a component from our library or component provided by a module is an architectural decision.

It is certainly an advantage that time comes, they will have the option to innovate but the re-use.

Without a good system without a good film and architecture, the second option would not be possible.

At the level of modules and other Drupal direct line of action should be to cooperate, but for now, until we standardize a system that allows entities compartment institutions reuse the same way that modules are reused, must be own internal hierarchy of each department that manages these components self.

Certainly a good course of action for the future of Drupal is to increase the functionality of the modules with the most common components, as have the location module, for surely it will create a module named person or people, allowing deployment all the characteristics of the individual.

Given this lack, the creation of individual component, to us, then we must decide whether all our sites must use it or there are some who would use only some characteristics.

The range of possibilities is endless.

We talked about so many other important architectural decisions that focus on project success and the success of an agile methodology components.

We are all partakers of inadequate documentation in most projects.

Excessive, impractical, too complete.

The aim is to prepare a dossier closest to the customer's needs, a documentation Abstract unnecessary details and get closer to the real objectives of each project.

We have a system that simply can represent almost any web project.

This methodology is partially detailed on our website Agile Methodologies .

We want to minimize all documents involved in a project and transform the traditional documentation system in a more agile system made fully operational documents and a documentation system that provides all the information that supports fully categorized and documentary aspects of each project.

It's time to forget about PDF documents, Word of countless pages.

It's time to address adequately the concerns and deploy a system to streamline the consultation process, to avoid redundancy and bet on the philosophy of "living document".

This role is vital to good architecture.

We analyze the needs of each role and to prepare documents according to them, and wrapped in a flexible, intuitive and well categorized.

Therefore the definition of the abstractions necessary to achieve this goal both content and in terms of final documentation will be another parameter to consider in a portal architecture.

Another important feature of free software is its great capacity for change, improvement, new features.

This philosophy is so variant in a short time a good solution becomes obsolete.

It is therefore important for an architect in Drupal to keep up to date on new components, their adaptation to the versions.

Well aware of the Update Status and the Upgrade Status of their portals.

Anticipating problems and when to act, be prepared for it.

It is important to test new features, contributions to the product test, learn about the benefits provided.

Browse product comparisons, analysis of new features made to be able to decide if the news is important for improving the site or simply a code that does not fully expanded new functionality.

Drupal has more than 5,000 modules currently four versions in dance, more than 500 contributions, many information.

All this makes the product complete and complex.

There are a thousand variations and many different ways of doing things has to be any better, except some exceptional cases.

So a good architecture that Drupal should devise ongoing effort in research of new components and upgrades to existing components.

The ability to meet the requirements does not depend on a single product or a single development.

It's free philosophy, our success is intrinsically linked to that of the components used.

Among all grow to improve the quality and it is this quality that allows us to succeed and indirectly improve the applications available to society.

Therefore, improving society.

And is that in terms of poor quality projects the software has been a clear example, because anyone can put a schedule, to try to get the job, as called in my country, regardless of architecture, robustness, security, only goal is to work.

It was that one of the pillars of corporate software failure.

In Drupal in particular and free software in general is not so.

Or should not, because even I have discussed this issue with many people who can not see the software developers and architects should be high profile and expertise and familiarity with the product.

So these changes should be requested to the profiles more in line for it, which are often responsible for that module or theme and that the requested change will enrich the product.

This should be the line of action, and in this line, the increase or improve the functionality provided by Drupal should be an important aspect when addressing the requirements of a future project.

Therefore we consider it more important to share skills with other products and together find a common ideal to have a more robust attempt to make war on each their own.

We must all make the product even better and that means that all components and companies involved in it are also becoming better.

Drupal is why you want even better Varnish, which Memcached increase its efficiency.

Apache, Ngnix, Ligthttp are becoming faster.

MySQL more efficiently.

Php that gets better every day.

That is the free philosophy .

A commitment for quality.

The first few times you come to Drupal, you do not consider its structure as an important location to manage multiple portals.

Drupal developers themselves even begin to orient the possibilities and importance of good architecture files.

Seeing it is a grave error to put everything in "modules."

The opportunity to qualify in "sites / all / modules' different approaches and different groupings of modules.

This ability to discern the common needs of specific options for one or other portal is architecture.

It is important to the proper approach of the websites we want to deploy and is important to understand the approach recommended by Drupal free and, where instead of seeking a single war is bidding for a sharing of knowledge and responsibilities in development.

What we have called Agile Collaborative Methodologies, where your success depends on the success of other companies and resounding in the complete success of the product.

Following this philosophy, the management of websites should not be a version control, for it's own product has its own version control.

Changes or improvements should be consistent and agree with the very perpetrators of these modules or themes.

It is this idea that Drupal gives us, and it is best to ensure the software quality criteria.

Therefore we can see ideal management structure of portals that have to be no version management.

In this structure we have a part directly related to the product such as folders:

-"includes" - "Includes"

-"scripts" - Scripts

-"profiles" - "Profiles"

-"modules" - "Modules"

-"misc" - "Misc"

-"themes" - 'Themes'

It could be a series of symbolic links "pointing to the latest stable version of the product.

Therefore partially delegate files and more generally in product customization sites.

Within files can raise a joint structure with customizations for documents such as icons, logos and images:

/files/ / Files /

This route can be configured to achieve a more optimal coupling of common components.

In the other line, we have the following sites in and structure provided by Drupal

/sites/all/ --> For all sites

/sites/default/ --> Default Settings

As I already said this structure increases the complexity of the site and does not allow us to make a simple approach.

In such a structure would, for example three sites:

sites/site1

sites/site2

sites/site2

sites/all

sites/default

As you can see everything is within the same sites.

We prefer to see the product more easily, where the entire structure is always similar whatever the site and where environmental changes are completely transparent to the internal structure:

In our vision we will:

sites/default --> Just setup

sites/all --> custom common components

This structure will be common to all sites.