Последние полгода на одном из своих проектов я перешел на необычный для меня концепт - package by feature . Суть его в том что мы не делим проект на пакеты типа model, dao, service, controller. Вместо этого мы делим их по фичам, и внутри фича-пакета у нас классы всех слоев.

Пока я очень доволен - структура проекта отражает то что он делает, кол-во public классов уменьшилось, наверно, раза в 3. Однако проект пока скромных размеров (без тестов это 25 kloc на бэке), а на мелких проектах все подходы выглядят хорошо.

Особенно интересно мнение людей которые уже сталкивались с таким.

У меня пока таких проблем не было. Видимо зависит от того что считать "фичей". Пока у меня разбиение по кускам домена, поэтому в пакете классов может быть прилично.

Вообще мне сложно представить как может в пакете один класс оказаться, ведь очень вероятно что ему нужно что-то отдать на UI или сохранить что-то в БД. Вот, например, простенький пример где нужно лишь получить запрос с UI и ответить обратно:

Я не думаю что (во всяком случае в моей ситуации) пакет может быть меньше этого. Разве что и запрос, и ответ - примитивы, тогда останется только RegressionApi. А вот пакет по-серьезней, который возможно следует нарезать по-тоньше, но здесь нет БД и API:

А вот более типичный пакет где все слои есть:

maytonЕсли у Станислава фичи - слабосвязные между собой то это хорошая практика. Получается что внедрение новой фичи
почти не затрагивает старый код. Минимум изменений - всегда знаешь где искать баг.Было бы здорово конечно, но в моем случае это все-таки не так. Наверно слово "feature" в этом подходе сбивает с толку. Я бью пакеты по куску домена, и уж если внутри большого пакета наклевывается какая-то фича, тогда получается еще создать пакет вот только с этой фичей. Но пока это редкость.
maytonИ еще в голове почему-то вертится Blue-Green deployment и мне кажется что это по духу близко к теме
топика. Такой-себе безобрывный и надежный деплой.Не, с деплоем это никак не связано. Все пакеты (независимо от разбиения) попадают в общий итоговый артефакт. И если нам нужен беспрерывный деплой, то в любом случае нужно какой-то код написать или конфигурацию изменить. Т.е. изменения потребуются те же вне зависимости от того как мы на пакеты нарежем.

Ну если взять разработку форума, то мы могли бы получить такие пакеты:

В каждом пакете может быть как одна или несколько Сущностей, так и DAO, Service, API, DTO классы. Мм.. возможно даже вызовы к внешним сервисам.
maytonВозможно в каком-то 2025 году будет сложно собрать части одного слоя т.к. он распыленВот я сначала тоже переживал, а потом подумал.. а зачем бы это надо было.
maytonИ мне кажется что подводным камнем может быть просто
распухание системы имен пакетов.А разве мы получаем много новых пакетов? Раньше было:

И если пакет распухал, то внутри model & service мы создавали пакет branch. А теперь: