Change Approach on ru file

Author: dyakubovskiy

i18n/ru/docusaurus-plugin-content-docs/current/guides/examples/entity-layer.md

@@ -23,11 +23,11 @@ FSD следует принципу **"Local First"** — начинайте с
 - Код остаётся в `pages/`
 - Используется только в одном месте
 
-**Подход А: Централизованное API** (`shared/api`)
+**Подход 1: Централизованное API** (`shared/api`)
 - API и типы в одном месте
 - Миграция в `entities/` при усложнении
 
-**Подход Б: Доменное API** (`entities/*/api/`)
+**Подход 2: Доменное API** (`entities/*/api/`)
 - Определяется пониманием бизнес-домена — если объект имеет уникальный бизнес-идентификатор и значимое поведение, он заслуживает собственного слайса
 - Размещение API внутри слайса сущности — следствие этого решения, а не основание для него
 - Полная инкапсуляция с первого дня
@@ -249,7 +249,7 @@ pages/settings/api/profile.ts         // getUserProfile() — дубликат!
 
 ---
 
-## Подход А: Централизованное API (`shared/api`)
+## Подход 1: Централизованное API (`shared/api`)
 
 В этом подходе API-функции и доменные типы живут в `shared/api/`, сгруппированные по сущностям. Хорошо подходит, когда сущности ещё в процессе изменений или проект небольшой.
 
@@ -314,7 +314,7 @@ const isAdmin = user.role === 'admin'
 
 ---
 
-## Подход Б: Доменное API (`entities/*/api/`)
+## Подход 2: Доменное API (`entities/*/api/`)
 
 В этом подходе каждая сущность полностью живёт в своём слайсе — включая API, маппинг DTO, доменные типы и бизнес-логику.
 
@@ -680,8 +680,8 @@ export function isInGracePeriod(subscription: Subscription): boolean {
 
 **3. Какой подход API подходит проекту?**
 
-- Важна защита от изменений backend? -> Подход Б
-- Важна скорость итераций? -> Подход А
+- Важна защита от изменений backend? -> Подход 2
+- Важна скорость итераций? -> Подход 1
 
 **4. Нужен ли `model/`?**