docs(readme): обновить структуру и содержание README.md, улучшить оформление (#27)

Co-authored-by: petrovyuri <petrovyuri@example.com>
2025-12-22 01:20:46 +00:00 · 2025-09-17 12:46:45 +03:00
parent 03e189e46b
commit c295412f4d
9 changed files with 223 additions and 171 deletions
--- a/tools/rfc/RFC-projects_structure.md
+++ b/tools/rfc/RFC-projects_structure.md
@@ -11,25 +11,24 @@
 - **/ios** - папка, содержащая нативный код для IOS
 - **/env** - папка, с внешними переменными окружения
 - **/lib** - код на Dart, Flutter-приложение
-    - **/app** - содержит основные настройки нашего приложения
-      - **/impls** - реализация интерфейсов
-      - **/interfaces** - объявление интерфейсов
-      - **/data** - общие поставщики данных
-      - **/domain** - общий слой
-      - **/presentation** - общий слой
-    - **/di** - файлы конфигурации зависимостей.
-    - **/routing** - все, что касается роутинга
-    - **/features** - фичи приложения, для каждой фичи создается отдельная папка
-      - **/feature_name** - подробнее см в разделе Структура feature папок
-         - **/data**
-         - **/domain**
-         - **/presentation**
-    - **/gen** - для сгенерированных файлов
-    - **/targets** - таргеты для сборок
-       - **/prod.dart** - сборка для prod
-       - **/dev.dart** - сборка разработки на моковых репозиториях
-       - **/stage.dart** - сборка для stage окружения
-
+  - **/app** - содержит основные настройки нашего приложения
+    - **/impls** - реализация интерфейсов
+    - **/interfaces** - объявление интерфейсов
+    - **/data** - общие поставщики данных
+    - **/domain** - общий слой
+    - **/presentation** - общий слой
+  - **/di** - файлы конфигурации зависимостей.
+  - **/routing** - все, что касается роутинга
+  - **/features** - фичи приложения, для каждой фичи создается отдельная папка
+    - **/feature_name** - подробнее см в разделе Структура feature папок
+      - **/data**
+      - **/domain**
+      - **/presentation**
+  - **/gen** - для сгенерированных файлов
+  - **/targets** - таргеты для сборок
+    - **/prod.dart** - сборка для prod
+    - **/dev.dart** - сборка разработки на моковых репозиториях
+    - **/stage.dart** - сборка для stage окружения

 ## Пример структуры feature папок

@@ -44,32 +43,38 @@
 - **/presentation** - слой представления
  - **/screens** - все экраны должны заканчиваться на Screen, например UserProfileScreen.
  - **/components** - виджеты, которые необходимы для работы в presentation слое. Например: SuperButton, AppTextFields итд.
-# Пояснение к структуре feature папок

-## Data (слой данных) Этот слой является поставщиком данных.
- - Repository - сущность, которая реализует внутри себя предоставление данных. Должен реализовывать какой либо интерфейс репозитория из domain слоя.
- - DTO - Dto(Data Transfer Object) модели, и модели с которыми происходит работа в data слое. Например: UserDto;
+## Пояснение к структуре feature папок

-## Domain (слой бизнес логики)
- - Entity - должны быть в максимально удобном виде для работы внутри Domain и Presentation. Например: UserEntity, ShopEntity;
- - State - управления состоянием  - state manager
- - Service - различные сервисы, для выполнения различных задач.
- - interfaces - интерфейсы репозиториев, которые используются в domain слое.
+### Data (слой данных) Этот слой является поставщиком данных

-## Presentation (слой представления)
- - сomponents - widget'ы которые реализуют работу какого либо визуального компонента(Buttons,TextFields,Lists, итд). Например: ShopList, RateButton. Модальные окна.
- - screens - widget'ы которые представляют собой экран приложения. Например: UserInfoScreen.
+- Repository - сущность, которая реализует внутри себя предоставление данных. Должен реализовывать какой либо интерфейс репозитория из domain слоя.
+- DTO - Dto(Data Transfer Object) модели, и модели с которыми происходит работа в data слое. Например: UserDto;

-# Основные правила общения объектов между папками
+### Domain (слой бизнес логики)

-## В рамках всего приложения
- - объекты внутри фичи должны быть инкапсулированы и не могут использоваться в других feature;
- - если есть необходимость использовать объект в нескольких feature, его нужно вынести в папку app и использовать как глобальный для всего приложения;
- - сервис, который должен быть использован в нескольких feature, создается как отдельная feature;
- - если создаваемый сервис является платформно-зависимым, его необходимо выносить в app_services. В приложении должен быть только интерфейс.
+- Entity - должны быть в максимально удобном виде для работы внутри Domain и Presentation. Например: UserEntity, ShopEntity;
+- State - управления состоянием  - state manager
+- Service - различные сервисы, для выполнения различных задач.
+- interfaces - интерфейсы репозиториев, которые используются в domain слое.

-## В рамках одной feature
- - объекты data слоя не должны ничего знать про объекты слоя presentation. Имеют доступ к объектам entity из domain слоя для преобразования DTO в Entity ;
- - объекты domain слоя не должны ничего знать про объекты слоя data, используемый экземпляр репозитория передается в объекты domain слоя через интерфейс репозитория, расположенного в этом же domain слое;
- - объекты domain слоя не должны ничего знать про слой presentation, не должны использовать компоненты библиотек ui, material, cupertino, widget и прочих, не должны использовать context;
- - объекты presentation слоя не должны ничего знать про объекты слоя data, все взаимодействия непосредственно через объекты слоя domain.
+### Presentation (слой представления)
+
+- сomponents - widget'ы которые реализуют работу какого либо визуального компонента(Buttons,TextFields,Lists, итд). Например: ShopList, RateButton. Модальные окна.
+- screens - widget'ы которые представляют собой экран приложения. Например: UserInfoScreen.
+
+## Основные правила общения объектов между папками
+
+### В рамках всего приложения
+
+- объекты внутри фичи должны быть инкапсулированы и не могут использоваться в других feature;
+- если есть необходимость использовать объект в нескольких feature, его нужно вынести в папку app и использовать как глобальный для всего приложения;
+- сервис, который должен быть использован в нескольких feature, создается как отдельная feature;
+- если создаваемый сервис является платформно-зависимым, его необходимо выносить в app_services. В приложении должен быть только интерфейс.
+
+### В рамках одной feature
+
+- объекты data слоя не должны ничего знать про объекты слоя presentation. Имеют доступ к объектам entity из domain слоя для преобразования DTO в Entity ;
+- объекты domain слоя не должны ничего знать про объекты слоя data, используемый экземпляр репозитория передается в объекты domain слоя через интерфейс репозитория, расположенного в этом же domain слое;
+- объекты domain слоя не должны ничего знать про слой presentation, не должны использовать компоненты библиотек ui, material, cupertino, widget и прочих, не должны использовать context;
+- объекты presentation слоя не должны ничего знать про объекты слоя data, все взаимодействия непосредственно через объекты слоя domain.