Хочу поделиться с Вами моим видением, как можно структурировать солюшен, когда в нём присутствуют Kafka Consumers, BackgroundJobs (HostedServices, Hangfire и т.п.) на примере BookLibrary.
Данный канал я начинал с более простого варианта и этот пост его дополняет.
Чтобы было проще понять структуру солюшена и знать что куда поместить - я 'https://t.me/sh_dotnet/132?comment=500' rel='nofollow'>нарисовал простенькую схему и выгрузил 'https://t.me/sh_dotnet/132?comment=501' rel='nofollow'>диаграмму зависимостей из Rider.
Основная цель предлагаемой структуры в том, чтобы компоненты были достаточно изолированными, но в тоже время было легко определить по названию что где лежит.
Недостаточная изоляция ведёт к слишком глубокой связанности и к сложностям с выбором места куда поместить тот или иной компонент.
А избыточная изоляция будет мешать разработке из-за церемоний. Поэтому хочется что-то ближе к золотой середине, насколько это возможно.
Так вот, в качестве запускаемого проекта будет BookLibrary.Host
Его задача быть упакованным в докер образ и уметь конфигурировать и запускать подключенные к нему независимые модули: Api, BackgroundJobs, Consumers. При этом модули хочется иметь возможность включать и выключать по флагам.
Например, запускаем образ передав переменные окружения:
BL_KAFKA_CONSUMERS_ENABLED=true - будут запущены Consumers
BL_BACKGROUND_JOBS_ENABLED=true - будут запущены фоновые воркеры
BL_API_ENABLED=true - будут работать API
Таким образом сможем из одного образа задеплоить одно приложение которое включает в себе всё или поделить на 2 или 3 деплоймента, в каждом из которых работают только нужные модули и всё из одного образа. Это упростит скейлинг в будущем.
Похожий подход может быть использован для структурирования модульного монолита.
Вся конфигурация идет через BookLibrary.Host, поэтому дублировать ничего не придется.
Инфраструктура настраивается тоже один раз и переиспользуется.
Отдельно я еще выделил сборку BookLibrary.Kafka, которая фактически является частью внешнего слоя.
Там держу в основном переиспользуемый библиотечный код работы с Kafka и методы регистрации их в DI.
А также кафка модели, например сгенерированный код из protobuf/avro и т.п.
Вообще редко вижу чтобы эту сборку выделяли. Вместо этого все реализуют в Infrastructure.
Но я все ещё считаю, что это плохая идея.
Потому что контракты кафки становятся доступны слишком большому числу сборок, в том числе инфраструктуре и она может начать где-нибудь использоваться их не по целевому назначению, а избавляться от такого потом может быть больно.
Как вариант, содержимое BookLibrary.Kafka можно держать в BookLibrary.Infrastructure или даже вынести в NuGet, а для контрактов сделать отдельную сборку BookLibrary.Kafka.Contracts и подключать их в нужных местах, но на текущий момент мне больше импонирует вариант, когда все что связано с кафкой лежит отдельно в одном месте.
Что думаете о такой структуре? О запуске из одного образа?
Данный канал я начинал с более простого варианта и этот пост его дополняет.
Чтобы было проще понять структуру солюшена и знать что куда поместить - я 'https://t.me/sh_dotnet/132?comment=500' rel='nofollow'>нарисовал простенькую схему и выгрузил 'https://t.me/sh_dotnet/132?comment=501' rel='nofollow'>диаграмму зависимостей из Rider.
Основная цель предлагаемой структуры в том, чтобы компоненты были достаточно изолированными, но в тоже время было легко определить по названию что где лежит.
Недостаточная изоляция ведёт к слишком глубокой связанности и к сложностям с выбором места куда поместить тот или иной компонент.
А избыточная изоляция будет мешать разработке из-за церемоний. Поэтому хочется что-то ближе к золотой середине, насколько это возможно.
Так вот, в качестве запускаемого проекта будет BookLibrary.Host
Его задача быть упакованным в докер образ и уметь конфигурировать и запускать подключенные к нему независимые модули: Api, BackgroundJobs, Consumers. При этом модули хочется иметь возможность включать и выключать по флагам.
Например, запускаем образ передав переменные окружения:
BL_KAFKA_CONSUMERS_ENABLED=true - будут запущены Consumers
BL_BACKGROUND_JOBS_ENABLED=true - будут запущены фоновые воркеры
BL_API_ENABLED=true - будут работать API
Таким образом сможем из одного образа задеплоить одно приложение которое включает в себе всё или поделить на 2 или 3 деплоймента, в каждом из которых работают только нужные модули и всё из одного образа. Это упростит скейлинг в будущем.
Похожий подход может быть использован для структурирования модульного монолита.
Вся конфигурация идет через BookLibrary.Host, поэтому дублировать ничего не придется.
Инфраструктура настраивается тоже один раз и переиспользуется.
Отдельно я еще выделил сборку BookLibrary.Kafka, которая фактически является частью внешнего слоя.
Там держу в основном переиспользуемый библиотечный код работы с Kafka и методы регистрации их в DI.
А также кафка модели, например сгенерированный код из protobuf/avro и т.п.
Вообще редко вижу чтобы эту сборку выделяли. Вместо этого все реализуют в Infrastructure.
Но я все ещё считаю, что это плохая идея.
Потому что контракты кафки становятся доступны слишком большому числу сборок, в том числе инфраструктуре и она может начать где-нибудь использоваться их не по целевому назначению, а избавляться от такого потом может быть больно.
Как вариант, содержимое BookLibrary.Kafka можно держать в BookLibrary.Infrastructure или даже вынести в NuGet, а для контрактов сделать отдельную сборку BookLibrary.Kafka.Contracts и подключать их в нужных местах, но на текущий момент мне больше импонирует вариант, когда все что связано с кафкой лежит отдельно в одном месте.
Что думаете о такой структуре? О запуске из одного образа?