Зачем этот блог: проектирование, архитектура и здравый смысл
Содержание
Я несколько лет собирался начать писать.
Не в смысле “было бы неплохо когда-нибудь” – в смысле у меня были заметки, черновики, наброски статей. Папка с материалами разрасталась, а до публикации не доходило ни разу. Знакомо?
Типичная история: днём ты решаешь реальные задачи – проектируешь, пишешь код, споришь на ревью. Вечером думаешь “надо бы это оформить в статью”. Потом открываешь редактор и понимаешь, что объяснить решение сложнее, чем его принять. И закрываешь редактор до следующего раза.
Так вот, следующий раз наступил.
Почему сейчас
У меня за спиной 10+ лет в бэкенде на .NET. EdTech, business travel, fintech, SaaS для маркетплейсов – каждый домен со своими сюрпризами. Я прошёл путь от “давайте начнём со схемы БД” до Domain-Driven Design, от монолитов до микросервисов (и обратно к модульным монолитам – но это отдельная история).
На каждом проекте я набивал шишки. И каждый раз думал: “Вот это точно стоит записать”. Проблема в том, что между “стоит записать” и “записал” проходило… ну, несколько лет.
Переломный момент – я начал замечать, что одни и те же разговоры повторяются. В разных компаниях, с разными командами, но сценарий один:
Почему эстимейт на простую фичу – месяц?
Мы же уже это обсуждали, почему опять сломалось?
А кто вообще отвечает за этот кусок системы?
Каждый раз я объяснял одно и то же. И подумал: может, проще написать один раз нормально.
О чём здесь будет
Этот блог – про проектирование, которое работает. Не про теорию ради теории, не про красивые диаграммы для презентаций. Про решения, которые ты принимаешь каждый день – и которые через полгода определяют, летит проект или буксует.
Конкретнее:
- Стоимость изменений – почему одни системы легко развивать, а другие превращаются в болото после первого года
- Domain-Driven Design на практике – не пересказ Эванса, а как это реально работает в продуктовых командах
- Bounded Contexts и модульность – как резать систему так, чтобы команды не стояли в очереди друг за другом
- Тактические паттерны – Aggregates, Value Objects, Domain Events – с кодом на C#, не абстрактно
- Event Storming – как за два дня вытащить из бизнеса то, что обычно узнаёшь через полгода багов
Код будет на C# (.NET 10), но идеи не привязаны к стеку. Если ты пишешь на Java, Go или TypeScript – паттерны те же, синтаксис другой.
Чего здесь не будет
Буду честен: я не планирую пересказывать учебники. Если тебе нужно определение Aggregate Root – есть книга Эванса и десяток статей на Medium. Здесь будет то, чего в учебниках нет: что происходит, когда паттерн встречается с реальным проектом.
Я не буду делать вид, что DDD – это серебряная пуля. Я сам на одном проекте увлёкся CQRS настолько, что создал больше сложности, чем решил проблем. Такие истории тоже будут – потому что из факапов учишься быстрее, чем из success stories.
И ещё: я пишу для практиков. Для тех, у кого завтра утром стендап и реальные задачи в Jira. Не для тех, кто хочет “изучить архитектуру” абстрактно. Если после статьи ты не можешь ничего применить на своём проекте – значит, статья не удалась.
Формат
Основной контент – лонгриды в блоге. Каждая статья разбирает одну тему глубоко, с кодом, примерами и честным разбором trade-offs.
Параллельно веду Telegram-канал – там короче и острее. Истории из практики, горячие takes про разработку, и то, что не влезло в статьи. Подписывайся, если формат заходит.
Поехали
Первый настоящий пост уже в работе – про стоимость изменений и почему архитектура это в первую очередь экономика, а не техника.
А пока – привет, меня зовут Владимир, и я наконец-то начал писать. Давно пора было.