Мой рабочий день - это код. Вечером я хочу разговаривать с кем-то по-английски, а не нажимать на пингвинчиков.
Duolingo учит меня заказывать яблоки в магазине.
Memrise превратился в видеоплатформу с озвучкой.
ChatGPT-чат отлично объясняет грамматику, но не помнит, что я уже разбирал Present Perfect в среду и опять путаю его с Past Simple в пятницу.
Прежде чем погружаться в архитектуру, давайте посмотрим на контекст, в котором всё это происходит.
По данным исследования McKinsey 2022 года, технический долг составляет до 40% всего технологического портфеля компаний. И это не просто цифра в отчёте. Согласно опросу 2024 года среди технических руководителей, у более чем 50% компаний технический долг занимает свыше четверти всего IT-бюджета, блокируя внедрение новых функций. (Источник: vFunction, 2025)
У меня была привычка. Вижу классную статью про архитектуру — сохраняю. Репозиторий с примерами DDD — в закладки. Видео про CQRS — в плейлист «Посмотреть потом».
Вы знаете, чем кончаются плейлисты «Посмотреть потом».
В какой‑то момент закладок стало 300+. Половина ссылок битые, треть дублируют друг друга, остальное - статьи, которые казались гениальными в два часа ночи. Я сел и вычистил всё до 106 ресурсов. Собрал их в awesome-list на GitHub.
Но статья не про список. Статья про три вещи, которые я для себя открыл в процессе и которые почему-то мало обсуждают.
Привет! 👋
В этой статье я хочу поделиться опытом разработки пет-проекта, который превратился в полноценный инструмент для автоматической генерации коротких видео (Shorts, Reels, TikTok). Идея проста: на входе — тема (например, "История Римской Империи за 1 минуту"), на выходе — готовый видеоролик с озвучкой, субтитрами и сгенерированным видеорядом.
Но вместо того, чтобы накидать "спагетти-код" в одном файле main.py, я решил подойти к задаче как инженер и построить систему на принципах Clean Architecture.
🎯 Зачем?
Генерация видео — это сложный пайплайн:
1. Написать сценарий.
Последние 5 лет я изучаю и практикую DDD как стратегический, так и тактический, везде, где представляется возможным. И вот чем больше я погружался в тактическую часть - тем чаще возникал вопрос "это я дурак или лыжи не едут". Пришло понимание того, что огромнейшая часть сообщества структурирует код своего контекста забыв о самом главном:
Структура и язык кода должны соответствовать бизнес-домену
Привет! Сегодня хочу поделиться с тобой опытом перехода от Feature-Sliced Design к Clean Architecture во фронтенде. Почему я считаю Clean Architecture более подходящей для сложных приложений, и как она решает проблемы, с которыми ты точно сталкивался.
Если ты используешь FSD или до сих пор пишешь всю логику в компонентах React — эта статья точно для тебя.
Feature-Sliced Design сейчас одна из самых популярных методологий во фронтенде. И не зря — она действительно помогает структурировать код лучше, чем хаотичное размещение файлов.
Понятное разделение по фичам и слайсам
Хочу поделиться подходом, который родился у меня в процессе разработки нескольких проектов. Весь код доступен в репозитории (ссылка в конце статьи), а также опубликован в виде pub-пакета.
На сегодняшний день во флаттер разработке сформировались несколько подходов к State Management, такие, как MobX, Redux, Bloc и прочие. Они по-своему хороши, но описывают лишь часть архитектуры, нежели полноценный подход к построению приложения. В то же время у нас есть Clean Architecture, который можно применять в разработке практически любого проекта на любом языке и фреймворке.
В чем разница и когда что использовать? Это был один из вопросов, на которые я пытался получить ответ.
Попытаюсь тут описать ту практику, которую считаю не плохой. С примерами на PHP. Постараюсь описывать на простом языке - без использования сложной терминологии.
Лучше всего это два подхода понимаются в слоистой архитектуре(слой презентации, доменный, инфраструктураприложение - те, которые на текущий момент я использую в итоговом примере).
DTO - это объект класса необходим для передачи структурированнойЧитать полностью »
В Go-экосистеме сложилась парадоксальная ситуация: при наличии множества руководств по структуре проектов, разработчики продолжают сталкиваться с системными проблемами:
