#clean_architecture — Public Fediverse posts

Feature Based Clean Architecture. Часть 5: Масштабирование FBCA и теоретико-графовый анализ зависимостей

Если описать NestJS-архитектуру как граф — вершины это модули и классы, рёбра — зависимости между ними, — утверждение «архитектура не деградирует» перестаёт быть оценочным. Формально доказывается, при каких условиях циклы между модулями топологически невозможны, при каких размер публичного API не растёт с каждой новой ручкой, и при каких стоимость добавления фичи остаётся константой, а не растёт с числом существующих потребителей. Три измеримых структурных свойства, а не ощущение. Для типовой feature-based-структуры, которую сегодня продвигают как стандарт, ни одно из них не выполняется. Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна. Часть 5 — финал серии. Архитектурный подход, при котором эти три свойства соблюдаются (Feature-Based Clean Architecture), нагружается тем же сценарием годового роста, под весом которого деградирует обычный feature-based: партнёрка, анти-фрод, рефералки, расширенная аналитика, утроение модуля пользователей. Без художественности: реальный код, граф зависимостей «до» и «после», и формальное доказательство трёх свойств — DAG-инвариант, граница связности, O(1)-стоимость инкремента — на языке теории графов. Точка, в которой «архитектура не деградирует» становится не похвалой, а конкретным структурным утверждением.

https://habr.com/ru/articles/1038450/

#NestJS #TypeScript #Clean_Architecture #Архитектура_ПО #Бэкенд #Featurebased #Теория_графов #Масштабирование #DAG #DomainDriven_Design

Feature Based Clean Architecture. Часть 4: FBCA: формализация границ ответственности в NestJS-модуле

После трёх частей разбора деградации остаётся один вопрос: как написать NestJS-проект так, чтобы god-сервис и циклические зависимости были невозможны. «Писать аккуратнее», «лучше ревьюить», «выделять день в спринте на рефакторинг» — варианты, которые не работают: дисциплина не масштабируется на пятьдесят спринтов и пять команд. Работает другое — наложить на модуль структурные ограничения, которые TypeScript и NestJS DI просто не дадут нарушить. Слои, однонаправленные зависимости, изоляция домена от инфраструктуры — не папки ради порядка, а барьер, который физически не пропускает сценарии деградации из частей 1–3. Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна. Часть 4 — конкретная имплементация подхода на том же сквозном Twitter-подобном бэкенде. Как модуль режется на четыре слоя (domain / use-case / infrastructure / presentation), как раздутый сервис заменяется набором use-case’ов, куда уезжает работа с базой и почему оркестратор перестаёт быть god-функцией. Без художественности: реальный код, что именно изменилось по сравнению с feature-based-структурой из частей 1–3, и точка, в которой видно — прежние сценарии деградации теперь не запускаются не потому, что «все стали аккуратнее», а потому что нечем.

https://habr.com/ru/articles/1038438/

#NestJS #TypeScript #Clean_Architecture #Архитектура_ПО #Бэкенд #Featurebased #DomainDriven_Design #Слоистая_архитектура #Рефакторинг #SOLID

Технический гайд по сторис – часть 4: как мы добавили видео формат

Привет! Меня зовут Владислав Фальзан, я работаю android-разработчиком в М2. Наша команда мобильной разработки развивает приложение – онлайн-платформу для решения вопросов с недвижимостью. Основные пользователи приложения – физические лица (B2C) и риелторы (B2B2C). Эта статья – технический гайд для android-разработчиков о том, как реализовать видео сторис у себя в приложении или как использовать нашу библиотеку для работы с ними. Из статьи вы поймете: как запустить видео сторис в своем приложении, как работать с несколькими видео, как сделать из этого полноценный плагин, если вы хотите инкапсулировать логику в отдельном модуле и подключать ее только при необходимости, или как использовать нашу библиотеку для этих целей. Для удобства изучения статьи я решил разбить ее на блоки:

https://habr.com/ru/companies/m2tech/articles/1037398/

#android #ddd #compose #stories #mvvm #kotlin #coroutines #clean_architecture #room

Технический гайд по сторис – часть 4: как мы добавили видео формат

Привет! Меня зовут Владислав Фальзан, я работаю android-разработчиком в М2. Наша команда мобильной разработки развивает приложение – онлайн-платформу для решения вопросов с недвижимостью. Основные пользователи приложения – физические лица (B2C) и риелторы (B2B2C). Эта статья – технический гайд для android-разработчиков о том, как реализовать видео сторис у себя в приложении или как использовать нашу библиотеку для работы с ними. Из статьи вы поймете: как запустить видео сторис в своем приложении, как работать с несколькими видео, как сделать из этого полноценный плагин, если вы хотите инкапсулировать логику в отдельном модуле и подключать ее только при необходимости, или как использовать нашу библиотеку для этих целей. Для удобства изучения статьи я решил разбить ее на блоки:

https://habr.com/ru/companies/m2tech/articles/1037398/

#android #ddd #compose #stories #mvvm #kotlin #coroutines #clean_architecture #room

Технический гайд по сторис – часть 4: как мы добавили видео формат

Привет! Меня зовут Владислав Фальзан, я работаю android-разработчиком в М2. Наша команда мобильной разработки развивает приложение – онлайн-платформу для решения вопросов с недвижимостью. Основные пользователи приложения – физические лица (B2C) и риелторы (B2B2C). Эта статья – технический гайд для android-разработчиков о том, как реализовать видео сторис у себя в приложении или как использовать нашу библиотеку для работы с ними. Из статьи вы поймете: как запустить видео сторис в своем приложении, как работать с несколькими видео, как сделать из этого полноценный плагин, если вы хотите инкапсулировать логику в отдельном модуле и подключать ее только при необходимости, или как использовать нашу библиотеку для этих целей. Для удобства изучения статьи я решил разбить ее на блоки:

https://habr.com/ru/companies/m2tech/articles/1037398/

#android #ddd #compose #stories #mvvm #kotlin #coroutines #clean_architecture #room

Технический гайд по сторис – часть 4: как мы добавили видео формат

Привет! Меня зовут Владислав Фальзан, я работаю android-разработчиком в М2. Наша команда мобильной разработки развивает приложение – онлайн-платформу для решения вопросов с недвижимостью. Основные пользователи приложения – физические лица (B2C) и риелторы (B2B2C). Эта статья – технический гайд для android-разработчиков о том, как реализовать видео сторис у себя в приложении или как использовать нашу библиотеку для работы с ними. Из статьи вы поймете: как запустить видео сторис в своем приложении, как работать с несколькими видео, как сделать из этого полноценный плагин, если вы хотите инкапсулировать логику в отдельном модуле и подключать ее только при необходимости, или как использовать нашу библиотеку для этих целей. Для удобства изучения статьи я решил разбить ее на блоки:

https://habr.com/ru/companies/m2tech/articles/1037398/

#android #ddd #compose #stories #mvvm #kotlin #coroutines #clean_architecture #room

Почему проекты превращаются в спагетти даже у хороших программистов

Когда программист впервые слышит слово «архитектура», он обычно представляет что-то скучное: диаграммы, стрелочки, коробочки, совещания на три часа и человека, который запрещает писать код. А потом проходит несколько лет. И внезапно оказывается, что проект, который «быстро накидали», начинает разваливаться от любого изменения. Добавили одну кнопку — сломался импорт. Поменяли отчёт — умерла авторизация. Обновили библиотеку — перестала открываться половина форм. И начинается археология. Почему так происходит? Потому что почти любой проект без нормальной архитектуры рано или поздно превращается в спагетти. Причём даже если его пишут хорошие программисты.

https://habr.com/ru/articles/1035696/

#архитектура_по #модульный_монолит #микросервисы #clean_architecture #legacy #спагеттикод #инженерия #backend #software_architecture #dependency_injection

Почему проекты превращаются в спагетти даже у хороших программистов

Когда программист впервые слышит слово «архитектура», он обычно представляет что-то скучное: диаграммы, стрелочки, коробочки, совещания на три часа и человека, который запрещает писать код. А потом проходит несколько лет. И внезапно оказывается, что проект, который «быстро накидали», начинает разваливаться от любого изменения. Добавили одну кнопку — сломался импорт. Поменяли отчёт — умерла авторизация. Обновили библиотеку — перестала открываться половина форм. И начинается археология. Почему так происходит? Потому что почти любой проект без нормальной архитектуры рано или поздно превращается в спагетти. Причём даже если его пишут хорошие программисты.

https://habr.com/ru/articles/1035696/

#архитектура_по #модульный_монолит #микросервисы #clean_architecture #legacy #спагеттикод #инженерия #backend #software_architecture #dependency_injection

Почему проекты превращаются в спагетти даже у хороших программистов

Когда программист впервые слышит слово «архитектура», он обычно представляет что-то скучное: диаграммы, стрелочки, коробочки, совещания на три часа и человека, который запрещает писать код. А потом проходит несколько лет. И внезапно оказывается, что проект, который «быстро накидали», начинает разваливаться от любого изменения. Добавили одну кнопку — сломался импорт. Поменяли отчёт — умерла авторизация. Обновили библиотеку — перестала открываться половина форм. И начинается археология. Почему так происходит? Потому что почти любой проект без нормальной архитектуры рано или поздно превращается в спагетти. Причём даже если его пишут хорошие программисты.

https://habr.com/ru/articles/1035696/

#архитектура_по #модульный_монолит #микросервисы #clean_architecture #legacy #спагеттикод #инженерия #backend #software_architecture #dependency_injection

Почему проекты превращаются в спагетти даже у хороших программистов

Когда программист впервые слышит слово «архитектура», он обычно представляет что-то скучное: диаграммы, стрелочки, коробочки, совещания на три часа и человека, который запрещает писать код. А потом проходит несколько лет. И внезапно оказывается, что проект, который «быстро накидали», начинает разваливаться от любого изменения. Добавили одну кнопку — сломался импорт. Поменяли отчёт — умерла авторизация. Обновили библиотеку — перестала открываться половина форм. И начинается археология. Почему так происходит? Потому что почти любой проект без нормальной архитектуры рано или поздно превращается в спагетти. Причём даже если его пишут хорошие программисты.

https://habr.com/ru/articles/1035696/

#архитектура_по #модульный_монолит #микросервисы #clean_architecture #legacy #спагеттикод #инженерия #backend #software_architecture #dependency_injection

Чистая архитектура на практике: перестаём ломать сервис при каждом релизе

У вас небольшой релиз. Вы меняете пару строк кода, выкатываете обновление - и через несколько минут сервис начинает отдавать странные ошибки. Баги появляются в местах, которые вы вообще не трогали. Знакомо? Обычно проблема не в конкретном изменении, а в архитектурной связанности системы: инфраструктурные детали начинают протекать в бизнес-логику, и зависимости между компонентами становятся слишком плотными. Разберём это на примерах. Примеры будут псевдореальные, иначе статья быстро превратится в книгу. Посмотрите на функцию загрузки инвойса:

https://habr.com/ru/articles/1034758/

#clean_architecture #clean_code #architecture #программирование #проектирование_систем #шаблоны_проектирования #ооп #hexagonal_architecture #grasp #solid

Чистая архитектура на практике: перестаём ломать сервис при каждом релизе

У вас небольшой релиз. Вы меняете пару строк кода, выкатываете обновление - и через несколько минут сервис начинает отдавать странные ошибки. Баги появляются в местах, которые вы вообще не трогали. Знакомо? Обычно проблема не в конкретном изменении, а в архитектурной связанности системы: инфраструктурные детали начинают протекать в бизнес-логику, и зависимости между компонентами становятся слишком плотными. Разберём это на примерах. Примеры будут псевдореальные, иначе статья быстро превратится в книгу. Посмотрите на функцию загрузки инвойса:

https://habr.com/ru/articles/1034758/

#clean_architecture #clean_code #architecture #программирование #проектирование_систем #шаблоны_проектирования #ооп #hexagonal_architecture #grasp #solid

Чистая архитектура на практике: перестаём ломать сервис при каждом релизе

У вас небольшой релиз. Вы меняете пару строк кода, выкатываете обновление - и через несколько минут сервис начинает отдавать странные ошибки. Баги появляются в местах, которые вы вообще не трогали. Знакомо? Обычно проблема не в конкретном изменении, а в архитектурной связанности системы: инфраструктурные детали начинают протекать в бизнес-логику, и зависимости между компонентами становятся слишком плотными. Разберём это на примерах. Примеры будут псевдореальные, иначе статья быстро превратится в книгу. Посмотрите на функцию загрузки инвойса:

https://habr.com/ru/articles/1034758/

#clean_architecture #clean_code #architecture #программирование #проектирование_систем #шаблоны_проектирования #ооп #hexagonal_architecture #grasp #solid

Чистая архитектура на практике: перестаём ломать сервис при каждом релизе

У вас небольшой релиз. Вы меняете пару строк кода, выкатываете обновление - и через несколько минут сервис начинает отдавать странные ошибки. Баги появляются в местах, которые вы вообще не трогали. Знакомо? Обычно проблема не в конкретном изменении, а в архитектурной связанности системы: инфраструктурные детали начинают протекать в бизнес-логику, и зависимости между компонентами становятся слишком плотными. Разберём это на примерах. Примеры будут псевдореальные, иначе статья быстро превратится в книгу. Посмотрите на функцию загрузки инвойса:

https://habr.com/ru/articles/1034758/

#clean_architecture #clean_code #architecture #программирование #проектирование_систем #шаблоны_проектирования #ооп #hexagonal_architecture #grasp #solid

Почему spec-driven development плохо работает на микросервисах: часть 1. Где теряется контекст

Я работаю в большой продуктовой компании с тысячей микросервисов. В такой системе даже небольшая фича часто проходит через несколько сервисов, событий и внутренних контрактов. Spec-driven development с LLM уже применяется в некоторых командах для планирования и ревью фич, поэтому мне было важно понять, где этот подход помогает, а где начинает ошибаться. Пока задача живёт внутри одного сервиса, всё обычно идёт быстро: спека короткая, описание и реализация помещаются в контекст модели. Но как только фича проходит через несколько сервисов, начинаются проблемы. По отдельности каждый кусок выглядит нормально: разбиение на слои, именование по код стайлу, прохождение тестов и ревью. Но в целом система не работает должным образом. Типичные ошибки: нет идемпотентности, LLM упускает сценарии и edge case-ы, появляются циклические вызовы сервисов. Чем больше делаешь правок, тем больше ошибок она допускает. Для эксперимента я собрал отдельный стенд: Go-проект - платформа для поиска фрилансеров . Внутри 12 микросервисов, связанных через gRPC и брокер сообщений; в этом проекте брокером выступает NATS. Одни сервисы хранят задачи и профили исполнителей, другие подбирают кандидатов, считают расстояния, проверяют портфолио и отправляют уведомления. Проект специально спроектирован с шестью категориями архитектурных ловушек: они проявляются не внутри одного сервиса, а на границах между сервисами. Фича для эксперимента была такой: если выбранный фрилансер отказался от оффера, платформа должна автоматически найти следующего подходящего кандидата, отправить ему новый оффер и уведомить заказчика о переназначении. Claude написал спеку, реализацию и юнит-тесты, но полный сценарий отказа и переназначения не сошёлся. Два независимых ревью нашли одну и ту же группу ошибок: по отдельности сервисы выглядели нормально, а вместе работали не так, как нужно. На это можно ответить, что нужен end-to-end тест на весь сценарий, но это не закрывает проблему целиком. End-to-end тесты есть не везде, их дорого поддерживать, и они не покрывают все развилки: особенно редкие edge case-ы, дубликаты событий, гонки и редкие комбинации условий. Главное же в другом: на этапе spec-driven разработки модель должна помочь собрать требования, ограничения и контекст, а именно там она часто ошибается. Разработчик тоже не всегда заранее знает, где спрятана проблема. Он может помнить про Outbox, дедупликацию уведомлений или особые требования конкретного сервиса к входным данным, но не сформулировать это как ограничение для новой фичи. LLM читает документы по сервисам, задаёт уточняющие вопросы и всё равно может пропустить связь между ними. В итоге спека получается подробной, но неполной: в ней есть локальные изменения по сервисам, зато нет системных инвариантов, которые живут между сервисами. Реализация может быть нормально разложена по слоям, тесты отдельных компонентов проходят, а ошибка обнаруживается уже на уровне сценария или ревью. Где LLM теряет контекст

https://habr.com/ru/articles/1033510/

#claude_code #specdriven_development #microservices #system_design #llm #архитектура #code_review #go #clean_architecture

Почему spec-driven development плохо работает на микросервисах: часть 1. Где теряется контекст

Я работаю в большой продуктовой компании с тысячей микросервисов. В такой системе даже небольшая фича часто проходит через несколько сервисов, событий и внутренних контрактов. Spec-driven development с LLM уже применяется в некоторых командах для планирования и ревью фич, поэтому мне было важно понять, где этот подход помогает, а где начинает ошибаться. Пока задача живёт внутри одного сервиса, всё обычно идёт быстро: спека короткая, описание и реализация помещаются в контекст модели. Но как только фича проходит через несколько сервисов, начинаются проблемы. По отдельности каждый кусок выглядит нормально: разбиение на слои, именование по код стайлу, прохождение тестов и ревью. Но в целом система не работает должным образом. Типичные ошибки: нет идемпотентности, LLM упускает сценарии и edge case-ы, появляются циклические вызовы сервисов. Чем больше делаешь правок, тем больше ошибок она допускает. Для эксперимента я собрал отдельный стенд: Go-проект - платформа для поиска фрилансеров . Внутри 12 микросервисов, связанных через gRPC и брокер сообщений; в этом проекте брокером выступает NATS. Одни сервисы хранят задачи и профили исполнителей, другие подбирают кандидатов, считают расстояния, проверяют портфолио и отправляют уведомления. Проект специально спроектирован с шестью категориями архитектурных ловушек: они проявляются не внутри одного сервиса, а на границах между сервисами. Фича для эксперимента была такой: если выбранный фрилансер отказался от оффера, платформа должна автоматически найти следующего подходящего кандидата, отправить ему новый оффер и уведомить заказчика о переназначении. Claude написал спеку, реализацию и юнит-тесты, но полный сценарий отказа и переназначения не сошёлся. Два независимых ревью нашли одну и ту же группу ошибок: по отдельности сервисы выглядели нормально, а вместе работали не так, как нужно. На это можно ответить, что нужен end-to-end тест на весь сценарий, но это не закрывает проблему целиком. End-to-end тесты есть не везде, их дорого поддерживать, и они не покрывают все развилки: особенно редкие edge case-ы, дубликаты событий, гонки и редкие комбинации условий. Главное же в другом: на этапе spec-driven разработки модель должна помочь собрать требования, ограничения и контекст, а именно там она часто ошибается. Разработчик тоже не всегда заранее знает, где спрятана проблема. Он может помнить про Outbox, дедупликацию уведомлений или особые требования конкретного сервиса к входным данным, но не сформулировать это как ограничение для новой фичи. LLM читает документы по сервисам, задаёт уточняющие вопросы и всё равно может пропустить связь между ними. В итоге спека получается подробной, но неполной: в ней есть локальные изменения по сервисам, зато нет системных инвариантов, которые живут между сервисами. Реализация может быть нормально разложена по слоям, тесты отдельных компонентов проходят, а ошибка обнаруживается уже на уровне сценария или ревью. Где LLM теряет контекст

https://habr.com/ru/articles/1033510/

#claude_code #specdriven_development #microservices #system_design #llm #архитектура #code_review #go #clean_architecture

Почему spec-driven development плохо работает на микросервисах: часть 1. Где теряется контекст

Я работаю в большой продуктовой компании с тысячей микросервисов. В такой системе даже небольшая фича часто проходит через несколько сервисов, событий и внутренних контрактов. Spec-driven development с LLM уже применяется в некоторых командах для планирования и ревью фич, поэтому мне было важно понять, где этот подход помогает, а где начинает ошибаться. Пока задача живёт внутри одного сервиса, всё обычно идёт быстро: спека короткая, описание и реализация помещаются в контекст модели. Но как только фича проходит через несколько сервисов, начинаются проблемы. По отдельности каждый кусок выглядит нормально: разбиение на слои, именование по код стайлу, прохождение тестов и ревью. Но в целом система не работает должным образом. Типичные ошибки: нет идемпотентности, LLM упускает сценарии и edge case-ы, появляются циклические вызовы сервисов. Чем больше делаешь правок, тем больше ошибок она допускает. Для эксперимента я собрал отдельный стенд: Go-проект - платформа для поиска фрилансеров . Внутри 12 микросервисов, связанных через gRPC и брокер сообщений; в этом проекте брокером выступает NATS. Одни сервисы хранят задачи и профили исполнителей, другие подбирают кандидатов, считают расстояния, проверяют портфолио и отправляют уведомления. Проект специально спроектирован с шестью категориями архитектурных ловушек: они проявляются не внутри одного сервиса, а на границах между сервисами. Фича для эксперимента была такой: если выбранный фрилансер отказался от оффера, платформа должна автоматически найти следующего подходящего кандидата, отправить ему новый оффер и уведомить заказчика о переназначении. Claude написал спеку, реализацию и юнит-тесты, но полный сценарий отказа и переназначения не сошёлся. Два независимых ревью нашли одну и ту же группу ошибок: по отдельности сервисы выглядели нормально, а вместе работали не так, как нужно. На это можно ответить, что нужен end-to-end тест на весь сценарий, но это не закрывает проблему целиком. End-to-end тесты есть не везде, их дорого поддерживать, и они не покрывают все развилки: особенно редкие edge case-ы, дубликаты событий, гонки и редкие комбинации условий. Главное же в другом: на этапе spec-driven разработки модель должна помочь собрать требования, ограничения и контекст, а именно там она часто ошибается. Разработчик тоже не всегда заранее знает, где спрятана проблема. Он может помнить про Outbox, дедупликацию уведомлений или особые требования конкретного сервиса к входным данным, но не сформулировать это как ограничение для новой фичи. LLM читает документы по сервисам, задаёт уточняющие вопросы и всё равно может пропустить связь между ними. В итоге спека получается подробной, но неполной: в ней есть локальные изменения по сервисам, зато нет системных инвариантов, которые живут между сервисами. Реализация может быть нормально разложена по слоям, тесты отдельных компонентов проходят, а ошибка обнаруживается уже на уровне сценария или ревью. Где LLM теряет контекст

https://habr.com/ru/articles/1033510/

#claude_code #specdriven_development #microservices #system_design #llm #архитектура #code_review #go #clean_architecture

Почему spec-driven development плохо работает на микросервисах: часть 1. Где теряется контекст

Я работаю в большой продуктовой компании с тысячей микросервисов. В такой системе даже небольшая фича часто проходит через несколько сервисов, событий и внутренних контрактов. Spec-driven development с LLM уже применяется в некоторых командах для планирования и ревью фич, поэтому мне было важно понять, где этот подход помогает, а где начинает ошибаться. Пока задача живёт внутри одного сервиса, всё обычно идёт быстро: спека короткая, описание и реализация помещаются в контекст модели. Но как только фича проходит через несколько сервисов, начинаются проблемы. По отдельности каждый кусок выглядит нормально: разбиение на слои, именование по код стайлу, прохождение тестов и ревью. Но в целом система не работает должным образом. Типичные ошибки: нет идемпотентности, LLM упускает сценарии и edge case-ы, появляются циклические вызовы сервисов. Чем больше делаешь правок, тем больше ошибок она допускает. Для эксперимента я собрал отдельный стенд: Go-проект - платформа для поиска фрилансеров . Внутри 12 микросервисов, связанных через gRPC и брокер сообщений; в этом проекте брокером выступает NATS. Одни сервисы хранят задачи и профили исполнителей, другие подбирают кандидатов, считают расстояния, проверяют портфолио и отправляют уведомления. Проект специально спроектирован с шестью категориями архитектурных ловушек: они проявляются не внутри одного сервиса, а на границах между сервисами. Фича для эксперимента была такой: если выбранный фрилансер отказался от оффера, платформа должна автоматически найти следующего подходящего кандидата, отправить ему новый оффер и уведомить заказчика о переназначении. Claude написал спеку, реализацию и юнит-тесты, но полный сценарий отказа и переназначения не сошёлся. Два независимых ревью нашли одну и ту же группу ошибок: по отдельности сервисы выглядели нормально, а вместе работали не так, как нужно. На это можно ответить, что нужен end-to-end тест на весь сценарий, но это не закрывает проблему целиком. End-to-end тесты есть не везде, их дорого поддерживать, и они не покрывают все развилки: особенно редкие edge case-ы, дубликаты событий, гонки и редкие комбинации условий. Главное же в другом: на этапе spec-driven разработки модель должна помочь собрать требования, ограничения и контекст, а именно там она часто ошибается. Разработчик тоже не всегда заранее знает, где спрятана проблема. Он может помнить про Outbox, дедупликацию уведомлений или особые требования конкретного сервиса к входным данным, но не сформулировать это как ограничение для новой фичи. LLM читает документы по сервисам, задаёт уточняющие вопросы и всё равно может пропустить связь между ними. В итоге спека получается подробной, но неполной: в ней есть локальные изменения по сервисам, зато нет системных инвариантов, которые живут между сервисами. Реализация может быть нормально разложена по слоям, тесты отдельных компонентов проходят, а ошибка обнаруживается уже на уровне сценария или ревью. Где LLM теряет контекст

https://habr.com/ru/articles/1033510/

#claude_code #specdriven_development #microservices #system_design #llm #архитектура #code_review #go #clean_architecture

Я устал от Duolingo и написал себе AI-репетитора. Go, Clean Architecture, 4 LLM-модели — и вот что из этого вышло

Мой рабочий день - это код. Вечером я хочу разговаривать с кем-то по-английски, а не нажимать на пингвинчиков. Duolingo учит меня заказывать яблоки, ChatGPT-чат отлично объясняет грамматику - но не помнит, что я разбирал Present Perfect в среду и опять путаю его с Past Simple в пятницу. Я хотел простую штуку: написать модели «давай сегодня про багтрекеры»; получить чат на 15 минут; а в конце - три новых слова , которые она же мне и подобрала по уровню B1. Чтобы завтра эти слова всплыли в упражнениях. Через месяц получился Lexis : Go · Clean Architecture · 4 LLM-модели · SSE-стриминг · JWT rotation + reuse detection MIT, открытый репозиторий. В статье - три инженерных якоря , которыми я доволен: Pluggable AI-провайдеры через интерфейс из трёх методов. SSE вместо WebSocket для стриминга AI-ответов. JWT rotation + reuse detection как production-ready стандарт, а не «потом перепишем». Плюс честный список того, что ещё не готово. Показать архитектуру

https://habr.com/ru/articles/1030928/

#Go #Clean_Architecture #JWT #AI #LLM #petproject #изучение_английского #SSE #modular_monolith #refresh_tokens

Я устал от Duolingo и написал себе AI-репетитора. Go, Clean Architecture, 4 LLM-модели — и вот что из этого вышло

Мой рабочий день - это код. Вечером я хочу разговаривать с кем-то по-английски, а не нажимать на пингвинчиков. Duolingo учит меня заказывать яблоки, ChatGPT-чат отлично объясняет грамматику - но не помнит, что я разбирал Present Perfect в среду и опять путаю его с Past Simple в пятницу. Я хотел простую штуку: написать модели «давай сегодня про багтрекеры»; получить чат на 15 минут; а в конце - три новых слова , которые она же мне и подобрала по уровню B1. Чтобы завтра эти слова всплыли в упражнениях. Через месяц получился Lexis : Go · Clean Architecture · 4 LLM-модели · SSE-стриминг · JWT rotation + reuse detection MIT, открытый репозиторий. В статье - три инженерных якоря , которыми я доволен: Pluggable AI-провайдеры через интерфейс из трёх методов. SSE вместо WebSocket для стриминга AI-ответов. JWT rotation + reuse detection как production-ready стандарт, а не «потом перепишем». Плюс честный список того, что ещё не готово. Показать архитектуру

https://habr.com/ru/articles/1030928/

#Go #Clean_Architecture #JWT #AI #LLM #petproject #изучение_английского #SSE #modular_monolith #refresh_tokens

Я устал от Duolingo и написал себе AI-репетитора. Go, Clean Architecture, 4 LLM-модели — и вот что из этого вышло

Мой рабочий день - это код. Вечером я хочу разговаривать с кем-то по-английски, а не нажимать на пингвинчиков. Duolingo учит меня заказывать яблоки, ChatGPT-чат отлично объясняет грамматику - но не помнит, что я разбирал Present Perfect в среду и опять путаю его с Past Simple в пятницу. Я хотел простую штуку: написать модели «давай сегодня про багтрекеры»; получить чат на 15 минут; а в конце - три новых слова , которые она же мне и подобрала по уровню B1. Чтобы завтра эти слова всплыли в упражнениях. Через месяц получился Lexis : Go · Clean Architecture · 4 LLM-модели · SSE-стриминг · JWT rotation + reuse detection MIT, открытый репозиторий. В статье - три инженерных якоря , которыми я доволен: Pluggable AI-провайдеры через интерфейс из трёх методов. SSE вместо WebSocket для стриминга AI-ответов. JWT rotation + reuse detection как production-ready стандарт, а не «потом перепишем». Плюс честный список того, что ещё не готово. Показать архитектуру

https://habr.com/ru/articles/1030928/

#Go #Clean_Architecture #JWT #AI #LLM #petproject #изучение_английского #SSE #modular_monolith #refresh_tokens

Я устал от Duolingo и написал себе AI-репетитора. Go, Clean Architecture, 4 LLM-модели — и вот что из этого вышло

Мой рабочий день - это код. Вечером я хочу разговаривать с кем-то по-английски, а не нажимать на пингвинчиков. Duolingo учит меня заказывать яблоки, ChatGPT-чат отлично объясняет грамматику - но не помнит, что я разбирал Present Perfect в среду и опять путаю его с Past Simple в пятницу. Я хотел простую штуку: написать модели «давай сегодня про багтрекеры»; получить чат на 15 минут; а в конце - три новых слова , которые она же мне и подобрала по уровню B1. Чтобы завтра эти слова всплыли в упражнениях. Через месяц получился Lexis : Go · Clean Architecture · 4 LLM-модели · SSE-стриминг · JWT rotation + reuse detection MIT, открытый репозиторий. В статье - три инженерных якоря , которыми я доволен: Pluggable AI-провайдеры через интерфейс из трёх методов. SSE вместо WebSocket для стриминга AI-ответов. JWT rotation + reuse detection как production-ready стандарт, а не «потом перепишем». Плюс честный список того, что ещё не готово. Показать архитектуру

https://habr.com/ru/articles/1030928/

#Go #Clean_Architecture #JWT #AI #LLM #petproject #изучение_английского #SSE #modular_monolith #refresh_tokens

Коллаборация человека и ИИ в Kotlin‑разработке: скрытые практики эффективных команд

ИИ-агенты пишут код быстрее человека, но кто поручится, что они не устроят cascading failure? Разберем, как в реальном проекте совместить инженерный опыт, архитектурные шаблоны и автономных агентов, чтобы получить работающий функциональный узел, а не груду классов-переростков. Вы увидите подготовку фундамента, декомпозицию задач, диаграммы и тот самый момент, когда ИИ нужно жёстко одёрнуть.

https://habr.com/ru/companies/otus/articles/1022118/

#kotlin #backendразработка #архитектура #aiагенты #agentoriented_programming #микросервисы #clean_architecture #идемпотентность #асинхронные_процессы #kotlin_ktor

Коллаборация человека и ИИ в Kotlin‑разработке: скрытые практики эффективных команд

ИИ-агенты пишут код быстрее человека, но кто поручится, что они не устроят cascading failure? Разберем, как в реальном проекте совместить инженерный опыт, архитектурные шаблоны и автономных агентов, чтобы получить работающий функциональный узел, а не груду классов-переростков. Вы увидите подготовку фундамента, декомпозицию задач, диаграммы и тот самый момент, когда ИИ нужно жёстко одёрнуть.

https://habr.com/ru/companies/otus/articles/1022118/

#kotlin #backendразработка #архитектура #aiагенты #agentoriented_programming #микросервисы #clean_architecture #идемпотентность #асинхронные_процессы #kotlin_ktor

Коллаборация человека и ИИ в Kotlin‑разработке: скрытые практики эффективных команд

ИИ-агенты пишут код быстрее человека, но кто поручится, что они не устроят cascading failure? Разберем, как в реальном проекте совместить инженерный опыт, архитектурные шаблоны и автономных агентов, чтобы получить работающий функциональный узел, а не груду классов-переростков. Вы увидите подготовку фундамента, декомпозицию задач, диаграммы и тот самый момент, когда ИИ нужно жёстко одёрнуть.

https://habr.com/ru/companies/otus/articles/1022118/

#kotlin #backendразработка #архитектура #aiагенты #agentoriented_programming #микросервисы #clean_architecture #идемпотентность #асинхронные_процессы #kotlin_ktor

Коллаборация человека и ИИ в Kotlin‑разработке: скрытые практики эффективных команд

ИИ-агенты пишут код быстрее человека, но кто поручится, что они не устроят cascading failure? Разберем, как в реальном проекте совместить инженерный опыт, архитектурные шаблоны и автономных агентов, чтобы получить работающий функциональный узел, а не груду классов-переростков. Вы увидите подготовку фундамента, декомпозицию задач, диаграммы и тот самый момент, когда ИИ нужно жёстко одёрнуть.

https://habr.com/ru/companies/otus/articles/1022118/

#kotlin #backendразработка #архитектура #aiагенты #agentoriented_programming #микросервисы #clean_architecture #идемпотентность #асинхронные_процессы #kotlin_ktor

Clean Architecture + DDD в Go: как не превратить проект в 200 файлов ни о чём

Прежде чем погружаться в архитектуру, давайте посмотрим на контекст, в котором всё это происходит. По данным исследования McKinsey 2022 года, технический долг составляет до 40% всего технологического портфеля компаний. И это не просто цифра в отчёте. Согласно опросу 2024 года среди технических руководителей, у более чем 50% компаний технический долг занимает свыше четверти всего IT-бюджета, блокируя внедрение новых функций. (Источник: vFunction, 2025 ) При этом исследование Carnegie Mellon выяснило, что наибольшим источником технического долга являются именно архитектурные проблемы — а не баги и не плохой код на уровне функций. Теперь о Go. По данным Go Developer Survey 2024, главной проблемой команд, работающих с Go, названо поддержание единых стандартов кода — в том числе из-за разного уровня опыта участников и привнесения не-идиоматических паттернов из других языков. (Источник: go.dev/blog/survey2024-h2-results ) Это напрямую про нашу тему: люди приходят из Java, Python, C# и приносят с собой архитектурные привычки, которые в Go не работают. Clean Architecture и DDD — не исключение. Их часто реализуют "как в Java", а потом жалуются, что Go — многословный и неудобный язык. Давайте разберёмся, как делать это правильно. Как мы сюда попали? Представьте: вы начинаете новый Go‑сервис. Читаете статьи, смотрите видео, решаете «делать по‑взрослому». Создаёте структуру:

https://habr.com/ru/articles/1025068/

#go #архитектура #DDD #clean_architecture #backend #паттерн #паттерны_проектирования

Clean Architecture + DDD в Go: как не превратить проект в 200 файлов ни о чём

Прежде чем погружаться в архитектуру, давайте посмотрим на контекст, в котором всё это происходит. По данным исследования McKinsey 2022 года, технический долг составляет до 40% всего технологического портфеля компаний. И это не просто цифра в отчёте. Согласно опросу 2024 года среди технических руководителей, у более чем 50% компаний технический долг занимает свыше четверти всего IT-бюджета, блокируя внедрение новых функций. (Источник: vFunction, 2025 ) При этом исследование Carnegie Mellon выяснило, что наибольшим источником технического долга являются именно архитектурные проблемы — а не баги и не плохой код на уровне функций. Теперь о Go. По данным Go Developer Survey 2024, главной проблемой команд, работающих с Go, названо поддержание единых стандартов кода — в том числе из-за разного уровня опыта участников и привнесения не-идиоматических паттернов из других языков. (Источник: go.dev/blog/survey2024-h2-results ) Это напрямую про нашу тему: люди приходят из Java, Python, C# и приносят с собой архитектурные привычки, которые в Go не работают. Clean Architecture и DDD — не исключение. Их часто реализуют "как в Java", а потом жалуются, что Go — многословный и неудобный язык. Давайте разберёмся, как делать это правильно. Как мы сюда попали? Представьте: вы начинаете новый Go‑сервис. Читаете статьи, смотрите видео, решаете «делать по‑взрослому». Создаёте структуру:

https://habr.com/ru/articles/1025068/

#go #архитектура #DDD #clean_architecture #backend #паттерн #паттерны_проектирования

Clean Architecture + DDD в Go: как не превратить проект в 200 файлов ни о чём

Прежде чем погружаться в архитектуру, давайте посмотрим на контекст, в котором всё это происходит. По данным исследования McKinsey 2022 года, технический долг составляет до 40% всего технологического портфеля компаний. И это не просто цифра в отчёте. Согласно опросу 2024 года среди технических руководителей, у более чем 50% компаний технический долг занимает свыше четверти всего IT-бюджета, блокируя внедрение новых функций. (Источник: vFunction, 2025 ) При этом исследование Carnegie Mellon выяснило, что наибольшим источником технического долга являются именно архитектурные проблемы — а не баги и не плохой код на уровне функций. Теперь о Go. По данным Go Developer Survey 2024, главной проблемой команд, работающих с Go, названо поддержание единых стандартов кода — в том числе из-за разного уровня опыта участников и привнесения не-идиоматических паттернов из других языков. (Источник: go.dev/blog/survey2024-h2-results ) Это напрямую про нашу тему: люди приходят из Java, Python, C# и приносят с собой архитектурные привычки, которые в Go не работают. Clean Architecture и DDD — не исключение. Их часто реализуют "как в Java", а потом жалуются, что Go — многословный и неудобный язык. Давайте разберёмся, как делать это правильно. Как мы сюда попали? Представьте: вы начинаете новый Go‑сервис. Читаете статьи, смотрите видео, решаете «делать по‑взрослому». Создаёте структуру:

https://habr.com/ru/articles/1025068/

#go #архитектура #DDD #clean_architecture #backend #паттерн #паттерны_проектирования

Clean Architecture + DDD в Go: как не превратить проект в 200 файлов ни о чём

Прежде чем погружаться в архитектуру, давайте посмотрим на контекст, в котором всё это происходит. По данным исследования McKinsey 2022 года, технический долг составляет до 40% всего технологического портфеля компаний. И это не просто цифра в отчёте. Согласно опросу 2024 года среди технических руководителей, у более чем 50% компаний технический долг занимает свыше четверти всего IT-бюджета, блокируя внедрение новых функций. (Источник: vFunction, 2025 ) При этом исследование Carnegie Mellon выяснило, что наибольшим источником технического долга являются именно архитектурные проблемы — а не баги и не плохой код на уровне функций. Теперь о Go. По данным Go Developer Survey 2024, главной проблемой команд, работающих с Go, названо поддержание единых стандартов кода — в том числе из-за разного уровня опыта участников и привнесения не-идиоматических паттернов из других языков. (Источник: go.dev/blog/survey2024-h2-results ) Это напрямую про нашу тему: люди приходят из Java, Python, C# и приносят с собой архитектурные привычки, которые в Go не работают. Clean Architecture и DDD — не исключение. Их часто реализуют "как в Java", а потом жалуются, что Go — многословный и неудобный язык. Давайте разберёмся, как делать это правильно. Как мы сюда попали? Представьте: вы начинаете новый Go‑сервис. Читаете статьи, смотрите видео, решаете «делать по‑взрослому». Создаёте структуру:

https://habr.com/ru/articles/1025068/

#go #архитектура #DDD #clean_architecture #backend #паттерн #паттерны_проектирования

3 архитектурные ошибки в C#, из-за которых проект становится неуправляемым

Когда проект молодой, писать «всё в одном классе» кажется быстрее. Создать отдельный интерфейс, вынести слой — это же лишняя минута! Но эта минута потом стоит часов: код невозможно покрыть тестами, замена ORM превращается в переписывание бизнес-логики, а новый человек в команде тратит день только на то, чтобы понять, где в методе заканчивается выборка из базы и начинается бизнес-правило. Эти антипаттерны не привязаны к версии фреймворка — они встречаются и в legacy на .NET Framework, и в современных проектах на .NET 8. Покажу три конкретных примера из реальных проектов — и как их исправить.

https://habr.com/ru/articles/1012004/

#c# #net_core #clean_architecture #антипаттерны #рефакторинг

3 архитектурные ошибки в C#, из-за которых проект становится неуправляемым

Когда проект молодой, писать «всё в одном классе» кажется быстрее. Создать отдельный интерфейс, вынести слой — это же лишняя минута! Но эта минута потом стоит часов: код невозможно покрыть тестами, замена ORM превращается в переписывание бизнес-логики, а новый человек в команде тратит день только на то, чтобы понять, где в методе заканчивается выборка из базы и начинается бизнес-правило. Эти антипаттерны не привязаны к версии фреймворка — они встречаются и в legacy на .NET Framework, и в современных проектах на .NET 8. Покажу три конкретных примера из реальных проектов — и как их исправить.

https://habr.com/ru/articles/1012004/

#c# #net_core #clean_architecture #антипаттерны #рефакторинг

3 архитектурные ошибки в C#, из-за которых проект становится неуправляемым

Когда проект молодой, писать «всё в одном классе» кажется быстрее. Создать отдельный интерфейс, вынести слой — это же лишняя минута! Но эта минута потом стоит часов: код невозможно покрыть тестами, замена ORM превращается в переписывание бизнес-логики, а новый человек в команде тратит день только на то, чтобы понять, где в методе заканчивается выборка из базы и начинается бизнес-правило. Эти антипаттерны не привязаны к версии фреймворка — они встречаются и в legacy на .NET Framework, и в современных проектах на .NET 8. Покажу три конкретных примера из реальных проектов — и как их исправить.

https://habr.com/ru/articles/1012004/

#c# #net_core #clean_architecture #антипаттерны #рефакторинг

3 архитектурные ошибки в C#, из-за которых проект становится неуправляемым

Когда проект молодой, писать «всё в одном классе» кажется быстрее. Создать отдельный интерфейс, вынести слой — это же лишняя минута! Но эта минута потом стоит часов: код невозможно покрыть тестами, замена ORM превращается в переписывание бизнес-логики, а новый человек в команде тратит день только на то, чтобы понять, где в методе заканчивается выборка из базы и начинается бизнес-правило. Эти антипаттерны не привязаны к версии фреймворка — они встречаются и в legacy на .NET Framework, и в современных проектах на .NET 8. Покажу три конкретных примера из реальных проектов — и как их исправить.

https://habr.com/ru/articles/1012004/

#c# #net_core #clean_architecture #антипаттерны #рефакторинг

Как реализовать WebSocket на Android и не сойти с ума

Как часто вы слышите что-то о протоколе WebSocket? А как часто видели его в проектах? Продакшн? Андроид? Что? Его кто-то использует? А теперь представьте, что перед вами стоит задача внедрить WS в крупный продакшн проект с нуля. С чего начать? Как подступиться?

https://habr.com/ru/companies/betboom/articles/1007816/

#kotlin #android #websocket #kmp #network #kotlin_multiplatform #wss #clean_architecture #мобильная_разработка #андроид

Как реализовать WebSocket на Android и не сойти с ума

Как часто вы слышите что-то о протоколе WebSocket? А как часто видели его в проектах? Продакшн? Андроид? Что? Его кто-то использует? А теперь представьте, что перед вами стоит задача внедрить WS в крупный продакшн проект с нуля. С чего начать? Как подступиться?

https://habr.com/ru/companies/betboom/articles/1007816/

#kotlin #android #websocket #kmp #network #kotlin_multiplatform #wss #clean_architecture #мобильная_разработка #андроид

Как реализовать WebSocket на Android и не сойти с ума

Как часто вы слышите что-то о протоколе WebSocket? А как часто видели его в проектах? Продакшн? Андроид? Что? Его кто-то использует? А теперь представьте, что перед вами стоит задача внедрить WS в крупный продакшн проект с нуля. С чего начать? Как подступиться?

https://habr.com/ru/companies/betboom/articles/1007816/

#kotlin #android #websocket #kmp #network #kotlin_multiplatform #wss #clean_architecture #мобильная_разработка #андроид

Как реализовать WebSocket на Android и не сойти с ума

Как часто вы слышите что-то о протоколе WebSocket? А как часто видели его в проектах? Продакшн? Андроид? Что? Его кто-то использует? А теперь представьте, что перед вами стоит задача внедрить WS в крупный продакшн проект с нуля. С чего начать? Как подступиться?

https://habr.com/ru/companies/betboom/articles/1007816/

#kotlin #android #websocket #kmp #network #kotlin_multiplatform #wss #clean_architecture #мобильная_разработка #андроид

ADR, архитектурные тесты и кейсы из прода: ресурсы, которые реально меняют код

У меня была привычка. Вижу классную статью про архитектуру —-сохраняю. Репозиторий с примерами DDD - в закладки. Видео про CQRS - в плейлист «Посмотреть потом». Вы знаете, чем кончаются плейлисты «Посмотреть потом». В какой-то момент закладок стало 300+. Половина ссылок битые, треть дублируют друг друга, остальное - статьи, которые казались гениальными в два часа ночи. Я сел и вычистил всё до 106 ресурсов. Собрал их в awesome-list на GitHub . Но статья не про список. Статья про три вещи, которые я для себя открыл в процессе и которые почему-то мало обсуждают.

https://habr.com/ru/articles/1001010/

#architecture #DDD #CQRS #clean_architecture #ADR #software_design #software_architecture #best_practices #system_design #microservices

ADR, архитектурные тесты и кейсы из прода: ресурсы, которые реально меняют код

У меня была привычка. Вижу классную статью про архитектуру —-сохраняю. Репозиторий с примерами DDD - в закладки. Видео про CQRS - в плейлист «Посмотреть потом». Вы знаете, чем кончаются плейлисты «Посмотреть потом». В какой-то момент закладок стало 300+. Половина ссылок битые, треть дублируют друг друга, остальное - статьи, которые казались гениальными в два часа ночи. Я сел и вычистил всё до 106 ресурсов. Собрал их в awesome-list на GitHub . Но статья не про список. Статья про три вещи, которые я для себя открыл в процессе и которые почему-то мало обсуждают.

https://habr.com/ru/articles/1001010/

#architecture #DDD #CQRS #clean_architecture #ADR #software_design #software_architecture #best_practices #system_design #microservices

ADR, архитектурные тесты и кейсы из прода: ресурсы, которые реально меняют код

У меня была привычка. Вижу классную статью про архитектуру —-сохраняю. Репозиторий с примерами DDD - в закладки. Видео про CQRS - в плейлист «Посмотреть потом». Вы знаете, чем кончаются плейлисты «Посмотреть потом». В какой-то момент закладок стало 300+. Половина ссылок битые, треть дублируют друг друга, остальное - статьи, которые казались гениальными в два часа ночи. Я сел и вычистил всё до 106 ресурсов. Собрал их в awesome-list на GitHub . Но статья не про список. Статья про три вещи, которые я для себя открыл в процессе и которые почему-то мало обсуждают.

https://habr.com/ru/articles/1001010/

#architecture #DDD #CQRS #clean_architecture #ADR #software_design #software_architecture #best_practices #system_design #microservices

ADR, архитектурные тесты и кейсы из прода: ресурсы, которые реально меняют код

У меня была привычка. Вижу классную статью про архитектуру —-сохраняю. Репозиторий с примерами DDD - в закладки. Видео про CQRS - в плейлист «Посмотреть потом». Вы знаете, чем кончаются плейлисты «Посмотреть потом». В какой-то момент закладок стало 300+. Половина ссылок битые, треть дублируют друг друга, остальное - статьи, которые казались гениальными в два часа ночи. Я сел и вычистил всё до 106 ресурсов. Собрал их в awesome-list на GitHub . Но статья не про список. Статья про три вещи, которые я для себя открыл в процессе и которые почему-то мало обсуждают.

https://habr.com/ru/articles/1001010/

#architecture #DDD #CQRS #clean_architecture #ADR #software_design #software_architecture #best_practices #system_design #microservices

Надежный код: как писать тесты, чтобы запускать фичи в продакшен одним днем

Писать или не писать тесты — выбор очевидный. Конечно, писать. Но если проект масштабный, одних unit‑тестов будет недостаточно: они бессильны на границах модулей, в интеграциях и пользовательских сценариях, а значит в этих местах будут пролезать баги. Такой код будет сложно поддерживать, вносить в него изменения и получать ожидаемый результат. В статье поговорим про разные стратегии тестирования под разные риски и кейсы. Поднимемся над привычными unit‑тестами и заглянем, что там есть еще. Спойлер: а еще там workflow‑, integration‑, property‑based‑ и resilience‑тесты.

https://habr.com/ru/companies/mindbox/articles/1000090/

#C# #unittesting #integration_testing #propertybasedtesting #pure_functions #clean_architecture

Надежный код: как писать тесты, чтобы запускать фичи в продакшен одним днем

Писать или не писать тесты — выбор очевидный. Конечно, писать. Но если проект масштабный, одних unit‑тестов будет недостаточно: они бессильны на границах модулей, в интеграциях и пользовательских сценариях, а значит в этих местах будут пролезать баги. Такой код будет сложно поддерживать, вносить в него изменения и получать ожидаемый результат. В статье поговорим про разные стратегии тестирования под разные риски и кейсы. Поднимемся над привычными unit‑тестами и заглянем, что там есть еще. Спойлер: а еще там workflow‑, integration‑, property‑based‑ и resilience‑тесты.

https://habr.com/ru/companies/mindbox/articles/1000090/

#C# #unittesting #integration_testing #propertybasedtesting #pure_functions #clean_architecture

Надежный код: как писать тесты, чтобы запускать фичи в продакшен одним днем

Писать или не писать тесты — выбор очевидный. Конечно, писать. Но если проект масштабный, одних unit‑тестов будет недостаточно: они бессильны на границах модулей, в интеграциях и пользовательских сценариях, а значит в этих местах будут пролезать баги. Такой код будет сложно поддерживать, вносить в него изменения и получать ожидаемый результат. В статье поговорим про разные стратегии тестирования под разные риски и кейсы. Поднимемся над привычными unit‑тестами и заглянем, что там есть еще. Спойлер: а еще там workflow‑, integration‑, property‑based‑ и resilience‑тесты.

https://habr.com/ru/companies/mindbox/articles/1000090/

#C# #unittesting #integration_testing #propertybasedtesting #pure_functions #clean_architecture

Надежный код: как писать тесты, чтобы запускать фичи в продакшен одним днем

Писать или не писать тесты — выбор очевидный. Конечно, писать. Но если проект масштабный, одних unit‑тестов будет недостаточно: они бессильны на границах модулей, в интеграциях и пользовательских сценариях, а значит в этих местах будут пролезать баги. Такой код будет сложно поддерживать, вносить в него изменения и получать ожидаемый результат. В статье поговорим про разные стратегии тестирования под разные риски и кейсы. Поднимемся над привычными unit‑тестами и заглянем, что там есть еще. Спойлер: а еще там workflow‑, integration‑, property‑based‑ и resilience‑тесты.

https://habr.com/ru/companies/mindbox/articles/1000090/

#C# #unittesting #integration_testing #propertybasedtesting #pure_functions #clean_architecture

Как я написал AI-генератор коротких видео (Shorts/Reels) на Python с Clean Architecture

Привет, Хабр! 👋 В этой статье я хочу поделиться опытом разработки пет-проекта, который превратился в полноценный инструмент для автоматической генерации коротких видео (Shorts, Reels, TikTok). Идея проста: на входе — тема (например, "История Римской Империи за 1 минуту"), на выходе — готовый видеоролик с озвучкой, субтитрами и сгенерированным видеорядом. Но вместо того, чтобы накидать "спагетти-код" в одном файле main.py , я решил подойти к задаче как инженер и построить систему на принципах Clean Architecture . 🎯 Зачем? Генерация видео — это сложный пайплайн: 1. Написать сценарий. 2. Придумать визуальный стиль. 3. Сгенерировать картинки (Midjourney, Flux). 4. Оживить картинки в видео (Kling, Runway, Sora). 5. Озвучить текст (TTS). 6. Собрать всё вместе с субтитрами. API меняются, модели выходят новые каждую неделю. Сегодня лучший визуал у Flux, завтра у Midjourney v7. Сегодня видео делаем в Runway, завтра в Kling. Жесткая привязка к конкретным API убила бы проект через месяц. Поэтому Clean Architecture здесь не роскошь, а необходимость. 🏗 Архитектура Проект разбит на слои, следуя классической "луковой" архитектуре: 1. Domain (Entities) : Pydantic-модели, описывающие суть ( VideoScript , Scene , Character ). Они ничего не знают о внешнем мире. 2. Interfaces : Абстрактные классы ( VideoGenerator , ScriptGenerator ). Контракты, которые должны соблюдать внешние сервисы. 3. Services (Use Cases) : Бизнес-логика. Здесь живут "Агенты": Сценарист, Арт-директор, Режиссер монтажа. 4. Infrastructure : Реализации интерфейсов (API клиентов Comet, Yandex, OpenAI и т.д.).

https://habr.com/ru/articles/996064/

#ai #langchain #langchain_агенты #pyhon #clean_architecture

Как я написал AI-генератор коротких видео (Shorts/Reels) на Python с Clean Architecture

Привет, Хабр! 👋 В этой статье я хочу поделиться опытом разработки пет-проекта, который превратился в полноценный инструмент для автоматической генерации коротких видео (Shorts, Reels, TikTok). Идея проста: на входе — тема (например, "История Римской Империи за 1 минуту"), на выходе — готовый видеоролик с озвучкой, субтитрами и сгенерированным видеорядом. Но вместо того, чтобы накидать "спагетти-код" в одном файле main.py , я решил подойти к задаче как инженер и построить систему на принципах Clean Architecture . 🎯 Зачем? Генерация видео — это сложный пайплайн: 1. Написать сценарий. 2. Придумать визуальный стиль. 3. Сгенерировать картинки (Midjourney, Flux). 4. Оживить картинки в видео (Kling, Runway, Sora). 5. Озвучить текст (TTS). 6. Собрать всё вместе с субтитрами. API меняются, модели выходят новые каждую неделю. Сегодня лучший визуал у Flux, завтра у Midjourney v7. Сегодня видео делаем в Runway, завтра в Kling. Жесткая привязка к конкретным API убила бы проект через месяц. Поэтому Clean Architecture здесь не роскошь, а необходимость. 🏗 Архитектура Проект разбит на слои, следуя классической "луковой" архитектуре: 1. Domain (Entities) : Pydantic-модели, описывающие суть ( VideoScript , Scene , Character ). Они ничего не знают о внешнем мире. 2. Interfaces : Абстрактные классы ( VideoGenerator , ScriptGenerator ). Контракты, которые должны соблюдать внешние сервисы. 3. Services (Use Cases) : Бизнес-логика. Здесь живут "Агенты": Сценарист, Арт-директор, Режиссер монтажа. 4. Infrastructure : Реализации интерфейсов (API клиентов Comet, Yandex, OpenAI и т.д.).

https://habr.com/ru/articles/996064/

#ai #langchain #langchain_агенты #pyhon #clean_architecture

Как я написал AI-генератор коротких видео (Shorts/Reels) на Python с Clean Architecture

Привет, Хабр! 👋 В этой статье я хочу поделиться опытом разработки пет-проекта, который превратился в полноценный инструмент для автоматической генерации коротких видео (Shorts, Reels, TikTok). Идея проста: на входе — тема (например, "История Римской Империи за 1 минуту"), на выходе — готовый видеоролик с озвучкой, субтитрами и сгенерированным видеорядом. Но вместо того, чтобы накидать "спагетти-код" в одном файле main.py , я решил подойти к задаче как инженер и построить систему на принципах Clean Architecture . 🎯 Зачем? Генерация видео — это сложный пайплайн: 1. Написать сценарий. 2. Придумать визуальный стиль. 3. Сгенерировать картинки (Midjourney, Flux). 4. Оживить картинки в видео (Kling, Runway, Sora). 5. Озвучить текст (TTS). 6. Собрать всё вместе с субтитрами. API меняются, модели выходят новые каждую неделю. Сегодня лучший визуал у Flux, завтра у Midjourney v7. Сегодня видео делаем в Runway, завтра в Kling. Жесткая привязка к конкретным API убила бы проект через месяц. Поэтому Clean Architecture здесь не роскошь, а необходимость. 🏗 Архитектура Проект разбит на слои, следуя классической "луковой" архитектуре: 1. Domain (Entities) : Pydantic-модели, описывающие суть ( VideoScript , Scene , Character ). Они ничего не знают о внешнем мире. 2. Interfaces : Абстрактные классы ( VideoGenerator , ScriptGenerator ). Контракты, которые должны соблюдать внешние сервисы. 3. Services (Use Cases) : Бизнес-логика. Здесь живут "Агенты": Сценарист, Арт-директор, Режиссер монтажа. 4. Infrastructure : Реализации интерфейсов (API клиентов Comet, Yandex, OpenAI и т.д.).

https://habr.com/ru/articles/996064/

#ai #langchain #langchain_агенты #pyhon #clean_architecture

Как я написал AI-генератор коротких видео (Shorts/Reels) на Python с Clean Architecture

Привет, Хабр! 👋 В этой статье я хочу поделиться опытом разработки пет-проекта, который превратился в полноценный инструмент для автоматической генерации коротких видео (Shorts, Reels, TikTok). Идея проста: на входе — тема (например, "История Римской Империи за 1 минуту"), на выходе — готовый видеоролик с озвучкой, субтитрами и сгенерированным видеорядом. Но вместо того, чтобы накидать "спагетти-код" в одном файле main.py , я решил подойти к задаче как инженер и построить систему на принципах Clean Architecture . 🎯 Зачем? Генерация видео — это сложный пайплайн: 1. Написать сценарий. 2. Придумать визуальный стиль. 3. Сгенерировать картинки (Midjourney, Flux). 4. Оживить картинки в видео (Kling, Runway, Sora). 5. Озвучить текст (TTS). 6. Собрать всё вместе с субтитрами. API меняются, модели выходят новые каждую неделю. Сегодня лучший визуал у Flux, завтра у Midjourney v7. Сегодня видео делаем в Runway, завтра в Kling. Жесткая привязка к конкретным API убила бы проект через месяц. Поэтому Clean Architecture здесь не роскошь, а необходимость. 🏗 Архитектура Проект разбит на слои, следуя классической "луковой" архитектуре: 1. Domain (Entities) : Pydantic-модели, описывающие суть ( VideoScript , Scene , Character ). Они ничего не знают о внешнем мире. 2. Interfaces : Абстрактные классы ( VideoGenerator , ScriptGenerator ). Контракты, которые должны соблюдать внешние сервисы. 3. Services (Use Cases) : Бизнес-логика. Здесь живут "Агенты": Сценарист, Арт-директор, Режиссер монтажа. 4. Infrastructure : Реализации интерфейсов (API клиентов Comet, Yandex, OpenAI и т.д.).

https://habr.com/ru/articles/996064/

#ai #langchain #langchain_агенты #pyhon #clean_architecture