Распространённая ошибка в software architecture, которую я часто встречаю:

→ Код организован без учёта бизнес-задач и частоты изменений.

К счастью, Vertical Slice Architecture (VSA) решает эту проблему довольно просто. Вместо разделения приложения на горизонтальные layers, VSA организует код вокруг конкретных features или use cases.

Почему это важно?

• Такой подход даёт несколько преимуществ:
• Повышает cohesion
• Упрощает поддержку
• Снижает общую сложность
• Фокусирует код на business logic

Вот с чего можно начать: https://milanjovanovic.tech/blog/vertical-slice-architecture-structuring-vertical-slices

👉 @KodBlog

17 ключевых слов C#, которые стоит запомнить

1/ static — принадлежит самому типу, а не конкретному экземпляру.
2/ const — определяет константное значение, известное на этапе компиляции.
3/ readonly — значение можно присвоить только при объявлении или в конструкторе.
4/ async / await — используются для написания асинхронного кода без блокировки потока во время ожидания.
5/ yield — упрощает создание итераторов, возвращая значения по мере их запроса.
6/ ref — передаёт переменную по ссылке, позволяя методу изменять её.
7/ out — передаёт переменную по ссылке, при этом вызываемый метод должен присвоить ей значение.
8/ params — позволяет методу принимать переменное количество аргументов.
9/ is / as — используются для проверки типа и безопасного приведения типов.
10/ lock — обеспечивает эксклюзивный доступ к критической секции в многопоточном коде.
11/ base — предоставляет доступ к членам и конструкторам базового класса.
12/ this — ссылается на текущий экземпляр.
13/ new — создаёт объект или скрывает унаследованный член.
14/ abstract — определяет классы или члены, предназначенные для реализации в производных типах.
15/ sealed — запрещает наследование от класса.
16/ override — предоставляет новую реализацию унаследованного virtual-члена.
17/ partial — позволяет разделить определение типа между несколькими файлами.

👉 @KodBlog

В .NET можно использовать Wolverine как Mediator, не создавая отдельные handler interfaces для каждого request.

Вот как это настраивается:

1/ Установите Wolverine
Добавьте пакет Wolverine в проект.
2/ Зарегистрируйте Wolverine
Настройте Wolverine при конфигурации приложения.
3/ Создайте Request
Определите request как обычный record или class. Специальный mediator interface не требуется.
4/ Создайте Handler
Добавьте метод Handle. Wolverine сам найдёт подходящий handler по conventions.
5/ Вызовите из Endpoint
Внедрите IMessageBus и отправьте request из API endpoint.
6/ Wolverine обработает весь flow
Endpoint → Request → Wolverine → Handler → Response

В результате получается чистый request/response flow с меньшим количеством boilerplate, связанного с Mediator pattern.

При этом возможности Wolverine не ограничиваются mediation: он также поддерживает asynchronous messaging, durable messaging, scheduled delivery, retries, sagas и transactional messaging.

👉 @KodBlog

Я попросил AI-ассистента написать всего один метод.

В итоге он принял за меня с десяток решений — и ни об одном не предупредил.

Промпт был простым: «Получи заказы для списка пользователей». В ответ я получил 10 строк аккуратного C#-кода. Всё компилировалось. Тесты проходили. Казалось, всё отлично.

А потом я внимательно посмотрел на код. Вот какие решения AI молча принял за меня:

• Новый HttpClient при каждом вызове
• Нет timeout
• Нет retries
• Нет ограничения на количество параллельных requests
• Нет cancellation
• Нет logging и tracing
• Ошибка для одного пользователя ломает весь batch

Сегодня ни один из этих пунктов не выглядит как явный bug. На моей машине всё работает. Но каждый из них может стать проблемой в production. Поэтому я это исправил.

👉 @KodBlog

На дворе 2026 год, а вы всё ещё не используете OpenTelemetry?

Вот как он может упростить жизнь software engineer. Если вам важна observability, стоит знать про OpenTelemetry.

Это vendor-neutral open-source стандарт для инструментирования приложений и сбора telemetry data.

Если проще — речь про:
• Logs
• Traces
• Metrics

Работает ли это с .NET? Да. Для .NET есть несколько библиотек, которые достаточно легко интегрировать в приложение.

Вот простой гайд, с которого можно начать знакомство: https://milanjovanovic.tech/blog/introduction-to-distributed-tracing-with-opentelemetry-in-dotnet

👉 @KodBlog

Ваш .NET API отлично работает локально. Но это ещё не значит, что он готов к продакшену.

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

В статье я разобрал, что важно в каждом пункте, почему это имеет значение и как всё настроить на практике в .NET.

Полная статья: https://mwaseemzakir.substack.com/p/before-your-net-api-goes-to-production

👉 @KodBlog

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

→ SignalR

SignalR позволяет добавить взаимодействие в реальном времени в .NET-приложения. При этом клиент может быть написан на React, Angular или обычном JavaScript.

Вы создаёте класс SignalR Hub. Это центральный компонент приложения, который управляет клиентскими подключениями и обменом сообщениями. Клиенты подключаются к Hub, чтобы отправлять и получать сообщения, поэтому связь может быть двусторонней.

SignalR скрывает детали транспортного механизма. Обычно используется WebSockets, но при необходимости библиотека может переключиться на Server-Sent Events или опрос сервера.

Всё, что нужно для начала: статья.

SignalR определённо входит в число лучших библиотек экосистемы .NET.

👉 @KodBlog

Ваш API входа раскрывает злоумышленникам, у кого есть аккаунт?

Распространённая ошибка: Если email не существует, возвращать «Пользователь не найден». Если пароль неверный, возвращать «Неверные учётные данные».

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

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

Когда пользователя не существует, вы пропускаете проверку пароля и быстро возвращаете ответ. Когда пользователь существует, вы обрабатываете введённый пароль с помощью bcrypt или Argon2, а это занимает ощутимое время.

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

Вот как закрыть эту брешь:

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

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

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

👉 @KodBlog

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

Вот почему.

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

С помощью архитектурных тестов можно контролировать:
• Направление зависимостей.
• Соглашения об именовании.
• Различные правила проектирования.

Подробное руководство, которое, думаю, вам понравится: читать статью.

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

Добавили бы такую проверку в свой процесс ревью кода?

👉 @KodBlog

Можете найти ошибку в этом фрагменте кода?

Второй пример вставляет 10 000 записей в базу данных в 43 раза быстрее. Откуда такая огромная разница в производительности?

Код в обоих примерах выглядит похоже. Но если понимать, как EF работает под капотом, ответ становится очевидным.

Каждый вызов SaveChanges означает обращение к базе данных. В первом примере для вставки каждой записи выполняется отдельный вызов. И накладные расходы быстро накапливаются…

Вот как правильно решить эту задачу: читать статью.

Лишние запросы к БД — одна из главных причин падения производительности. Не допускайте этой ошибки в своём коде.

👉 @KodBlog

Интерактивные курсы по Git

GitHub запустила cборку онлайн курсов, где можно прокачать навыки работы с Git и GitHub бесплатно. Ветки, коммиты, pull request’ы, Actions и реальные командные сценарии.

Быстрый и лёгкий способ подтянуть базу и перестать гуглить «как откатить коммит» в неподходящий момент.

👉 @KodBlog

17 .NET-библиотек, которые стоит держать под рукой каждому backend-разработчику

Необязательно писать всё с нуля. Вот какие задачи закрывает каждая:

Wolverine — современный mediator и message bus для CQRS со встроенными outbox, retries и планированием.
Dapper — лёгкий micro ORM. Особенно удобен для сложных запросов с большим количеством таблиц и JOIN.
Serilog — структурированное логирование с поддержкой более 40 sinks.
Bogus — генерация реалистичных тестовых данных для разработки и тестирования.
FluentValidation — валидация моделей с помощью понятного fluent-синтаксиса.
Refit — уменьшает количество boilerplate-кода при работе с HTTP API поверх HttpClient.
Health Checks — стандартный механизм проверки состояния сервисов и интеграции с мониторингом и алертами.
Hangfire / Quartz — надёжное выполнение и планирование фоновых задач для сценариев, где обычных hosted services уже недостаточно.
Noda Time — корректная работа с датами, временем и часовыми поясами. Создана Джоном Скитом.
Autofac — DI-контейнер для более сложных сценариев внедрения зависимостей.
MiniProfiler — простой способ быстро найти узкие места в производительности приложения.
FastEndpoints — библиотека для создания Web API на основе REPR-паттерна. Структурированная альтернатива controllers и Minimal APIs.
NSubstitute — простой в настройке mocking framework для тестов.
System.Text.Json — зрелая сериализация JSON и стандартный вариант для современных .NET-приложений.
BenchmarkDotNet — точные бенчмарки производительности .NET-кода.
Scalar — интерактивная документация для API, современная альтернатива Swagger UI.
SignalR — упрощает реализацию real-time функций: чатов, уведомлений, live-обновлений и других сценариев.

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

👉 @KodBlog