package by feature Упаковка кода Хотел написать пост про package by feature, но когда начал собирать фактуру, понял, что проблема, которую я хотел обозреть, куда глубже. Поэтому сегодня поговорим про упаковку кода в целом. На своей практике я чаще всего вижу 2 варианта упаковки кода: 1. Package by type - когда проект состоит из таких папок, как Controllers, Services, Repositories, Entities, DTOs и т.д. Обычный скелетон, который предлагает любой фреймворк. 2. Package by layer - когда проект состоит из папок, как App, Domain, Infra и т.д. Те, кто только начинают практиковать DDD, часто используют этот вариант. Есть третий вариант, о котором я очень часто слышу, но в реальных проектах, которые проходили через меня, пока не встречал в чистом виде. 3. Package by feature - когда проект делится на фичи: Feature1, Feature2, Feature3 и т.д. Например, фича регистрации пользователя содержит и сущность, и DTO, и контроллер, и сервис, и репозиторий. Если сущность переиспользуется в другой фиче, то её выносят в общий модуль и импортируют. А вот какой подход лучше? Каждый подход хорош, пока кодовая база небольшая. Package by type -- считаю самым отвратительным способом. Можно сказать, одна фича размыта по 5 или 6 папкам, между которыми приходится постоянно переключаться. Package by layer -- супер, мы выделили слои, но у нас по-прежнему каждый слой содержит кучу функциональности, файлов и папок. Весь проект просто разделен на технические слои, а не по функциональности. Package by feature -- код фичи инкапсулирован, но вероятно, фич может быть также много, они могут быть связаны между собой и использовать одни и те же сущности. Разбухает количество shared классов. Также несколько фич может относиться к какой-то определенной зоне функциональности продукта. Что делать? Забирать лучшее от каждого подхода. В DDD есть понятие домена. В рамках такого домена существует своя модель, термины и свои правила. Каждый домен развивается независимо друг от друга. И это хорошая точка для начала упаковки. Таким доменами могут быть, например, billing, catalog, users и т.д. Здесь прослеживается подход package by feature. Домены могут быть простыми и сложными, например, billing может быть очень сложным, включать в себя оплату, выплаты, счета и т.д. И такой домен можно ещё покомпозировать и поделить на поддомены. Продолжаем делить по типу package by feature. Код домена/поддомена можно поделить по-разному, всё зависит от его сложности. Если домен состоит из пары файлов, то смысла делить вообще нет. Если домен типа support или generic, то можно использовать package by type. Если домен сложный и/или core, то стоит поделить на слои App, Domain, Infra, UI, получив все преимущества чистой архитектуры. Каждый слой также требует декомпозиции. Возьмем слой Domain, который может быть достаточно большим, классы в нём захочется упаковать по папочкам. И тут снова стоит поделить на фичи. Например, Order, Customer, Product. Не стоит делить по типу: Entity, Repository, ValueObject и т.д. Иначе это снова приведет к тому, что код, относящийся к одной функциональности, будет разделен по разным каталогам. Комбинация этих подходов к упаковке кода даст хорошо структурированный проект, с независимыми модулями, каждый из которых может применять ту архитектуру, которая будет приносить максимальную пользу для конкретного домена.