Skip to content

feat(intro): add a "For Whom" section #512

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Jul 27, 2022
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 16 additions & 6 deletions i18n/en/docusaurus-plugin-content-docs/current/intro.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -11,17 +11,25 @@ pagination_next: get-started/index

**Feature-Sliced Design** (FSD) is an architectural methodology for scaffolding front-end applications. Simply put, it's a compilation of rules and conventions on organizing code. The main purpose of this methodology is to make the project more understandable and structured in the face of ever-changing business requirements.

Here is how it's accomplished:
## Is it right for me?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Rin-Akaia-eth хелпани с переводом пож

"Is it right for me?" чуть режет слух, но и мой "For whom" возможно тоже не самый лучший варик

image


- A strong foundation of **time-tested** design practices:
_SOLID, GRASP, DDD, Separation of Concerns, Vertical Slices, Public API, Isolation._
- Project partitioning on business domains
- Consistency in file structure
FSD can be implemented in projects and teams of any size, but there are a few things to keep in mind:

- This methodology is for front-end projects only. If you're looking for a back-end architecture, consider [Clean Architecture][refs-clean-architecture].
- A very simple app of a single page might not need the benefits of FSD and suffer from the overhead. However, FSD promotes a nice way of thinking, so feel free to use on the tiniest projects if you want.
- A huge app, the size of the Google Cloud admin dashboard, will require a custom architecture. It could still be based on FSD, by the way.

The methodology is not tied to any particular technology stack and is applicable to most front-end projects. This documentation contains examples in JavaScript + React, but FSD has been successfully adapted to other technology stacks (see [project examples][refs-examples]).
FSD doesn't enforce a particular programming language, UI framework or state manager — bring your own or see some [examples][refs-examples].

If you have an existing project, fear not — FSD can be adopted incrementally. Just make sure that your team is **in&nbsp;pain** from the current architecture, otherwise a switch might not be worth it. <!-- For migration guidance, see the Migration section. TODO: add the migration section and link to it here -->

## Basics

In radically simplified terms, FSD boils down to the following:

- Project partitioning on business domains
- Specific and consistent file structure (see the image below)

![themed--scheme](/img/visual_schema.jpg)

The terms in the diagram above are explained in detail in the [**Abstractions**][refs-basics--abstractions] section.
Expand Down Expand Up @@ -108,3 +116,5 @@ import Link from "@docusaurus/Link";
[refs-motivation]: /docs/about/motivation
[refs-architecture]: /docs/concepts/architecture
[refs-examples]: /examples

[refs-clean-architecture]: https://medium.com/codex/clean-architecture-for-dummies-df6561d42c94