Merge pull request #306 from lazynvim/patch-1

Update README_RU.md

Author: soltanoff

README_RU.md

@@ -2,7 +2,7 @@
 
 # Go Чистая Архитектура
 
-Шаблон Чистой Архитектурой для приложений на Golang
+Шаблон Чистой Архитектуры для приложений на Golang
 
 [![Release](https://img.shields.io/github/v/release/evrone/go-clean-template.svg)](https://github.com/evrone/go-clean-template/releases/)
 [![License](https://img.shields.io/badge/License-MIT-success)](https://github.com/evrone/go-clean-template/blob/master/LICENSE)
@@ -25,7 +25,7 @@
 Цель этого шаблона - показать принципы Чистой Архитектуры Роберта Мартина (дядюшки Боба):
 
 - как структурировать проект и не дать ему превратиться в спагетти-код
-- где хранить бизнес-логику, что бы она оставалась независимой, чистой и расширяемой
+- где хранить бизнес-логику, чтобы она оставалась независимой, чистой и расширяемой
 - как не потерять контроль при росте проекта
 
 [Go-clean-template](https://evrone.com/go-clean-template?utm_source=github&utm_campaign=go-clean-template) создан и
@@ -91,7 +91,7 @@ make compose-up-all
 
 ### `cmd/app/main.go`
 
-Инициализация конфигурации и логгера. Здесь вызывается основаная часть приложения из `internal/app/app.go`.
+Инициализация конфигурации и логгера. Здесь вызывается основная часть приложения из `internal/app/app.go`.
 
 ### `config`
 
@@ -125,19 +125,19 @@ Protobuf файлы также используются для генераци
 
 ### `internal/app`
 
-Здесь находится только одна _Run_ функция. Она размещена в файле `app.go` и является логическим продолжением функции
+Здесь находится только одна функция _Run_. Она размещена в файле `app.go` и является логическим продолжением функции
 _main_.
 
 Здесь создаются все основные объекты.
-[Внедрение Зависимостей](#внедрение-зависимостей) происходит через конструктор "New ...".
-Эта позволяет слоировать приложение, делая бизнес-логику независимой от других слоев.
+[Внедрение зависимостей](#внедрение-зависимостей) происходит через конструктор "New ...".
+Это позволяет слоировать приложение, делая бизнес-логику независимой от других слоев.
 
-Далее, запускается сервер и ожидается сигнал в _select_ для корректного завершения работы.
+Далее запускается сервер и ожидается сигнал в _select_ для корректного завершения работы.
 Если `app.go` стал слишком большим, вы можете разделить его на несколько файлов.
 
 Если зависимостей много, то для удобства можно использовать [wire](https://github.com/google/wire).
 
-Файл `migrate.go` испольузется для автоматической миграции базы данных.
+Файл `migrate.go` используется для автоматической миграции базы данных.
 Он включается в компиляцию только при указании тега _migrate_.
 Пример:
 
@@ -147,17 +147,17 @@ go run -tags migrate ./cmd/app
 
 ### `internal/controller`
 
-Слой хэндлеров сервера (MVC контроллеры). В шаблоне показана работа 3х серверов:
+Слой хэндлеров сервера (MVC контроллеры). В шаблоне показана работа 3 серверов:
 
 - AMQP RPC (на основе RabbitMQ в качестве транспорта)
 - gRPC ([gRPC](https://grpc.io/) фреймворк на основе protobuf)
 - REST API ([Fiber](https://github.com/gofiber/fiber) фреймворк)
 
 Маршрутизаторы http сервера пишутся в едином стиле:
 
-- Хэндлеры сгруппируются по области применения (по общему критерию)
-- Для каждый группы создается свой маршрутизатор
-- Объект бизнес-логики передается в маршрутизатор, что бы быть доступным внутри хэндлеров
+- Хэндлеры группируются по области применения (по общему критерию)
+- Для каждой группы создается свой маршрутизатор
+- Объект бизнес-логики передается в маршрутизатор, чтобы быть доступным внутри хэндлеров
 
 #### `internal/controller/amqp_rpc`
 
@@ -199,7 +199,7 @@ reflection.Register(app)
 #### `internal/controller/http`
 
 Простое версионирование REST API.
-Для создания версии v2, нужно создать папку `http/v2` с таким же содержимым.
+Для создания версии v2 нужно создать папку `http/v2` с таким же содержимым.
 Добавить в файл `internal/controller/http/router.go` строки:
 
 ```go
@@ -221,18 +221,18 @@ swagger [swag](https://github.com/swaggo/swag).
 ### `internal/entity`
 
 Сущности бизнес-логики (модели). Могут быть использованы в любом слое.
-Также они могуть иметь методы, например, для валидации.
+Также они могут иметь методы, например, для валидации.
 
 ### `internal/usecase`
 
 Бизнес-логика.
 
-- Методы сгруппированы по области применения (по общему критерию)
+- Методы группируются по области применения (по общему критерию)
 - У каждой группы своя отдельная структура
 - Один файл - одна структура
 
 Репозитории, webapi, rpc и другие структуры передаются в слой бизнес-логики в связующем файле `internal/app/app.go`
-(смотрите [Внедрение Зависимостей](#внедрение-зависимостей)).
+(смотрите [Внедрение зависимостей](#внедрение-зависимостей)).
 
 #### `internal/repo/persistent`
 
@@ -242,7 +242,7 @@ swagger [swag](https://github.com/swaggo/swag).
 
 Это абстрактное web API, с которым взаимодействует бизнес-логика.
 Например, это может быть внешний микросервис, к которому бизнес-логика обращается через REST API.
-Название пакета выбирается таким, что бы соответствовать его назначению.
+Название пакета выбирается таким, чтобы соответствовать его назначению.
 
 ### `pkg/rabbitmq`
 
@@ -252,13 +252,13 @@ RabbitMQ RPC паттерн:
 - Используется fanout-обмен, к которому привязана одна эксклюзивная очередь - это наиболее производительная конфигурация
 - Переподключение при потере соединения
 
-## Внедрение Зависимостей
+## Внедрение зависимостей
 
 Для устранения зависимости бизнес-логики от внешних пакетов используется внедрение зависимостей.
 
 Например, через конструктор "New" внедряется репозиторий в слой бизнес-логики.
 Это делает бизнес-логику независимой и переносимой.
-Мы можем переписать реализацию интерфейса репозитория не внося изменения в пакет бизнес-логики `usecase`.
+Мы можем переписать реализацию интерфейса репозитория, не внося изменения в пакет бизнес-логики `usecase`.
 
 ```go
 package usecase
@@ -298,7 +298,7 @@ func (uc *UseCase) Do() {
 
 Программисты создают оптимальную архитектуру приложения после написания основной части кода.
 
-> Хорошая архитектура позволяет отклыдывать изменение как можно дольше.
+> Хорошая архитектура позволяет откладывать изменения как можно дольше.
 
 ### Основной принцип
 
@@ -309,28 +309,28 @@ func (uc *UseCase) Do() {
 Например, приложение можно разделить на два слоя - внутренний и внешний:
 
 1. **Бизнес-логика** (например, стандартная библиотека Go).
-2. **Инструменты** (базы данных, сервера, брокеры сообщений и другие библиотеки и фреймворки).
+2. **Инструменты** (базы данных, серверы, брокеры сообщений и другие библиотеки и фреймворки).
 
 ![Чистая архитектура](docs/img/layers-1.png)
 
 **Внутренний слой** с бизнес-логикой должен быть чистым. Он обязан:
 
-- Не импортировать пакеты с внешних слоев.
+- Не импортировать пакеты из внешних слоев.
 - Использовать только стандартную библиотеку.
 - Взаимодействовать с внешними слоями через интерфейсы (!).
 
 Бизнес-логика не должна ничего знать о Postgres или о реализации web API.
-Бизнес-логика имеет интерфейс для взаимодейсвтия с _абстрактной_ базой данных или _абстрактным_ web API.
+Бизнес-логика имеет интерфейс для взаимодействия с _абстрактной_ базой данных или _абстрактным_ web API.
 
 **Внешний слой** имеет ограничения:
 
-- Компоненты этого слоя не могут знать друг о друге и взаимодействать напрямую. Обращение друг к другу происходит через
+- Компоненты этого слоя не могут знать друг о друге и взаимодействовать напрямую. Обращение друг к другу происходит через
   внутренний слой - слой бизнес-логики.
 - Вызовы во внутренний слой выполняются через интерфейсы (!).
 - Данные передаются в формате, удобном для бизнес-логики (структуры хранятся в `internal/entity`).
 
-Например, нужно обратиться к базе данных из HTTP хэндера (в слое контроллер).
-База данных и HTTP находятся во внешнем слое. Они не знаю друг о друге ничего и не могут взаимодействовать напрямую.
+Например, нужно обратиться к базе данных из HTTP хэндлера (в слое контроллер).
+База данных и HTTP находятся во внешнем слое. Они не знают друг о друге ничего и не могут взаимодействовать напрямую.
 Взаимодействие будет происходить через слой бизнес-логики `usecase`:
 
 ```
@@ -366,12 +366,12 @@ func (uc *UseCase) Do() {
 
 ### Терминология в Чистой Архитектуре
 
-- **Entities** (сущности) - это структуры, с которыми работает бизнес логика.
+- **Entities** (сущности) - это структуры, с которыми работает бизнес-логика.
   Они располагаются в папке `internal/entity`.
   В терминологии MVC сущности - это модели.
-- **Use Cases** это бизнес-логика. Располагается в папке `internal/usecase`.
+- **Use Cases** - это бизнес-логика. Располагается в папке `internal/usecase`.
 
-Слой, с которым бизнес-логика взаимодействует напрямую, обычно, называется _инфраструктурным_ слоем.
+Слой, с которым бизнес-логика взаимодействует напрямую, обычно называется _инфраструктурным_ слоем.
 Это может быть репозиторий `internal/usecase/repo`, внешнее webapi `internal/usecase/webapi`, любой пакет или
 микросервис.
 В шаблоне пакеты _infrastructure_ размещены внутри `internal/usecase`.
@@ -392,7 +392,7 @@ func (uc *UseCase) Do() {
 для создания больших монолитных приложений предложено 4 слоя.
 
 В исходной версии внешний слой делится на два, которые также имеют инверсию зависимостей в другие слои и взаимодействуют
-через интерфесы.
+через интерфейсы.
 
 Внутренний слой также делится на два (с использованием интерфейсов) в случае сложной логики.
 
@@ -403,11 +403,11 @@ func (uc *UseCase) Do() {
 
 ### Другие подходы
 
-Кроме Чистой Архитектуры есть и другие подоходы:
+Кроме Чистой Архитектуры есть и другие подходы:
 
 - Луковая Архитектура
-- Гексогональная (_Порты и адаптеры_ также на неё похожа)
-  Они обе основаны на на принципе инверсии зависимостей.
+- Гексагональная (_Порты и адаптеры_ также похожа на неё)
+  Они обе основаны на принципе инверсии зависимостей.
   _Порты и адаптеры_ очень похожи на _Чистую Архитектуру_. Различия в основном заключаются в терминологии.
 
 ## Похожие проекты