chore: updates README.md

README.md

@@ -6,8 +6,8 @@
 ## Оглавление
 
 - [Установка](#Установка)
-- [Базовые примеры](#базовые-примеры)
 - [Назначение](#Назначение)
+- [Базовые примеры](#базовые-примеры)
 - [ServiceContainer](#ServiceContainer)
 - [Наследование](#Наследование)
 - [Service](#Service)
@@ -35,6 +35,37 @@ import {Service} from '@e22m4u/js-service';
 const {Service} = require('@e22m4u/js-service');
 ```
 
+## Назначение
+
+Модуль предлагает два основных класса, `ServiceContainer` и `Service`,
+которые можно использовать как по отдельности, так и вместе для построения
+слабосвязанной архитектуры.
+
+- `ServiceContainer` *(IoC-контейнер)*  
+  Реализация сервис-контейнера через паттерн «Сервис-локатор»;
+- `Service` *(абстрактный сервис)*  
+  Позволяет скрывать работу с контейнером и внедрением зависимостей;
+
+**Инверсия управления (IoC)**
+
+В основе данной архитектуры лежит принцип **Inversion of Control**.
+Вместо того, чтобы сервис сам создавал свои зависимости (например,
+`const api = new ApiClient()`), он запрашивает их у **IoC-контейнера**.
+Контроль над созданием объектов и управлением их жизненным циклом
+*инвертируется* от сервиса к контейнеру.
+
+**Ключевые преимущества**
+
+- **Слабая связанность (Loose Coupling)**  
+  Сервисы не зависят от конкретных реализаций своих зависимостей. Они просто
+  запрашивают другие сервисы по классу-конструктору.
+- **Централизованное управление**  
+  Вся конфигурация зависимостей находится в одном месте (в контейнере),
+  что делает архитектуру более прозрачной и управляемой.
+- **Упрощение тестирования**  
+  Поскольку зависимости не создаются внутри класса, их легко подменить
+  на мок-объекты в тестах.
+
 ## Базовые примеры
 
 Создание контейнера и экземпляра сервиса (Singleton).
@@ -136,36 +167,7 @@ app.start();
 //   app.start();
 ```
 
-## Назначение
-
-Модуль предлагает два основных класса, `ServiceContainer` и `Service`,
-которые можно использовать как по отдельности, так и вместе для построения
-слабосвязанной архитектуры.
-
-- `ServiceContainer` *(IoC-контейнер)*  
-  Реализация сервис-контейнера через паттерн «Сервис-локатор»;
-- `Service` *(абстрактный сервис)*  
-  Позволяет скрывать работу с контейнером и внедрением зависимостей;
-
-**Инверсия управления (IoC)**
-
-В основе данной архитектуры лежит принцип **Inversion of Control**.
-Вместо того, чтобы сервис сам создавал свои зависимости (например,
-`const api = new ApiClient()`), он запрашивает их у **IoC-контейнера**.
-Контроль над созданием объектов и управлением их жизненным циклом
-*инвертируется* от сервиса к контейнеру.
-
-**Ключевые преимущества**
-
-- **Слабая связанность (Loose Coupling)**  
-  Сервисы не зависят от конкретных реализаций своих зависимостей. Они просто
-  запрашивают другие сервисы по классу-конструктору.
-- **Централизованное управление**  
-  Вся конфигурация зависимостей находится в одном месте (в контейнере),
-  что делает архитектуру более прозрачной и управляемой.
-- **Упрощение тестирования**  
-  Поскольку зависимости не создаются внутри класса, их легко подменить
-  на мок-объекты в тестах.
+Подмена сервиса в контейнере (тестирование).
 
 ```js
 // в тестах легко подменить реальный сервис на мок