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

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

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

• Координация команд.
• Сбои в распределённой системе.
• Работа с 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

Как убрать лишние зависимости из .NET NativeAOT-приложения

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

В статье Эндрю Лок показывает, как использовать подмену методов — linker substitutions, — чтобы исключить ненужный код и убрать дополнительные зависимости из итоговой сборки.

Читать статью

👉 @KodBlog

Следующая версия .NET с поддержкой iOS и Android — в отдельной папке репозитория

Без установки на уровне системы. Удаляете папку — и никаких следов этой установки. Один скрипт, реальные замеры и один неожиданный нюанс работы MAUI на следующей версии .NET.

https://dev.to/danardelean/run-the-next-net-today-from-a-folder-in-your-repo-with-nothing-installed-system-wide-26pb

👉 @KodBlog

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

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

В .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