home.social

#clean_architecture — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #clean_architecture, aggregated by home.social.

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

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

    habr.com/ru/articles/1044352/

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

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

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

    habr.com/ru/articles/1044218/

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

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

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

    habr.com/ru/articles/1001010/

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

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

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

    habr.com/ru/articles/942910/

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