Feature oriented architecture for web applications

Feature is a very nature concept for people to understand a system. It’s also used to describe user requirements for software development. But when a feature comes to programmers side it’s usually immediately converted to technical artifacts such as components, actions, models etc. This convention adds the difficulty for new comers or developers themselves serval weeks later to understand the system.

So if we organize a web project by features rather than technique categories (like components, actions, models) it will help us always manage the project under control when the project grows because we construct the system with bigger units.

This architecture is also the key concept of Rekit, a toolkit for building web applications with React, Redux and React router.)


Unlike backend system, frontend web application is the direct interface for user to understand the capabilities of an application. So it’s more suitable to be organized by features.

What is a feature?

A feature is some capability of a system.

That is a feature always adds some functionality to a system. For example, For a content management system, a new supported content type is a feature, for an IDE the capability to run tests is a feature.

Organize application by features

Because we’ve grouped components, actions, stores into features, we don’t need to think about how these small parts work together but we only consider how features work together to construct the whole application. Features are much bigger units than pure technical artifacts like components, actions or models. By analyzing dependencies between features the system could auto generate understandable and accurate diagrams for developers to learn or review the project.

The implementation using React, Redux, React router

Real word example

All Dependencies Visible
Only dependencies among features

By this approach, we separate concerns of a large project. Each feature is self manageable and decoupled from others. To understand the whole project, we look at relations among features, to understand we only look into a single and small feature.

Hard and soft dependencies

When feature A is based on feature B, that is B will not work without A. We say the dependency from B to A is a hard dependency.

For example, diagram feature provides visualization of the project, it uses data from home feature, if no home feature then diagram doesn’t work. Then we say diagram hardly depends on home.

When feature A uses some artifacts from B (depends on B) to provide new capabilities, but if without B, A still works by simply remove related code. Then we say the dependency from A to B is a soft dependency.

For example, in Rekit portal application, Rekit-cmds feature provides the ability to manage Rekit elements, but home feature needs to provide menu items as entries. Then we say home softly depends on Rekit-cmds feature. Soft dependencies usually could be dismissed by designing some extension mechanism. For example, if home feature allows other features to register menu items then there will be no dependencies from home to Rekit-cmds. However an extension architecture always adds much complexity to the system, if not heavily needed, we prefer soft dependencies so that the system is easier to understand or debug.

In Rekit portal diagrams, we can easily find hard in solid lines, and soft dependencies in dashed lines. See below, when mouse over Rekit cmds feature, we can see the hard and soft dependencies.

Dependencies of Rekit cmds feature


Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store