Архитектурные правила должны проверяться автоматически

Даже продуманная архитектура постепенно разрушается, если её границы легко нарушить. Дедлайны, недопонимание и случайные зависимости превращают аккуратную структуру в запутанный код.

В .NET закрепить правила помогают три подхода.

• Компилятор и статический анализ: Модификатор internal скрывает типы от других сборок, а отдельные проекты позволяют ограничивать зависимости между частями приложения. Нарушение доступности обнаружится уже при сборке.

Дополнительные ограничения можно выразить через анализаторы Roslyn. Но дробить приложение на множество проектов или писать собственный анализатор для каждого правила не всегда удобно.

• Архитектурные тесты: Позволяют описать правила проектирования как автоматические проверки. Например:

• Доменный слой не зависит от инфраструктуры.
• Контроллеры не обращаются к базе напрямую.
• Модули взаимодействуют только через публичные API.

Запускаете такие тесты в CI — и обнаруживаете нарушения до слияния изменений.

• Код-ревью с помощью AI: Автоматические проверки дополняются оценкой разработчика: насколько решение соответствует задаче, оправданы ли зависимости и усложнения. AI может ускорить поиск проблем, но архитектурные решения всё равно требуют осмысленного ревью.

Архитектурные тесты превращают договорённости команды в проверяемые ограничения. Это особенно полезно, когда код быстро появляется в больших объёмах, в том числе с помощью AI.

Подробнее об архитектурном тестировании

👉 @KodBlog

Дресс-код: C# casual.

👉 @KodBlog

От .NET к AI: дорожная карта разработчика

Осваивайте разработку AI-приложений поэтапно:

• Основа: C# и .NET, создание API, работа с данными, тестирование, развёртывание и наблюдаемость.
• AI-стек: основы AI, вызовы моделей, RAG, подключение инструментов и оценка качества ответов.

Закрепляйте знания в проектах: API → AI-ассистент → ассистент по документам → автоматизированный процесс с AI.

👉 @KodBlog

Три способа использовать IHttpClientFactory в .NET

IHttpClientFactory помогает централизовать настройки HTTP-клиентов и управлять временем жизни обработчиков соединений.

Есть три варианта:

• Обычные клиенты: создаются через CreateClient(). Общие настройки можно задать при регистрации — настраивать каждый экземпляр заново необязательно.
• Именованные клиенты: отдельная конфигурация для каждого внешнего API, которую выбирают по имени.
• Типизированные клиенты: класс объединяет настройки и методы обращения к API и подключается через DI.

Подробнее о работе с HttpClient

👉 @KodBlog

Как развивался Pattern Matching в C#

Сопоставление с образцом позволяет проверять тип, значение и структуру данных, а также извлекать нужные части в переменные.

На схеме показана эволюция этой возможности от C# 7 до C# 11: от простых проверок типов до рекурсивных, логических и списковых паттернов.

👉 @KodBlog

Модулям не нужна одинаковая структура папок

В модульном монолите каждый модуль владеет своими правилами и данными. Другие модули обращаются к нему через публичный API.

Внутри этой границы можно использовать вертикальные срезы: собрать код сценария SubmitOrder в одном месте, а GetOrder — в отдельном срезе. Общие правила работы с заказами при этом остаются в доменной модели.

Это два разных решения:

• Модуль определяет, чем он владеет и что предоставляет другим.
• Срез объединяет код конкретной функции или сценария.

Модуль продажи билетов может использовать срезы, а другой — слоистую архитектуру. Выбирайте структуру, с которой проще понимать и изменять конкретный модуль, сохраняя правила взаимодействия на его границах.

Разбор с примером на .NET

👉 @KodBlog

Сам 🚬

👉 @KodBlog

Rate limiting в ASP.NET Core — один из уровней защиты API

Ограничение частоты запросов помогает сдерживать перебор паролей, злоупотребления API и перегрузку ресурсов. Но одного middleware недостаточно.

Защищайте весь путь запроса:
CDN и защита от DDoS → WAF → API Gateway → .NET API → зависимые сервисы

На внешних уровнях фильтруйте вредоносный трафик, в API задавайте лимиты для пользователей и операций, а обращения к зависимостям ограничивайте по частоте и числу одновременных запросов.

👉 @KodBlog

Маленькие сервисы не гарантируют быстрое оформление заказа

Если checkout последовательно вызывает три сервиса, пользователь ждёт ответа каждого. Каждый вызов добавляет задержку и ещё одну точку возможного отказа.

Прежде чем добавлять серверы, проследите весь путь запроса. Какие данные нужны прямо сейчас? Где повторяются чтения? Какие действия можно выполнить позже?

Затем проверьте границы сервисов. Если двум сервисам почти для каждой задачи нужны данные друг друга, общение по HTTP не уменьшит их связанность. Возможно, эту логику стоит оставить в одном модуле.

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

Пять вопросов перед разделением системы

👉 @KodBlog

Долгий отчёт не должен удерживать HTTP-запрос открытым

Сохраните задание и верните 202 Accepted с его идентификатором. Фоновый обработчик выполнит работу, а пользователь сможет проверять прогресс.

На старте обработчик может работать внутри приложения, разделяя с API процессор и память. Когда тяжёлые задания начинают замедлять обычные запросы, вынесите его в отдельный процесс и передавайте задания через очередь. Тогда число обработчиков можно увеличивать независимо от API.

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

Пошаговый разбор и цена каждого решения

👉 @KodBlog

Вышел .NET 11 RC2

Microsoft представила второй релиз-кандидат .NET 11. Это ещё не финальная версия, но сборка уже имеет поддержку go-live для использования в production.

Что нового:

• Настройка начального параллелизма HTTP/2.
• Ускорение обработки файловых масок в MSBuild.

Настройка минимального возраста NuGet-пакетов через CLI.
API виртуализации QuickGrid вышли из экспериментального статуса.

Официальный анонс и полный список изменений

👉 @KodBlog

Коварные баги в .NET не выбрасывают исключений.

Регистрируете сервис как Singleton и внедряете в него DbContext, который по умолчанию имеет lifetime Scoped. Без проверки областей видимости приложение может запуститься, но запросы начнут использовать один контекст: устаревшие данные, накопление отслеживаемых сущностей и ошибки при параллельной работе.

Не захватывайте scoped-зависимость внутри singleton. Для работы с БД создавайте отдельную область через IServiceScopeFactory или контекст через IDbContextFactory<TContext>.

Сталкивались с такой ошибкой?

👉 @KodBlog

Оплата прошла. Заказ не оформился.

Так бывает, когда оплатой и остатками управляют разные сервисы. Успешное списание денег ещё не означает, что товар зарезервирован.

Этот сценарий нужно учитывать заранее: сохранять результаты шагов и понимать, что делать дальше. Если товар закончился, может потребоваться возврат денег.

Saga координирует процесс между сервисами. Каждый шаг выполняется в своей локальной транзакции. Если следующий шаг завершается ошибкой, компенсирующее действие отменяет эффект предыдущего: например, возвращает оплату.

Но возврат тоже может не пройти. Сохраняйте его статус, обеспечивайте безопасные повторные попытки и отмечайте случаи, требующие ручного вмешательства. «Запрос на возврат отправлен» не означает «деньги возвращены».

Реализация саги заказа с MassTransit

👉 @KodBlog

Практические уроки для Backend, Data Engineering и DevOps

Площадка с пошаговыми туториалами и облачными окружениями. Изучаем теорию и сразу выполняем команды без настройки локальной среды. В каталоге PostgreSQL, Redis, Docker, Kubernetes, Airflow, Spark и ClickHouse.

https://prepare.sh/

👉 @KodBlog

Данные изменились. Другой сервер всё ещё показывает старое значение.

Так бывает, когда каждый экземпляр приложения хранит локальный кэш. Удаление ключа на сервере A не очищает его копию на сервере B.

Перед кэшированием определите, как долго данные могут оставаться устаревшими. Старое имя в профиле ненадолго допустимо. Отозванное право доступа требует более строгих правил.

Можно рассылать уведомления об изменениях, чтобы серверы удаляли свои копии. Но сообщения могут теряться. Поэтому задавайте абсолютный срок жизни записи: пропущенное уведомление не должно оставлять старое значение в кэше навсегда.

Если операция требует актуальных данных, проверяйте их в системе, которая ими управляет.

Разбор проблемы локального кэша и Redis backplane

👉 @KodBlog

Как выбрать первый модуль для выделения в отдельный сервис

Начните с модуля, у которого мало связей с остальным приложением. Он должен отвечать за понятную задачу, владеть своими данными и иметь причину для отдельного запуска — например, потребность в независимом масштабировании.

До переноса кода найдите все места, которые напрямую читают или изменяют его таблицы. Замените такие обращения явным контрактом взаимодействия и продумайте миграцию данных.

Часть локальных вызовов станет сетевой. Понадобятся тайм-ауты, обработка сбоев и распределённая трассировка, чтобы отслеживать запрос между приложениями.

Выделите один модуль, проверьте его в работе и учтите полученный опыт, прежде чем браться за следующий.

Руководство по выделению первого сервиса и переносу данных

👉 @KodBlog

👉 @KodBlog

12 библиотек .NET, о которых стоит знать каждому разработчику

Сохраняйте подборку и делитесь с коллегами 🔖

👉 @KodBlog

Заказ сохранился, но так и не отправился

Приложение записывает заказ в БД, затем публикует событие для запуска доставки. Если брокер недоступен, а приложение остановится до повторной попытки, событие может потеряться.

Transactional Outbox помогает пережить такой сбой. Заказ и событие сохраняются в одной транзакции БД: либо фиксируются обе записи, либо ни одна.

Фоновый обработчик читает таблицу outbox и отправляет события брокеру. Если отправка не удалась, запись остаётся для повторной попытки.

Но есть нюанс: обработчик может отправить событие и упасть до того, как отметит его отправленным. После перезапуска сообщение уйдёт повторно.

Поэтому получатель должен обрабатывать дубликаты безопасно. Повторное сообщение не должно приводить к повторной отправке заказа.

Проверьте оба сценария:

• Остановите брокер перед отправкой события.
• Остановите обработчик после отправки, но до обновления записи в outbox.

Разбор механизма и настройки в EF Core

👉 @KodBlog

Автоматическая регистрация зависимостей со Scrutor в ASP.NET Core

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

Меньше ручных регистраций — особенно когда в проекте много однотипных сервисов.

👉 @KodBlog