Системный аналитик должен проектировать структуру сущностей на основании собранной информации.
Без уточнения типа БД, без привязки типов данных конкретной БД.

Фактически СА надо сформировать абстрактную схему сущность - связь. Указать параметры связей (1к1, 1к*, *к* и тд) и сущностей (какие данные в ней будут, какие типы (список, объект, цифра, строка, булево), какие ограничения (длинна строки, корректные и некорректные знаки)). Обязательность.

А на что это будут напяливать - реляционную бд, нереляционную, файловое хранилище, оперативку... СА побоку.

Как раз твоя работа и должна позволить разработчикам и архитекторам понять, как лучше уложить данные.

Структуру БД куда лучше сделает профессиональный разработчик.

Работа аналитика в выделении, формализации сущностей прикладной области.
На мой взгляд хороший вариант артефакта такой работы - схема в формате UML Object diagram

все вроде оно так... но вот:

и сущностей (какие данные в ней будут, какие типы (список, объект, цифра, строка, булево), какие ограничения (длинна строки, корректные и некорректные знаки)).

Это черт возьми физическая модель, без абстракций, для реляционной БД
UPD а второе вообще для интерфейсов и проверки на стороне клиента (в вебе это браузер) даже скорей всего

Делаем так: ДА. Правильно так: НЕТ

ER читается приятней. И проще для понимания разработкой.

Разработчик сам сможет определить сколько у человека должно быть рабочих телефонов?
Или именно разработчик сможет понять, обязателен ли для сотрудника этот телефон или нет?

Кажется это вопрос прикладной области. Если разработчик её хорошо знает, то там не нужен СА принципиально.

Та же вещь, вид сбоку.
Те же варианты отношений, только их разработчики не понимают часто, т.к. диаграмму эту будут видеть впервые.

И нет, это не физическая модель, это как раз ERD

ER это специфическая нотация отражения сущностей реляционных баз.

UML object это про сущности домена предметной области.
В UML Object есть отношения вида "композиция", "агрегация, "специализация" и т.д.

тоже но в er, куда как лучше зайдет.

Да какая разница в чём писать, главное не ужимать разработчика в принятии решения.

Но работа эта всё равно ложится на аналитика.

длина строки и объекты, вы диктуете разработке, а точнее "ленивым" или хорошо устроившимся разработчикам что за обхекты и как с ними работать в ООП, так еще и в БД как объекты уложить. Объекты не домена, объекты физической реализации в коде. Реально это именно так.

Я не смотрел ролик про bed smell, но если так то реально bed smell попахивать начинает.
Еще чутка и вы начнете разработке методы ООП придумывать в uml, нотация хорошо для этого подходит. Я вам как человек с определенным опытом в коммерческом кодинге на JAVA говорю. Не профи, но все же опыт есть.

На мой взгляд bad smell начинается, когда постановка аналитика начинает напоминать псевдокод. Это уже признак что явно что-то не так.

Что за объекты? Есть сущности. Длину строки и символы вы получите от тех же разработчиков и уложите в документацию. Там вашей работы 0.

Вместо определения задачи фиксируется что конкретно нужно сделать, причем без объяснения почему.

А как тогда алгоритмы обработки данных описывать?
Или оставлять разработчику на "подумать"?

У меня было решение, в котором один запрос порождал логику на n-цать страниц преобразования данных, поиска сущностей, обновления и создания сущностей.

+

Просто есть два типа СА - один, это аналитик, который использует чужие знания и не парится. Фактически становится тем, кто документирует принятые решения и разрешает несоответствия.

Второй тип - кто лезет в код, это сегодняшние псевдо- и завтрашние готовые solution architect. А это значит, что через 3-6 лет они спокойно смогут создавать решения, указывать в каких технологиях хранить данные, описывать алгоритмы и так далее.

Другой вопрос, что к моменту их созревания придёт понимание, как надо оттягивать до последнего принятия решения по выбору технологий, типов хранений данных, вариантов реализации.

По разному. Я еще раз скажу, делаем так: ДА, хорошо это: НЕТ.

Даже код обрастает абстракцией, почитайте холивары функционального vs объектно ориентированно. Они даже на уровне кода хотя оторавтаься от этого. А вы на уровне требований и ООП шный псевдокод даете. А в БД физическую модель блин.

Ну ты кидай примеры, сейчас я не вижу альтернатив.

Я смотрю диаграмму доменов и у меня возникает вопросов больше, чем ответов