Коллеги, а помогите пожалуйста собрать для мини-исследования знакомых статистику

https://tjournal.ru/tech/153814-a-chto-delaet-tvoy-rabotodatel-v-period-pandemii

для меня непонятно что имеется в виду под термином “класс”, что означают буквенные сокращения в блоке техники/принципы/свойств. В итоге не ясно какой именно постулат высказывает эта схема.

SOLID же буквенные сокращения)

Схема -  попытка как-то связать правила GRASP + SOLID, их взаимосвязь

Класс - объект, сущность. Из ООП понятие

вот это и есть недостающая информация, то есть определение контекста к чему это относится

это очень важно для передачи знания другим людям.
Автор всегда в контексте задачи, ему все очевидно.
А человеку со стороны неочевидно.
Потом мы видим что новые разработчики не могут разобраться в коде который делали другие разработчики,
буквы и конструкции языка все известные, но логику не понять.  Потому что писали “для себя”, а не “для других”, сокращая важные смысловые вещи. Многое подразумевается, а не показано явно. Подразумеваемое неизвестно другим людям.

Видели проекты, передавемые от одного исполнителя к другому?
Знакомые ощущения?)

Пример неопределенного контекста: Мне принесли документы про “онлайн-чат”.  Чат с кем? Чат в каком сервисе? Кто с кем общается в чате, по каким процессам/задачам?
В системе где есть больше одного сервиса и класса пользователей, этот термин может означать что угодно.
А если чаты у вас уже есть, вообще не понять о чем это и к чему относится)

Да, спасибо) Я просто попытался разобраться с некоторыми принципами, и хотел услышать мнение со стороны

Как сказал великий Брукс: основная задача проектирования состоит в том, что определить что должно быть спроектировано (цитирую не дословно, по памяти)

Кстати да. Вот прям в точку.

Сеглдня по новостям прошла статья-учебник по проетированию схем БД в PostgreSQL
https://www.graphile.org/postgraphile/postgresql-schema-design/

что бросается в глаза: сделан упор на дизайн БД на основе объектных типов (https://www.postgresql.org/docs/current/sql-createtype.html)

Как вы считаете, применение объектных типов колонок СУБД это хорошая новая практика или нет, стоит по прежнему использовать только примитивные типы (строки, числа)?

Смотря для каких задач, но для Postgre это скорее хорошая практика )

у случае высокой степени изменчивости предметной области это очень неплохое решение - особенно в купе применения, например, JSON-полей

грубо говоря это одна из альтернатив схемам типа EAV

но надо понимать, что из этого могут вытекать и проблемы поддержки целостности данных

Только строгая типизация и нормализация спасут мир)
А если серьёзно, то ИМХО сугубо от условия применения