Feature Modules for Future Proof ApplicationsFeature Modules for Future Proof Applications

Feature modules are a simple concept but way underused in Frontend Development. It's so reasonable that you are going to wonder how come you haven't been using it before. Not using feature modules makes your project harder to navigate, increase merge conflicts while decreasing its scalability. Want to figure out a solution? Let's dig in!

#What's the challenge of grouping code?

Have you ever had a services folder lurking in your project? What about components? Perhaps api?

Those are the kind of folders that can grow uncontrollably quite fast. There's nothing wrong with these types of folders; it's a matter of choosing how nested they are. Since when these folders are quite nested, they are not that dangerous.

Let's check an example:

src/
├── components/
│   ├── button.tsx
│   ├── login-form.tsx
│   ├── signup-form.tsx
│   └── profile-card.tsx
│
├── services/
│   ├── auth.service.ts
│   ├── dashboard.service.ts
│   └── profile.service.ts
│
├── api/
│   ├── auth.api.ts
│   ├── dashboard.api.ts
│   └── profile.api.ts
│
├── hooks/
│   ├── useAuth.ts
│   ├── useDashboard.ts
│   └── useProfile.ts
│
├── pages/
│   ├── login.page.tsx
│   ├── dashboard.page.tsx
│   └── profile.page.tsx
│
├── utils/
│   └── format-date.ts
│
└── main.tsx

Everything here is grouped by type, not by purpose.

This is what we call grouping code by type.

If this project were to stay with these sets of files forever, one would say it's quite manageable. However, we know that software development projects don't stop changing and growing.

In a not-so-distant future we could find ourselves with the following folder:

src/
└──  services/
    ├── auth.service.ts
    ├── user.service.ts
    ├── profile.service.ts
    ├── dashboard.service.ts
    ├── notifications.service.ts
    ├── payments.service.ts
    ├── orders.service.ts
    ├── products.service.ts
    ├── cart.service.ts
    ├── reviews.service.ts
    ├── search.service.ts
    ├── analytics.service.ts
    ├── settings.service.ts
    ├── messages.service.ts
    ├── subscriptions.service.ts
    ├── billing.service.ts
    ├── shipping.service.ts
    ├── inventory.service.ts
    ├── wishlist.service.ts
    └── support.service.ts

Problematic, right?

Let's take a step back, what are we missing?

#How to know how to group code?

In a given project we tend to forget that we are dealing with certain concepts that are not really technical.

Let's imagine we are talking about an application that calculates intergalactic space trips. When a user is describing the features of such an application they don't mention components, api or services, they mention things like users, trip, space-ship or destination.

This unseemingly trivial agglomeration of words is of the utmost importance. Identifying concepts and unifying the language that we use to refer to the same concept is one of our greatest assets as developers.

The effort on creating a distinct language model when describing the application is often called the Ubiquitous languageOpen in a new tab.

“

Using language with precision is our greatest asset as developers.

”

This concept first appeared on Domain Driven DesignOpen in a new tab. Eric EvansOpen in a new tab (its author) describes how important it is that users and developers speak the same language. Knowing the importance of this, now we can find a solution to our problem.

#Grouping code by Feature

In conversations with users, concepts will start appearing. So, what if we use those concepts to group our code?

src/
└── features/
    ├── auth/
    ├── dashboard/
    └── profile/

Now each feature is self-contained.

Something so simple, yet very effective. Now it begs the question, what about the rest of the files?

Well, as we said, there's nothing wrong with having a services, components or api folder, it's just a matter of nesting.

src/
└── features/
    ├── auth/
    │   ├── components/
    │   ├── services/
    │   └── api/
    │
    ├── dashboard/
    │   ├── components/
    │   ├── services/
    │   └── api/
    │
    └── profile/
        ├── components/
        ├── services/
        └── api/

  src/
  └── features/
      ├── auth/
      │   ├── domain/
      │   ├── application/
      │   ├── delivery/
      │   └── infrastructure/
      │
      ├── dashboard/
      │   ├── domain/
      │   ├── application/
      │   ├── delivery/
      │   └── infrastructure/
      │
      └── profile/
          ├── domain/
          ├── application/
          ├── delivery/
          └── infrastructure/

#Benefits of grouping code by Features

This simple change has many benefits. For instance, when we need to change a feature of our application now we don't need to jump from the services folder to the components and then find the components related to, for example, the dashboard.

Now we just head to the dashboard folder and, we can find everything we need there.

Another benefit is that since things are grouped by what they represent and not what they are, we will have fewer collisions with other coworkers, making it easier to parallelize the project.

And if a module grows too big, then we can extract it into a separate application or service if we need to.

So the benefits are:

1. Collocation: Everything related lives together

2. Fewer conflicts: Teams don't overlap

3. Scalable: Easy to extract

#Conclusion

Grouping by feature instead of type is a simple way of making sure your Frontend Architecture is scalable by default. It provides many benefits and is something I don't see often in templates for common projects I see online, so it's easier to miss.

“

Structure follows language.

”

Now, let's take a vote!

I've added a cool new poll component so you can let me know what I should talk about in the next issue of this newsletter.

It's a one-click poll. Easy and handy to me. Since I don't track whether emails are opened or read (because I value your privacy), I will also use this component to know how many people actually read the newsletter. Nifty!

P.S: Before you go, I'm super happy to share with you that I have been selected to speak at Codemotion MadridOpen in a new tab, Commit ConfOpen in a new tab and React SummitOpen in a new tab. So if you are thinking about joining one of those conferences, I'll see you there!

P.S 2: I've been interviewed by Ricardo Benitez from Programando en JavaOpen in a new tab. You can check the Spanish interview hereOpen in a new tab.

P.S 3: Thank you for reading, I really appreciate your time and focus.