Если разработчик-внедренец, то лучше USR и USP оставлять пустыми для:
USR - работы кодеров клиента, в процессе внедрения слой по жизни пустой
USP - для временных слияний кода, тк утилита сравнения ущербна, лучше залить в ЮСП, сравнить по-человечески, и стереть за собой.
В USP так же стоит сваливать разработческие утилиты, и стирать их за собой после внедрения.
Ошибочное занятие USR для внедрения, а USP для клиента приводит к тому, что слоев просто нет для сливания ХРО (внимание! сами себе яму роете этим)
Приходим к тому, что для внедренца разрабатывать лучше в CUS слое.
При этом, если в основе проекта лежит какое-то решение (самого внедренца или чье-то), то оно должно лежать в VAR, для удобного сравнения с было-стало. И апдайтится как серфис пак, если его делает другая команда.
Слой CUP при этом может (не обязательно) использоваться для самого кодинга всей командой, а после кодревью ведущего разработчика (удобного как кас-кап дельта) опускается в кас с сохранением ИД и стирается весь кап до следующей итерации.
Важно, что между ВАР и ВАП, кас и кап, юср и юсп переносить можно (и нужно) с сохранением ИД.
А между ВАР и КАС (и прочими) - не нужно (хотя и можно), но крайне НЕ нужно.
Учесть при выборе слоев возможности заливки в запущенную рабочую АХ ХРОшек по-живому (ИД новых элементов и периодическую подмену слоев целиком).
Разобраться с SQLDictonary, понять, как после перебивки ИД (из КАС в ВАР или из ЮСР в КАС) сохранить данные, если делалось на живых данных.
Все это выстраданное ИМХО за много лет разных подходов и проектов. Не зависимо от книжек (тогда их и не было) и теорий.
Это действующая методика, дающая экономию во времени до 40-70% времени и повышающая качество за счет удобного сравнения кода и код ревью.
Сталкивался с двумя мнениями разработчиков, кто что считает верхним слоем.
Сам я фанат картинки-схемы аля слои Земли, где sys - это ядро, а usr - слой почвы
Потому термин "нижний слой" - это физически вниз
, то есть в sys.