Separation of Concerns in Web Design and Development

Separation of concerns results in more degrees of freedom for some aspect of the website code’s design, deployment, or usage.

Common among these is increased freedom for simplification and maintenance of code.

When concerns are well-separated, there are more opportunities for,

·      module upgrade,

·      reuse, and 

·      independent development.

In web programming, there is a design principle that says that your website implementation should be separated into three domains:

1. Style and presentation: the visual appearance of the site.

2. Business logic: the way that the website behaves in response to user actions.

3. Content: the actual data being presented, such as blog posts or articles.

Following these rules, one would try to avoid having business logic and presentation mixed together, and the same is true for content. If possible, these elements would be contained in different source or data files; if not, then they would be in distinct and easily identified sections of the same file.

There are a number of good reasons for doing this.

The first is that these elements are often changed independently. For example, you may want to present the same web content, with the same business logic, but with a different style.

Or, you may want to present different content, but with the same style and logic. Keeping these elements separate makes it easy to swap out one without affecting the others, especially if the interactions between them are formal and well-defined.

The majority of developers, unfortunately, do not observe separation of concerns.

The general rationale for doing so is that it can actually be really difficult to achieve separation of concerns and to build modular systems.

As usual, many people assume that the short-term easy path which does not require studying difficult concepts and ideas, will get them to their goals at a faster pace.

What these people will not realize is the enormous benefits that are provided from building programs in this way over the intermediate and long-term:

They are easier to read. This will save you and your team plenty of time that would otherwise be spent deciphering code which a developer wrote even days prior.

They are easier to modify, fix, and update. You are working with individual units of code (we could be talking functions, things, or modules); as opposed to continuous and amorphous blobs of code. Whether it’s a new feature or an update of the existing one, isolation of the modules helps with scoping out the areas of the program that may be affected by the change, thus accelerating development.

They are actually easier to design and build. This is perhaps the greatest irony: Some developers think it is easier to build complex programs without any architecture.

Better code clarity. It is much easier to understand what is going on in the website when each module has a concise and clear API with a logically scoped set of methods.

Better code reusability. The main benefit of reusing code is reduced maintenance costs. Whenever you need to extend the functionality or fix a bug, it’s much less painful to do so when you’re certain it appears in only one place.

Better testability. Independent modules with properly scoped functionality and isolation from the rest of the app are a breeze to test whether in Drupal, WordPress or Magento. You don’t need to set up the entire environment to see how your module works, it is sufficient to replace neighboring real modules with dummy mocks or fake data sources. This way you can test the module as the black box by verifying just the output, or as the white box by also seeing which methods are being called on the connected modules.

It is easier to organize simultaneous development by multiple engineers. They just need to agree on which module they are working on to make sure they don’t interfere with each other.

What if . . .

Suppose you and your team successfully release an website. You’re getting great feedback and all is nice in the world.

Then, like they always do, a requirement for a new feature comes in. And for the sake of the argument, this is a feature you absolutely have to do. You can’t refuse it (let’s say the competitor’s website already has it).

What would the potential risks be when you add this feature? We could cite a lot of them, but it all boils down to two things in the end really. First, it’s possible that the feature could be very hard to write because you’d have to write a lot of code in a lot of different places. You also run the risk of breaking current features that paying customers already depend on.

Keeping your concerns separated will decrease the above risks.

Separation of Concerns is that giant on whose shoulders stand many buzzword web design patterns we know today. Just that principle alone provides the required guidance for dramatic improvement of web development quality at all levels.