сам не до конца знаешь "требования"? Например, у заказчика как такового требования нет чтобы "всё работало быстро".
1. Но я знаю что он этого хочет и это "надо" учитывать.
Ну и туда же в топку -
Я не знаю как надо хранить продукты. Я могу показать что есть сейчас. Могу глянуть что и как на рынке используется. Блекло могу представить куда наш продукт заедет и какой там нужен будет список атрибутов.
2. Я так понимаю за это должен отвечать Архитект - которого ещё попробуй подбери, обычно они исходят из личных предпочтений просто.
архитект тебе нужен когда у тебя N команд и нужен кто-то кто будет заниматься координацией действий и стратегическим планированием. Тактические решения (как хранить атрибуты продуктов) - это сорян на тебе. То что "не знаю как" - ну да бывает, все там были. Пробуем, меряем, разбираемся "а почему не вышло" (увы "почему вышло" часто приводит к ложным выводам, а вот факапы весьма поучительны).
на тему "требований". Мне нравится фраза requirements means shut up. Есть "проблемы", есть "хотелки", есть "риски", это все надо приоритизировать, разбираться "для чего это понадобилось и откуда вылезло", разбираться откуда идет поток изменений этих требований (а они будут меняться, какие-то чаще какие-то реже). Вот все эти солиды и т.д. - это все про то что бы проектировать ориентируясь на эти самые потоки изменений требований (srp -> одна причина для изменений -> кто-то на это влияет - разделять под них).
Обсуждают сегодня