#clean_architecture — Public Fediverse posts

FSD, Clean или modular? Шесть вариантов React-магазина под четырьмя изменениями

Мы вынесли компактную карточку банковской карты в entities/card/ui : маска номера, баланс и статус — решение казалось очевидным. Через два спринта в карточке появились действия «заблокировать карту» и «изменить лимит». В итоге entity начала импортировать features/block-card , features/change-card-limit и проверку прав доступа мимо public API. Когда ту же карточку понадобилось показать в выборе счёта списания, вместе с ней приехали ненужные зависимости и проверки ролей. Пользовательских инцидентов не случилось, но исправление отняло время. В entity оставили чистый CardPreview , сценарии подключили выше, композицию дашборда перенесли в widgets/card-summary , затем заново прогнали ролевые тесты. После этого на ревью мы стали обсуждать имя папки ближе к концу разговора. Сначала отвечали на другой вопрос: Какие будущие изменения выбранная граница позволит оставить локальными? В FSD 2.1 для подобных ситуаций рекомендуют начинать со страниц и извлекать код ниже по мере появления переиспользования. Это хороший вариант по умолчанию, хотя самостоятельный сценарий с близким вторым потребителем иногда оправдывает границу раньше.

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

#React #TypeScript #архитектура_фронтенда #FeatureSliced_Design #FSD #Clean_Architecture #модульная_архитектура #масштабирование_приложений #границы_модулей #рефакторинг

FSD, Clean или modular? Шесть вариантов React-магазина под четырьмя изменениями

Мы вынесли компактную карточку банковской карты в entities/card/ui : маска номера, баланс и статус — решение казалось очевидным. Через два спринта в карточке появились действия «заблокировать карту» и «изменить лимит». В итоге entity начала импортировать features/block-card , features/change-card-limit и проверку прав доступа мимо public API. Когда ту же карточку понадобилось показать в выборе счёта списания, вместе с ней приехали ненужные зависимости и проверки ролей. Пользовательских инцидентов не случилось, но исправление отняло время. В entity оставили чистый CardPreview , сценарии подключили выше, композицию дашборда перенесли в widgets/card-summary , затем заново прогнали ролевые тесты. После этого на ревью мы стали обсуждать имя папки ближе к концу разговора. Сначала отвечали на другой вопрос: Какие будущие изменения выбранная граница позволит оставить локальными? В FSD 2.1 для подобных ситуаций рекомендуют начинать со страниц и извлекать код ниже по мере появления переиспользования. Это хороший вариант по умолчанию, хотя самостоятельный сценарий с близким вторым потребителем иногда оправдывает границу раньше.

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

#React #TypeScript #архитектура_фронтенда #FeatureSliced_Design #FSD #Clean_Architecture #модульная_архитектура #масштабирование_приложений #границы_модулей #рефакторинг

FSD, Clean или modular? Шесть вариантов React-магазина под четырьмя изменениями

Мы вынесли компактную карточку банковской карты в entities/card/ui : маска номера, баланс и статус — решение казалось очевидным. Через два спринта в карточке появились действия «заблокировать карту» и «изменить лимит». В итоге entity начала импортировать features/block-card , features/change-card-limit и проверку прав доступа мимо public API. Когда ту же карточку понадобилось показать в выборе счёта списания, вместе с ней приехали ненужные зависимости и проверки ролей. Пользовательских инцидентов не случилось, но исправление отняло время. В entity оставили чистый CardPreview , сценарии подключили выше, композицию дашборда перенесли в widgets/card-summary , затем заново прогнали ролевые тесты. После этого на ревью мы стали обсуждать имя папки ближе к концу разговора. Сначала отвечали на другой вопрос: Какие будущие изменения выбранная граница позволит оставить локальными? В FSD 2.1 для подобных ситуаций рекомендуют начинать со страниц и извлекать код ниже по мере появления переиспользования. Это хороший вариант по умолчанию, хотя самостоятельный сценарий с близким вторым потребителем иногда оправдывает границу раньше.

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

#React #TypeScript #архитектура_фронтенда #FeatureSliced_Design #FSD #Clean_Architecture #модульная_архитектура #масштабирование_приложений #границы_модулей #рефакторинг

Лучшая архитектура KMP-приложений и когда её не использовать. Часть 2

В первой части мы разобрали философию KMP, обсудили лестницу развития проектов и выяснили, почему не стоит шарить ViewModel. Теперь давайте заглянем в код и поговорим про то, с чем столкнутся разработчики при выполнении ежедневных задач. Это вторая, практическая, часть из двух. Здесь про то, как организованы слои, какие контракты уходят в Swift, как готовить SKIE, как устроены обработка ошибок и DI, что с модульностью, скоростью сборки и тестами.

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

#kotlin_multiplatform #kmp #compose_multiplatform #clean_architecture #кроссплатформенная_разработка #архитектура_мобильных_приложений #kmp_архитектура #skie #нативная_разработка

Лучшая архитектура KMP-приложений и когда её не использовать. Часть 2

В первой части мы разобрали философию KMP, обсудили лестницу развития проектов и выяснили, почему не стоит шарить ViewModel. Теперь давайте заглянем в код и поговорим про то, с чем столкнутся разработчики при выполнении ежедневных задач. Это вторая, практическая, часть из двух. Здесь про то, как организованы слои, какие контракты уходят в Swift, как готовить SKIE, как устроены обработка ошибок и DI, что с модульностью, скоростью сборки и тестами.

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

#kotlin_multiplatform #kmp #compose_multiplatform #clean_architecture #кроссплатформенная_разработка #архитектура_мобильных_приложений #kmp_архитектура #skie #нативная_разработка

Лучшая архитектура KMP-приложений и когда её не использовать. Часть 2

В первой части мы разобрали философию KMP, обсудили лестницу развития проектов и выяснили, почему не стоит шарить ViewModel. Теперь давайте заглянем в код и поговорим про то, с чем столкнутся разработчики при выполнении ежедневных задач. Это вторая, практическая, часть из двух. Здесь про то, как организованы слои, какие контракты уходят в Swift, как готовить SKIE, как устроены обработка ошибок и DI, что с модульностью, скоростью сборки и тестами.

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

#kotlin_multiplatform #kmp #compose_multiplatform #clean_architecture #кроссплатформенная_разработка #архитектура_мобильных_приложений #kmp_архитектура #skie #нативная_разработка

1038 баллов на Hacker News собрал пост про отказ от AI-кодинга. У меня была та же ночь, но другой вывод

9 мая пост «I’m going back to writing code by hand» набрал на Hacker News 1038 баллов и 617 комментариев. Автор семь месяцев вайб-кодил Kubernetes-дашборд с Claude, дошёл до god object на 1690 строк и бросил AI-кодинг. Я узнал в этом свою историю полугодовой давности, но вывод сделал другой.

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

#claude_code #ai_coding #vibecoding #clean_architecture #ai_agents #developer_tools #claudemd

1038 баллов на Hacker News собрал пост про отказ от AI-кодинга. У меня была та же ночь, но другой вывод

9 мая пост «I’m going back to writing code by hand» набрал на Hacker News 1038 баллов и 617 комментариев. Автор семь месяцев вайб-кодил Kubernetes-дашборд с Claude, дошёл до god object на 1690 строк и бросил AI-кодинг. Я узнал в этом свою историю полугодовой давности, но вывод сделал другой.

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

#claude_code #ai_coding #vibecoding #clean_architecture #ai_agents #developer_tools #claudemd

1038 баллов на Hacker News собрал пост про отказ от AI-кодинга. У меня была та же ночь, но другой вывод

9 мая пост «I’m going back to writing code by hand» набрал на Hacker News 1038 баллов и 617 комментариев. Автор семь месяцев вайб-кодил Kubernetes-дашборд с Claude, дошёл до god object на 1690 строк и бросил AI-кодинг. Я узнал в этом свою историю полугодовой давности, но вывод сделал другой.

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

#claude_code #ai_coding #vibecoding #clean_architecture #ai_agents #developer_tools #claudemd

Clean Architecture и AI: как я перестроил проект на 200К строк, чтобы агенты не ломали код

Агент не ломает архитектуру. Он заливается в те щели, которые ты ему оставил. Как я перестроил проект на 200К строк, чтобы границы держал линтер и CI, а не слова в CLAUDE.md . С кодом и цифрами до и после.

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

#clean_architecture #claude_code #CLAUDEmd #архитектура #aiинструменты #typescript

Clean Architecture и AI: как я перестроил проект на 200К строк, чтобы агенты не ломали код

Агент не ломает архитектуру. Он заливается в те щели, которые ты ему оставил. Как я перестроил проект на 200К строк, чтобы границы держал линтер и CI, а не слова в CLAUDE.md . С кодом и цифрами до и после.

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

#clean_architecture #claude_code #CLAUDEmd #архитектура #aiинструменты #typescript

Clean Architecture и AI: как я перестроил проект на 200К строк, чтобы агенты не ломали код

Агент не ломает архитектуру. Он заливается в те щели, которые ты ему оставил. Как я перестроил проект на 200К строк, чтобы границы держал линтер и CI, а не слова в CLAUDE.md . С кодом и цифрами до и после.

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

#clean_architecture #claude_code #CLAUDEmd #архитектура #aiинструменты #typescript

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

Контракт use case должен описывать потребность приложения, а не API выбранного persistence фреймворка. Spring Data пагинация хорошо работает в CRUD приложениях. Для многих проектов Pageable в application service — это разумный компромисс. Проблема возникает, когда Pageable становится частью публичного контракта use case.

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

#Clean_Architecture #Pageable #pagination #Repository_Pattern #CQRS #Read_Model #JDBC #java

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

Контракт use case должен описывать потребность приложения, а не API выбранного persistence фреймворка. Spring Data пагинация хорошо работает в CRUD приложениях. Для многих проектов Pageable в application service — это разумный компромисс. Проблема возникает, когда Pageable становится частью публичного контракта use case.

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

#Clean_Architecture #Pageable #pagination #Repository_Pattern #CQRS #Read_Model #JDBC #java

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

Контракт use case должен описывать потребность приложения, а не API выбранного persistence фреймворка. Spring Data пагинация хорошо работает в CRUD приложениях. Для многих проектов Pageable в application service — это разумный компромисс. Проблема возникает, когда Pageable становится частью публичного контракта use case.

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

#Clean_Architecture #Pageable #pagination #Repository_Pattern #CQRS #Read_Model #JDBC #java

В поисках баланса в backend-архитектуре

Размышление о backend‑архитектуре между двумя крайностями: академической чистотой и радикальным прагматизмом. На примере read/write path, CQRS, кэширования готовых ответов и собственного framework‑а на Go я показываю, как архитектурные шаблоны сталкиваются с production‑реальностью.

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

#backend #golang #go #clean_architecture #ddd #cqrs #архитектура #framework #read_path #write_path

В поисках баланса в backend-архитектуре

Размышление о backend‑архитектуре между двумя крайностями: академической чистотой и радикальным прагматизмом. На примере read/write path, CQRS, кэширования готовых ответов и собственного framework‑а на Go я показываю, как архитектурные шаблоны сталкиваются с production‑реальностью.

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

#backend #golang #go #clean_architecture #ddd #cqrs #архитектура #framework #read_path #write_path

В поисках баланса в backend-архитектуре

Размышление о backend‑архитектуре между двумя крайностями: академической чистотой и радикальным прагматизмом. На примере read/write path, CQRS, кэширования готовых ответов и собственного framework‑а на Go я показываю, как архитектурные шаблоны сталкиваются с production‑реальностью.

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

#backend #golang #go #clean_architecture #ddd #cqrs #архитектура #framework #read_path #write_path

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. Часть 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. Часть 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

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

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

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

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

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

Почему 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

Коллаборация человека и ИИ в 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 #паттерн #паттерны_проектирования

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 #мобильная_разработка #андроид