#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 #модульная_архитектура #масштабирование_приложений #границы_модулей #рефакторинг

Boolean — плохой флаг для данных

Мы все видели и использовали поля типа boolean в базах данных как часть структуры данных. На первый взгляд это удобно: два значения — «да» или «нет», просто и понятно. Например, у пользователя может быть флаг is_active , который показывает, включён аккаунт или нет, или поле is_deleted , которое используется как мягкое удаление. Такие поля встречаются повсюду. Но на практике хранение boolean в базе данных как элемента модели часто приводит к проблемам. В этой статье разберёмся, почему boolean может быть плохим выбором, и что использовать вместо него, чтобы избежать ошибок в будущем.

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

#clean_code #clean_architecture #data_structures #data_storage #architectureascode #architecture_design #architecture_principles #architectural_decision_records