🔎 Intro

OVERVIEW-ORIENTED

FeatureSliced is an architectural design methodology for frontend projects. It aims to divide an application according to business logic and scopes of responsibility.

• Provides explicitness, controllability and adaptability of architecture
• Based on time-tested design practices and concepts

  SOLID, GRASP, DDD, Separation of Concerns, Vertical Slices, Public API, Isolation

• Suggests dividing the project according to business units

note

The methodology is not tied to a specific tech stack and is applicable to any frontend projects in general.

But the current version is based on and provides examples for JavaScript + React stack.

Basics

More details: "Concepts, Abstractions, Structure"

Motivation

Usually, approaches to building the frontend architecture from project to project are re-invented from scratch, thereby adding "project knowledge"

Despite the fact that the specifics of frontend projects do not differ so much

At the same time, incorrectly made decisions often lead to problems of scalability of the project and the team.

And therefore, instead of inventing and documenting it every time, it is better to summarize the experience and form a working, battle-tested and documented methodology for designing the frontend architecture.

Yes, there are many practices and patterns (SOLID, GRASP, DDD, ...)

But for the frontend it is highly difficult to find well-established and specific approaches

Overview

The methodology is designed to simplify and standardize the decomposition of logic for large and long-lived projects.

To do this, it introduces a number of concepts and abstractions, on which the architecture can be based from project to project - from here we get a number of advantages

info

Module - the structural unit of the project (file / directory)

Explicit business logic

Modules are distributed according to scope of influence, business responsibility and technical purpose

Thanks to this, the architecture is standardized and becomes easier to read

Adaptation to new conditions

Each component of the architecture has its own purpose and does not affect the others

Thanks to this it is possible to independently modify the functionality of the application to meet new requirements without unforeseen consequences

Technical debt and refactoring

Each module is independent and self-sufficient

Thanks to this you can rewrite it from scratch without unexpected side effects

Scaling the project and the team

The increase in functionality leads to significantly less complexity of the project, since all the logic is distributed deterministically and in isolation

Thanks to this it is easy to add and onboard new people to the team, as well as expand the functionality of the project

Controlled reuse of logic

Each module has its own limitations and recommendations for reuse according to its layer

Thanks to this, a balance is maintained between compliance with the DRY principle and the ability to customize the module logic without overhead overrides

What's next?

🚀

Get Started

Quick dive into the methodology

Basics • QuickStart • Motivation

🎯

Guides

Practical guides and application examples

From v1 • From legacy • Examples

🧩

Concepts

Core concepts for better understanding and application

Decomposition • Isolation • Public API

📚

Reference

Reference details of core concepts

Glossary • Layers • Segments

🍰

About

The philosophy of methodology, its goals and place in the modern frontend

Mission • Promote & Integration

💫

Community

Community resources, additional materials

Awesome • Team • Contributing

🛠

Examples

Examples of projects built with Feature Sliced