VoidVolker

Про size_t - если вы на 100% уверены, что у вас никогда не случится потеря данных при преобразовании из 8 байтного беззнакового size_t в 4 байтный знаковый int, то можете сделать явное преобразование типов (cast). Но гораздо правильней для размера (всего чего угодно) использовать size_t (а не int), как это давно уже делают в std.
Про strncpy - в некоторых случаях она может быть не безопасной. Если вы на 100% уверены, что в вашем случае она точно безопасна, то можно забить на ошибку, объявить макрос, который указан в тексте ошибки и на этом проблема будет исчерпана. Но есть безопасные аналоги строковых функций у них к имени добавляется суффикс _s. В вашем случае безопасный аналог strncpy_s. Используйте безопасные функции. Безопасные функции немного медленней работают, за счет дополнительных проверок и т.п.

Так там же явно написано:
C4267 - size_t действительно теоретически быть больше, чем int
C4996 - strncpy действительно может небезопасной.

Там же явно написано о том, как их можно исправить - читай внимательно.

В реальных проектах используют разные варианты исходя из личного опыта и настроения каждого члена команды на момент старта проекта.

Может быть и супер сложный clean architecture + DDD + CQRS.
Может быть Vertical Slice.
А может быть и предельно простая архитектура даже без разделения на проекты (крайне недооценённый вариант на самом деле)

У всего есть свои плюсы и минусы.