The biggest cause for code smell is to under-think your software architecture, and more tangibly, the design patterns in use. Any decent software developer will tell you that there is no silver bullet when it comes to choosing a design pattern, and as such, we often have to choose from off-the-shelf architectures or improvise our own.

In this post I want to share with you a design I found myself using in several projects. I will temporarily refer to it as Feature-Centric Design Pattern (if you have a more creative name please share) and it is becoming especially handy in single-page JavaScript applications.

In its most simple form, a Feature-Centric Design Pattern consists of two areas (or namespaces): Core Classes and Features.

Core Classes

These will consist of any overlapping system/infrastructural functions, namely:
Bootstrapper, used to register features by specifying the name of the feature to be included on startup, and includes the code to load and initialize each feature.
Controller, used as a non-domain-specific orchestrator, for example calling the bootstrapper at startup, showing or hiding views which are loaded from features, etc.
Settings class is just an example of another centralized and generic function, used by features to write or read settings, such as the state of a control or last computed value, etc.

Features

A feature is encapsulated in its own folder and behaves like a separate ecosystem. Ideally, a feature will follow an MVC pattern, hosting all three layers (models, views, and controller) or sometimes HTML, CSS, and JavaScript. A feature is able to listen to events, request the Controller to reveal a specific view, or make use of the Settings helper. All features are registered in the Bootstrapper class, otherwise they will not be loaded.

Also To Consider

I like to have three other areas (or folders) in addition to the two above: libs for libraries such as jQuery and underscore, plugins for self-contained functionality that is not domain-specific, such as shared custom buttons, and finally, a resources folder for the assets. In the Core namespace I also create a Feature class to be extended by all features to help keep things consistent. Click here for for a screenshot showing the structure of my current project.

Why is this good?

This architecture is not for everyone. The greatest benefit is the unparalleled single responsibility and loose coupling. For example, if you have a “Welcome” screen, all the views and logic will be in that one folder/namespace, significantly reducing the risk of bloated controllers. This works great for small and lean applications, especially mobile applications, where you can conceptualize different screens as different features.

Why is this bad?

Have you noticed how all of this is not domain-model friendly? If you plan on having a lot of models and/or complicated workflows, this design is not for you. If your features (i.e. components) need to continually communicate and are highly dependent on each other, consider a different architecture. Plus be mindful of the lack of testing frameworks.

The Road Ahead

I have been using this in the development of one of my mobile apps, based on PhoneGap and HTML/CSS/JS and so far it has been a great success. I am tweaking and improving as I progress. I am posting this to gauge feedback and based on thatI am considering creating a framework. The framework I am proposing will be based on PhoneGap and will only give developers an underlying architecture to dictate how things should be arranged (to be clear: I am not proposing a UI framework like jQuery Mobile , but an underlying design, like Rails) – what do you think?