Health Checks в .NET — два вызова методов

• AddHealthChecks() регистрирует необходимые сервисы.
• MapHealthChecks() добавляет эндпоинт для проверки состояния приложения.

Но это только инфраструктура. Сами проверки нужно зарегистрировать отдельно.

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

Подробнее о Health Checks

👉 @KodBlog

Хватит возвращать BadRequest("какая-то строка")

Когда каждый эндпоинт возвращает ошибки в своём формате, клиентам приходится отдельно обрабатывать каждый вариант.

В ASP.NET Core есть ProblemDetails: AddProblemDetails() и Results.Problem() помогают использовать единый машиночитаемый формат ошибок по стандарту RFC.

👉 @KodBlog

Пишете код каждый день? Помните о пяти вещах:

• Сначала добейтесь, чтобы код работал.
• Затем сделайте его понятным и аккуратным.
• Подстрахуйте его тестами.
• Избегайте избыточного усложнения.
• Проводите рефакторинг, когда это необходимо — а обычно это необходимо.

Рефакторинг — ваша суперсила для приведения кода в порядок.

Пять проверенных техник рефакторинга

С ИИ-агентами этот подход тоже работает. Но нужно уметь направлять их: ваши навыки разработки по-прежнему пригодятся.

👉 @KodBlog

Один API-запрос на несколько минут создаёт проблемы всем.

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

Решение — изменить подход к обработке долгих задач:

• Принять задачу и сразу вернуть 202 Accepted со ссылкой для проверки статуса.
• Выполнить тяжёлую работу в фоновом обработчике.
• Позволить клиенту опрашивать статус или получить уведомление о готовности результата.

Теперь отчёт, который формируется пять минут, не требует держать HTTP-запрос открытым всё это время. API остаётся отзывчивым, а фоновые обработчики можно масштабировать независимо от веб-серверов.

Длительная задача — это ресурс, который вы создаёте и отслеживаете, а не ответ, которого нужно ждать в открытом соединении.

👉 @KodBlog

Не начинайте с микросервисов ❌

Даже если уверены, что в будущем они понадобятся вашему приложению.

У микросервисов есть скрытые издержки:

• Координация команд.
• Сбои в распределённой системе.
• Работа с eventual consistency — согласованностью данных в конечном счёте.
• Автоматизация развёртывания нескольких сервисов.
• Управление множеством инфраструктурных компонентов.
• Выделение дополнительных ресурсов по мере необходимости.

На старте проекта такая сложность часто не оправдана. Менее рискованный подход:

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

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

👉 @KodBlog

Domain Events и Integration Events: в чём разница?

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

В Domain-Driven Design агрегат задаёт границу согласованности. Если произошедшее внутри него должно вызвать изменения за его пределами, можно опубликовать доменное событие. Обработчики отреагируют на него и выполнят нужные действия, сохраняя слабую связанность между агрегатами.

Доменные события — внутри bounded context. Они помогают отделить основную доменную логику от дополнительных действий.

Интеграционные события — между bounded contexts. Например, один микросервис публикует событие, а другой получает его и обрабатывает.

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

Пример реализации

👉 @KodBlog

Переписать legacy-приложение на .NET с нуля — заманчивый путь в ловушку.

Полтора года работы, заморозка новых функций — и новая система всё ещё не умеет того, что старая незаметно делала в продакшене. Альтернатива — постепенная модернизация с Claude. Последовательный процесс, а не кнопка «переписать всё».

1. Оцените состояние кода
Дайте AI-агентам доступ только на чтение и поручите составить план изменений. Приоритеты определяйте по рискам и ценности для бизнеса.

2. Создайте страховочную сетку
Напишите characterization tests — тесты, фиксирующие текущее поведение приложения, включая существующие баги. Чтобы безопасно менять код, нужно уметь проверять его поведение.

3. Устраните критичный техдолг на старом фреймворке
Исправьте SQL-инъекции, отсутствие необходимых транзакций и утечки ресурсов. Намеренные изменения поведения отражайте в тестах.

4. Подготовьте границы, затем обновляйтесь
Разделите зависимости через DI и обновляйте фреймворк поэтапно, проверяя работоспособность после каждого перехода.

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

Полный процесс модернизации

👉 @KodBlog

Видишь такое в пул-реквесте. Твои действия? 😂

👉 @KodBlog

Модульный монолит: как сохранить границы модулей в базе данных

Модульный монолит обещает удобство разработки монолита и чёткие границы между частями системы. У каждого модуля своя доменная модель, логика и данные.

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

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

Закрепить это можно на уровне БД:

• Выделить каждому модулю отдельную схему и роль.
• Дать роли доступ только к нужной схеме. Настроить search_path, помня, что сам по себе он не ограничивает права.
• Использовать отдельный DbContext в EF Core для каждого модуля, со своей схемой и строкой подключения под соответствующей ролью.
• Для межмодульного чтения при необходимости предоставить представление с доступом только на чтение — как явно согласованный контракт.
• Если нужно ограничить доступ к отдельным строкам внутри таблицы, использовать Row-Level Security.

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

Подробнее о реализации

👉 @KodBlog