Слои или Фичи (Домены)Существует два основных подхода организации кода в приложениях. Либо по слоям, когда у нас, грубо говоря, в одной папке контроллеры, в другой модели, в третьей тесты и так далее. И подход когда папочки объединяются по фичам/домену, в таком случае в одной папке лежат все возможные элементы приложения (и контроллеры и модели и тесты и что там еще есть в вашей экосистеме). И каждый раз идет срач на тему, а как правильно? Иногда за нас это уже определено.Значит если мы берем большие фреймворки, то там все это вшито на базовом уровне. В джанге мы объединяемся вокруг доменов, в rails/laravel и многих других вокруг слоев. В микрофреймворках обычно дефолт это слои, но никто не мешает разложить по доменам. Во фронтенде можно и так и так, мало какой инструмент диктует структуру.Бывают и гибридные варианты. В той же Django внутри каждой фичи (app) у нас слоистая архитектура. А в rails есть понятие engine, когда часть логики можно вынести как бы в отдельное rails приложение, а затем внедрить его в исходное (для этого есть механизм движков). Его обычно используют для каких-то тем, которые прямо сильно выделяются или реализуются как отдельные проекты, например, так можно подрубить форум или систему мониторинга очередей.Несмотря на то, что система с разбиением по фичам/доменам кажется очень привлекательной я скептически отношусь к попытке ставить это в базу и делать абсолютно всю логику приложения через такой подход. Для меня это сродни тому что мы со старта делаем микросервисную архитектуру. Сразу встает масса сложностей, которые надо решать начиная от управления зависимостями между этими частями (кто от кого зависит, а если они зависят друг от друга?) до решения того, куда помещать логику на стыках? Достаточно посмотреть сколько в Django мире на эту тему придумано паттернов и разведено срачей.А вот наоборот проще. По дефолту все можно складывать вместе, но если надо, мы без особых проблем можем строить внутри достаточно изолированные части, которые хотя и лежат физически в разных папках, но правильно изолированы от других частей системы (тут и сервисы и события и все на свете). Если идти дальше, то можно вынести логику и в сервис и в библиотеку. Например в Хекслете редактор реализован в виде отдельного пакета и разрабатывается в отдельной репе, но теоретически мы могли бы положить его тупо внутрь проекта (кроме бекенда). Такое отделение заставляет делать больше телодвижений, но зато очень хорошо соблюдаются границы.Есть еще важная вещь, которую я учитываю. Разделение по фичам требует постоянно выскокой квалификации. Есть проекты где на это можно рассчитывать, а есть где нет. И там где нет, попытка делать крутую структуру может закончится еще хуже, потому что будут приниматься откровенно плохие решенияКак вы делаете в своих проектах?Telegram | YouTube | Сообщество
После прохождения процедуры можно разрешить установку APK на 7 дней или навсегда, при этом предупреждения о рисках всё равно будут появляться при каждой установке.
