Практическое применение архитектуры Vertical Slice в ASP.NET Core

https://www.telerik.com/blogs/practicing-vertical-slice-architecture-aspnet-core

Автор: Assis Zang

#aspnetcore

👉 @KodBlog

Перестаньте использовать исключения для управления логикой приложения

Вот почему 👇

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

Но есть проблема: исключения подходят далеко не для всех сценариев.

Работая архитектором ПО и .NET-разработчиком, я пришёл к простому выводу:

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

👉 Исключения нужны для обработки действительно нештатных ситуаций.

Но ими не стоит заменять обычную бизнес-логику и ожидаемые условия.

Основные недостатки такого подхода:

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

• Снижение читаемости — try/catch ломает линейный поток чтения кода

• Вложенность — отладка и навигация по коду становятся менее удобными

• Потери производительности — обработка исключений обходится дороже обычных проверок (даже с улучшениями в .NET 9)

Что использовать вместо этого?

✅ Result Pattern

Вместо выбрасывания исключений метод возвращает объект Result.

Так успех и ошибка становятся явной частью контракта метода.

📌 Обычно объект Result содержит:

1️⃣ IsSuccess / IsError — успешно ли выполнена операция

2️⃣ Value — результат выполнения при успехе

3️⃣ Error — информация об ошибке при неудаче

Плюсы такого подхода:

↳ Более предсказуемые API

↳ Более чистый поток выполнения

↳ Проще писать unit-тесты

↳ Лучше производительность

Для этого паттерна уже есть готовые библиотеки:

• FluentResults

• CSharpFunctionalExtensions

• Ardalis.Result

• ErrorOr

Но на практике сторонние пакеты вовсе не обязательны.

👉 @KodBlog

Как работает git?

На изображении схематично изображён процесс работы с Git — системой контроля версий.

Workspace: Рабочее пространство, где находятся файлы проекта (например, .git, src, index.html).
🟢Команда git add перемещает изменения в Stage (область индексации).
🟢Команда git reset отменяет индексацию изменений.

Stage: Область индексации, где изменения подготавливаются для фиксации.
🟢 Команда git commit сохраняет изменения в локальном репозитории.

Local Repository: Локальный репозиторий, где хранятся зафиксированные изменения.
🟢 Команда git push отправляет изменения в удалённый репозиторий.

Remote Repository: Удалённый репозиторий, например, на платформах GitLab, GitHub или Bitbucket.
🟢 Команда git fetch извлекает изменения с удалённого репозитория.
🟢 Команда git pull объединяет изменения удалённого и локального репозиториев (эквивалентно git fetch + git merge).

В нижней части схемы представлена последовательность действий при выполнении команды git pull. 😮

Эта схема полезна для понимания основных этапов работы с Git.

👉 @KodBlog

Сравнение, которое снова разожгло споры о лаконичности языков программирования.
На скриншоте один и тот же HTTP-сервер с маршрутом "/" и ответом "Hello world" реализован на Clojure и C#.

Вариант на C# использует минимальный API из ASP.NET Core и укладывается в несколько строк.
Реализация на Clojure выглядит заметно объёмнее: отдельное описание обработчика, заголовков ответа и запуск Jetty-сервера.

👉 @KodBlog

Большинство разработчиков изучают PostgreSQL в неправильном порядке.

Вот мой личный план изучения, разделённый на 7 уровней.

Не начинайте сразу с:

* тюнинга производительности
* индексов
* репликации
* партиционирования

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

1️⃣ Основы SQL

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

* SELECT
* WHERE
* ORDER BY
* GROUP BY
* агрегатные функции
* базовые JOIN'ы
* LIMIT и OFFSET
* DISTINCT

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

2️⃣ Моделирование данных

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

Сюда входят:

* таблицы
* схемы
* первичные ключи
* внешние ключи
* ограничения
* связи
* нормализация
* типы данных
* соглашения по именованию

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

3️⃣ Продвинутые запросы

На этом этапе вы переходите от простых запросов к более выразительным SQL-конструкциям:

* JOIN'ы
* подзапросы
* CTE
* оконные функции
* условные выражения
* продвинутые агрегации
* запросы к JSON и JSONB
* операции с массивами

Этот уровень позволяет решать сложные бизнес-задачи непосредственно внутри базы данных.

4️⃣ Индексы

Сначала вас волнует, работает ли запрос вообще.

Потом начинает волновать, работает ли он быстро.

Здесь в игру вступают индексы.

Нужно понимать:

* индексы B-tree
* индексы GIN
* индексы GiST
* частичные индексы
* составные индексы
* уникальные индексы
* обслуживание индексов
* когда индексы помогают
* когда индексы вредят

Цель не в том, чтобы добавлять индексы везде подряд.

Цель — понимать, как ваше приложение читает данные.

5️⃣ Тюнинг производительности

На этом уровне вы учитесь анализировать, что база данных делает на самом деле.

Важные темы:

* EXPLAIN
* EXPLAIN ANALYZE
* планирование запросов
* анализ использования индексов
* VACUUM
* ANALYZE
* раздувание таблиц (table bloat)
* статистика
* логи медленных запросов
* настройки памяти и I/O
* настройка конфигурации

Тюнинг производительности — это не угадывание.

Это расследование.

6️⃣ Администрирование

PostgreSQL в продакшене — это не только написание запросов.

Её также нужно безопасно и надёжно эксплуатировать.

Этот уровень включает:

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

7️⃣ Масштабирование и экосистема

Масштабирование — это верхний уровень, а не отправная точка.

Сюда входят:

* партиционирование
* реплики для чтения
* высокая доступность
* логическая репликация
* шаблоны шардирования
* управляемые сервисы PostgreSQL
* инструменты наблюдаемости
* интеграции с экосистемой
* расширения вроде PostGIS, pg_trgm и TimescaleDB

Прочный фундамент — ключ к изучению чего угодно.

👉 @KodBlog

Воскресенский совет для .NET-разработчиков: перестаньте использовать DateTime.UtcNow напрямую в коде.
Используйте TimeProvider.

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

На примере:

public sealed class TrialService(TimeProvider clock)
{
    public bool IsExpired(DateTimeOffset startedAt) =>
        clock.GetUtcNow() >= startedAt.AddDays(14);
}

В тесте:

var clock = new FakeTimeProvider(startedAt);
var service = new TrialService(clock);

clock.Advance(TimeSpan.FromDays(15));

Assert.True(service.IsExpired(startedAt));

Никаких задержек, никаких сюрпризов от DateTime.UtcNow. Просто перематываете время вперёд в тестах и проверяете нужный сценарий.

https://learn.microsoft.com/ru-ru/dotnet/standard/datetime/timeprovider-overview

👉 @KodBlog

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

Называется Deslop. Написан на Rust, но работает не только с Rust-проектами — поддерживает Python, Dart и C#.
Инструмент анализирует кодовую базу, находит дубликаты и помогает избавиться от повторяющихся фрагментов. Автор предлагает просто установить его в VS Code или любой другой форк редактора и использовать прямо в процессе разработки.

Автор проекта также собрал отдельную подборку статей и исследований, которые легли в основу алгоритмов Deslop.

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

👉 @KodBlog

🚀 В .NET 11 Preview 6 появилась новая возможность из C# 15 — extension indexers.

Теперь индексаторы можно объявлять прямо внутри extension-блоков:

static class E
{
    extension(...)
    {
        int this[...] { get => ...; set => ...; }
    }
}

Это позволяет добавлять индексаторы к существующим типам без изменения их исходного кода, так же как сегодня работают extension methods.
Фича уже влита в C# 15 Preview и доступна в .NET 11 Preview 6. 🔥

https://github.com/dotnet/csharplang/blob/main/proposals/extension-indexers.md

👉 @KodBlog

Docker-ошибка, которую я вижу почти в каждом junior Dockerfile:

COPY . .
RUN npm install

должно быть:

COPY package*.json ./
RUN npm install
COPY . .

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

docker кэширует каждую инструкцию как отдельный слой
исходный код меняется с каждым коммитом
поэтому COPY . . ломает кэш, и всё после него (включая npm install) пересобирается с нуля при каждой сборке
если поменять порядок, слой с установкой зависимостей остаётся в кэше даже при изменении кода, потому что он зависит только от package.json
одна перестановка строк. экономит 40+ секунд на каждой пересборке. кэшируй зависимости, а не код.

👉 @KodBlog

Ваш API тормозит в продакшене.

Вы открываете логи.

Сотни записей.

Что дальше?

Логи полезны, но в распределённом .NET-приложении они обычно показывают лишь отдельные фрагменты картины.

Один запрос может пройти через:

→ API
→ другой сервис
→ PostgreSQL
→ Redis
→ брокер сообщений

Когда что-то работает медленно или падает, важно видеть весь маршрут запроса целиком.

Здесь помогают OpenTelemetry и Grafana.

OpenTelemetry собирает телеметрию приложения:

→ трейсы для отслеживания пути запроса
→ логи с контекстом
→ метрики состояния системы

Grafana позволяет анализировать всё это в одном месте.

В результате можно быстро ответить на вопросы:

• Какой запрос был медленным?
• Где именно он потерял время?
• Какой SQL-запрос вызвал задержку?
• Какие логи относятся к этому конкретному запросу?

Вместо поиска иголки в стоге логов вы получаете полную картину происходящего — от входящего HTTP-запроса до последнего вызова базы данных.

👉 @KodBlog

Большинству разработчиков в 2026 году уже не обязательно платить за AI-инструменты.

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

Мой стек за $0:

→ Rider — бесплатно для некоммерческого использования
→ Cursor Hobby — AI прямо в редакторе
→ NotebookLM — работа с документацией и RFC через RAG
→ Granola — конспекты встреч и action items
→ Grammarly — исправление английского на лету
→ Gamma — генерация презентаций за минуты
→ Excalidraw — архитектурные диаграммы без боли

Код, документация, встречи, презентации, диаграммы и AI-помощники.

Ещё пару лет назад такой набор обходился бы в сотни долларов в год. Теперь большая часть доступна бесплатно.

👉 @KodBlog

Собрать 500 файлов без единой ошибки и всё равно не получить исполняемый файл. Звучит странно, но это чистая правда.

Когда один модуль вызывает функцию, которая ссылается на функции, переменные или структуры из другого модуля, компилятор ничего не разрешает. Он просто оставляет пометку. В объектном файле появляется запись о внешнем символе, и компилятору этого достаточно.

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

Собирать по кирпичикам, а не лепить кое-как. Есть статические линкеры и динамические, но об этом в другой раз.

👉 @KodBlog

Что нового в PostgreSQL 19?

PostgreSQL 19 продолжает одну важную тенденцию. Postgres превращается во что-то гораздо большее, чем просто реляционная база.

Самые интересные новинки:

Графовые запросы через SQL/PGQ
PostgreSQL 19 научился выполнять SQL Property Graph Queries. Теперь можно запрашивать связи прямо на SQL, без отдельной графовой базы. Пригодится для соцсетей, рекомендаций, поиска мошенничества и графов зависимостей.

GROUP BY ALL
Вместо того чтобы перечислять все колонки в GROUP BY, пишешь GROUP BY ALL. Postgres сам группирует по неагрегатным колонкам. Меньше шаблонного кода, меньше ошибок.

WAIT FOR LSN
Фича для приложений, которые используют реплики чтения. Позволяет подождать, пока реплика догонит основную базу, прежде чем читать данные. Полезно для консистентности «прочитал то, что написал».

Лучшая поддержка JSON
Postgres и дальше улучшает работу с полуструктурированными данными, не теряя при этом SQL, индексы, соединения и транзакции.

PostgreSQL 19 пока в бете. Детали могут поменяться к релизу. Но направление понятно. Postgres потихоньку становится одной платформой под всё: реляционные данные, документы, графы, аналитика и векторы для AI.

👉 @KodBlog

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

Я посоветовал ему отличный гайд от Beej.

Он перезвонил сегодня. Полный восторга. Делился впечатлениями. Так что вот, снова рекомендую. Для всех студентов и всех, кто только начинает знакомство с Git.

https://beej.us/guide/bggit/

👉 @KodBlog

20 законов разработки, которые должен знать каждый инженер

1. Закон Галла: Работающая сложная система вырастает из работающей простой.

2. KISS: Делай проще. Всё остальное — оверхеад.

3. Закон Конвея: Компании проектируют системы, которые повторяют структуру их коммуникаций.

4. Закон Хайрума: У достаточно большого API уже неважно, что ты обещал в контракте. Кто-нибудь уже зависит от каждого observable-поведения твоей системы.

5. CAP-теорема: Выбери два: консистентность, доступность, устойчивость к разделению.

6. Закон Завински: Любая программа разрастается до тех пор, пока не научится читать почту.

7. Закон Брукса: Добавление людей в опаздывающий проект делает его ещё более поздним.

8. Эффект Рингельмана: Производительность каждого участника группы падает с ростом группы.

9. Закон Прайса: Половину работы делают квадратный корень от всех людей.

10. Эффект Даннинга — Крюгера: Новички переоценивают свои способности, эксперты — недооценивают.

11. Закон Хофштадтера: Всё занимает больше времени, чем ты планируешь, даже с учётом этого закона.

12. Закон Паркинсона: Работа расширяется, чтобы заполнить всё отведённое на неё время.

13. Закон Гудхарта: Когда метрика становится целью, она перестаёт быть хорошей метрикой.

14. Закон Гилба: Измерять неточно лучше, чем не измерять вообще.

15. Принцип Кнута: Забудь о микрооптимизациях в 97% случаев. Преждевременная оптимизация — корень всех зол.

16. Закон Амдала: Ускорение одной части системы ограничено долей времени, которое эта часть реально используется.

17. Закон Мёрфи: Если что-то может пойти не так, оно пойдёт не так.

18. Закон Постела: Будь консервативен в том, что отправляешь, и либерален в том, что принимаешь.

19. Закон Стерджена: 90% всего на свете — фигня.

20. Закон Каннингема: Лучший способ получить правильный ответ в интернете — не задать вопрос, а написать неправильный ответ.

👉 @KodBlog

Postgres использует эффективный по кешу и CPU алгоритм, когда за ORDER BY следует _разумный_ LIMIT. С LIMIT алгоритм сортировки может использовать всего 25кБ памяти. Без LIMIT алгоритму сортировки требуется хранить весь результирующий набор в кеше.

Логично, правда? Если бы вас попросили взять 10 самых больших камней из кучи в 100 камней, вы бы не выстраивали все камни от маленького к большому, а потом брали 10 самых больших. Вы бы отложили 10 в порядке, а затем сравнивали каждый камень с самым маленьким из этих 10 и заменяли бы его, если новый камень больше. (У вас есть возможности, которых нет у баз данных: «быстрый визуальный поиск больших объектов», операторы вроде «визуальная оценка размера» и «взять камень и сравнить ощущаемый вес».)

Это top-N heapsort (пирамидальная сортировка top-N).

При выполнении EXPLAIN ANALYZE на запросе ниже приведён пример top-N heapsort:

Sort  (cost=...) (actual time=... rows=10 loops=1)
  Sort Key: created_at DESC
  Sort Method: top-N heapsort  Memory: 25kB
  ->  Seq Scan on events  (rows=1000000 ...)

Всего 25кБ памяти? Это та маленькая кучка камней, которую вы держите в памяти, пока сканируете всю таблицу.

Без LIMIT используется quicksort (быстрая сортировка), которой нужно держать в памяти весь входной набор, отсортировать его, а затем вернуть первые N строк. Top-N heapsort поддерживает min-кучу фиксированного размера ровно из N кортежей и прогоняет через неё поток входных данных. Вычислительная сложность — O(M log N), где M — количество просканированных строк, а N — LIMIT. По сравнению с O(M log M) для полной сортировки, top-N heapsort также быстрее для CPU.

Используемая память = N × row_size (где N — LIMIT). Для LIMIT 10 со строками по 20 байт это 200 байт. Postgres округляет до минимума в 25кБ для выравнивания и служебных данных. В любом случае, для _разумного_ LIMIT сброса на диск не произойдёт независимо от размера таблицы.

А что насчёт _неразумного_ лимита?

Видели когда-нибудь URL пагинации с per_page=10? Что произойдёт, если изменить его на per_page=1000000, а приложение не валидирует ввод, и запрос получает LIMIT 1000000?

Когда лимит становится слишком большим, Postgres в конечном счёте переключается на quicksort или внешнюю сортировку слиянием (а это убийственно).

Postgres принимает решение на этапе планирования, основываясь на соотношении оценочного количества входных строк к N. Когда N приближается к числу сортируемых строк, поддержание кучи перестаёт быть выгодным, и вступает quicksort. Точная точка перехода зависит от размера строки и оценки планировщика. Ниже приведён гипотетический пример переключения планировщика с top-N heapsort на quicksort. Использование памяти — это объём памяти, занятый сортировкой, а не общее потребление памяти запросом.

LIMIT 10:       Sort Method: top-N heapsort  Memory: 25kB
LIMIT 100:      Sort Method: top-N heapsort  Memory: 30kB
LIMIT 1,000:    Sort Method: top-N heapsort  Memory: 97kB
LIMIT 10,000:   Sort Method: top-N heapsort  Memory: 914kB
LIMIT 100,000:  Sort Method: quicksort       Memory: 9,113kB

Не забывайте про индексы

Top-N heapsort — это оптимизация сортировки неиндексированного набора данных. Она всё равно требует полного последовательного сканирования входных данных. Для 10 самых последних событий среди 1M строк она каждый раз сканирует все 1M строк. Индекс по (created_at DESC) извлёк бы эти 10 строк напрямую, без сканирования всего набора данных.

👉 @KodBlog

Вот лучший способ версионировать API.

Но никто его не использует.

Слышали про версионирование через media type?

Это самый чистый подход к версионированию API.

1. Вы указываете версию API в заголовке Accept.
2. Сервер направляет запросы к соответствующему эндпоинту.

Вы не засоряете URL версиями. Это также можно расширить с помощью контент-nego.

Но версионирование API — лишь средство для достижения цели. Лучший API вообще не использует версионирование.

Вместо этого вам нужен change management.

Change management означает развитие API без неожиданностей и поломок для существующих клиентов. Вместо того чтобы сразу создавать v2, вы сначала спрашиваете: можно ли сделать изменение аддитивным, могут ли старая и новая функциональность сосуществовать, безопаснее ли новая операция, чем изменение существующей, и можно ли обработать deprecation через документацию, runtime-сигналы, миграционные гайды и телеметрию.

👉 @KodBlog

Исторический момент. Новый HTTP-метод в стандарте.

QUERY. Альтернатива GET и POST.

Как GET — не меняет состояние ресурса. Как POST — можно использовать тело запроса. Шлёшь JSON, кешируешь ответ.

Только что повышен до Proposed Standard.

👉 @KodBlog

ОДИН РАЗРАБОТЧИК ЗАНОВО ПРИДУМАЛ ФОРМАТ PDF. И проблема, которую он решил, до смешного очевидна.

Банк попросил его предоставить 17 PDF-файлов для оформления ипотеки.

Он открывал их по одному.
Закрывал их по одному.
Объединял их в один файл.
Стало только хуже.

Тогда он подумал: а что, если PDF работал бы как Figma?

Горизонтальная прокрутка — между страницами.
Вертикальная — между файлами.

До него этого никто не сделал.

Поэтому он расширил стандарт PDF, добавив метаданные.
Он придумал новый формат.
Назвал его .pdfx.

Claude сделал 80% проекта за 2 часа.

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

https://github.com/AlexandrosGounis/pdfx

👉 @KodBlog