Сборка Infrastructure
Эта сборка является частью слоя "Frameworks" из чистой архитектуры Роберта Мартина.
Основное назначение - реализовать абстракции объявленные в слое Application.
Примеры таких абстракций:
* Работа с базой данных
* HTTP клиенты
* Отправка уведомлений на почту/мессенджеры
* Работа с файлами (S3)
* Реализация сборщика метрик используя к примеру OpenTelemetry
* Все в таком духе.
Почему эта сборка нужна? Можно ведь все абстракции реализовать в том же Api?
В теории можно, но на практике появляется необходимость сделать альтернативный интерфейс к микросервису. И помимо классического HTTP API может появиться GRPC API, BackgroundJobs и др. И им всем эти реализации абстракций будут нужны и придется потом их уносить в отдельную сборку - Infrastructure.
Здесь может появиться еще один вопрос - а почему Producer реализуется на уровне BackgroundJobs, а не в Infrastructure? Ведь в GRPC/API они тоже могут понадобиться.
Тут все зависит от того как вы публикуете в шину. Я для этого использую Transactional Outbox.
Поэтому всё что мне нужно сделать - это добавить запись об отправляемом сообщении в базу данных в одной транзакции с изменениями доменных сущностей. Доступ к таблице Outbox в слое Infrastructure имеется, поэтому сложностей обычно не возникает.
Фоновые воркеры, которые сканируют таблицу с outbox messages и доставляют сообщения в шину располагаются в BackgroundJobs или API/GRPC, если Вы не отделяли от них BackgroundJobs.
Поэтому прямого доступа к Producer в целом и не требуется из сборки Infrastructure.
Если же у вас появится соблазн перенести Consumer/Producer и их DTO модели в Infrastructure, будьте с этим аккуратны, так как они становятся доступны во всех сборках выше (API, GRPC, BackgroundJobs etc) и необходимо их тщательно изолировать от некорректного использования и распространения.
Следующим рассмотрим слой Application
Эта сборка является частью слоя "Frameworks" из чистой архитектуры Роберта Мартина.
Основное назначение - реализовать абстракции объявленные в слое Application.
Примеры таких абстракций:
* Работа с базой данных
* HTTP клиенты
* Отправка уведомлений на почту/мессенджеры
* Работа с файлами (S3)
* Реализация сборщика метрик используя к примеру OpenTelemetry
* Все в таком духе.
Почему эта сборка нужна? Можно ведь все абстракции реализовать в том же Api?
В теории можно, но на практике появляется необходимость сделать альтернативный интерфейс к микросервису. И помимо классического HTTP API может появиться GRPC API, BackgroundJobs и др. И им всем эти реализации абстракций будут нужны и придется потом их уносить в отдельную сборку - Infrastructure.
Здесь может появиться еще один вопрос - а почему Producer реализуется на уровне BackgroundJobs, а не в Infrastructure? Ведь в GRPC/API они тоже могут понадобиться.
Тут все зависит от того как вы публикуете в шину. Я для этого использую Transactional Outbox.
Поэтому всё что мне нужно сделать - это добавить запись об отправляемом сообщении в базу данных в одной транзакции с изменениями доменных сущностей. Доступ к таблице Outbox в слое Infrastructure имеется, поэтому сложностей обычно не возникает.
Фоновые воркеры, которые сканируют таблицу с outbox messages и доставляют сообщения в шину располагаются в BackgroundJobs или API/GRPC, если Вы не отделяли от них BackgroundJobs.
Поэтому прямого доступа к Producer в целом и не требуется из сборки Infrastructure.
Если же у вас появится соблазн перенести Consumer/Producer и их DTO модели в Infrastructure, будьте с этим аккуратны, так как они становятся доступны во всех сборках выше (API, GRPC, BackgroundJobs etc) и необходимо их тщательно изолировать от некорректного использования и распространения.
Следующим рассмотрим слой Application