Skip to content

Update README_RU.md #306

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.

Sign up for GitHub

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
soltanoff merged 1 commit into from
Aug 8, 2025
Merged

Update README_RU.md #306

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
66 changes: 33 additions & 33 deletions README_RU.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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)
Expand All @@ -25,7 +25,7 @@
Цель этого шаблона - показать принципы Чистой Архитектуры Роберта Мартина (дядюшки Боба):

- как структурировать проект и не дать ему превратиться в спагетти-код
- где хранить бизнес-логику, что бы она оставалась независимой, чистой и расширяемой
- где хранить бизнес-логику, чтобы она оставалась независимой, чистой и расширяемой
- как не потерять контроль при росте проекта

[Go-clean-template](https://evrone.com/go-clean-template?utm_source=github&utm_campaign=go-clean-template) создан и
Expand Down Expand Up @@ -91,7 +91,7 @@ make compose-up-all

### `cmd/app/main.go`

Инициализация конфигурации и логгера. Здесь вызывается основаная часть приложения из `internal/app/app.go`.
Инициализация конфигурации и логгера. Здесь вызывается основная часть приложения из `internal/app/app.go`.

### `config`

Expand Down Expand Up @@ -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_.
Пример:

Expand All @@ -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`

Expand Down Expand Up @@ -199,7 +199,7 @@ reflection.Register(app)
#### `internal/controller/http`

Простое версионирование REST API.
Для создания версии v2, нужно создать папку `http/v2` с таким же содержимым.
Для создания версии v2 нужно создать папку `http/v2` с таким же содержимым.
Добавить в файл `internal/controller/http/router.go` строки:

```go
Expand All @@ -221,18 +221,18 @@ swagger [swag](https://github.com/swaggo/swag).
### `internal/entity`

Сущности бизнес-логики (модели). Могут быть использованы в любом слое.
Также они могуть иметь методы, например, для валидации.
Также они могут иметь методы, например, для валидации.

### `internal/usecase`

Бизнес-логика.

- Методы сгруппированы по области применения (по общему критерию)
- Методы группируются по области применения (по общему критерию)
- У каждой группы своя отдельная структура
- Один файл - одна структура

Репозитории, webapi, rpc и другие структуры передаются в слой бизнес-логики в связующем файле `internal/app/app.go`
(смотрите [Внедрение Зависимостей](#внедрение-зависимостей)).
(смотрите [Внедрение зависимостей](#внедрение-зависимостей)).

#### `internal/repo/persistent`

Expand All @@ -242,7 +242,7 @@ swagger [swag](https://github.com/swaggo/swag).

Это абстрактное web API, с которым взаимодействует бизнес-логика.
Например, это может быть внешний микросервис, к которому бизнес-логика обращается через REST API.
Название пакета выбирается таким, что бы соответствовать его назначению.
Название пакета выбирается таким, чтобы соответствовать его назначению.

### `pkg/rabbitmq`

Expand All @@ -252,13 +252,13 @@ RabbitMQ RPC паттерн:
- Используется fanout-обмен, к которому привязана одна эксклюзивная очередь - это наиболее производительная конфигурация
- Переподключение при потере соединения

## Внедрение Зависимостей
## Внедрение зависимостей

Для устранения зависимости бизнес-логики от внешних пакетов используется внедрение зависимостей.

Например, через конструктор "New" внедряется репозиторий в слой бизнес-логики.
Это делает бизнес-логику независимой и переносимой.
Мы можем переписать реализацию интерфейса репозитория не внося изменения в пакет бизнес-логики `usecase`.
Мы можем переписать реализацию интерфейса репозитория, не внося изменения в пакет бизнес-логики `usecase`.

```go
package usecase
Expand Down Expand Up @@ -298,7 +298,7 @@ func (uc *UseCase) Do() {

Программисты создают оптимальную архитектуру приложения после написания основной части кода.

> Хорошая архитектура позволяет отклыдывать изменение как можно дольше.
> Хорошая архитектура позволяет откладывать изменения как можно дольше.

### Основной принцип

Expand All @@ -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`:

```
Expand Down Expand Up @@ -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`.
Expand All @@ -392,7 +392,7 @@ func (uc *UseCase) Do() {
для создания больших монолитных приложений предложено 4 слоя.

В исходной версии внешний слой делится на два, которые также имеют инверсию зависимостей в другие слои и взаимодействуют
через интерфесы.
через интерфейсы.

Внутренний слой также делится на два (с использованием интерфейсов) в случае сложной логики.

Expand All @@ -403,11 +403,11 @@ func (uc *UseCase) Do() {

### Другие подходы

Кроме Чистой Архитектуры есть и другие подоходы:
Кроме Чистой Архитектуры есть и другие подходы:

- Луковая Архитектура
- Гексогональная (_Порты и адаптеры_ также на неё похожа)
Они обе основаны на на принципе инверсии зависимостей.
- Гексагональная (_Порты и адаптеры_ также похожа на неё)
Они обе основаны на принципе инверсии зависимостей.
_Порты и адаптеры_ очень похожи на _Чистую Архитектуру_. Различия в основном заключаются в терминологии.

## Похожие проекты
Expand Down
Loading