Каков порядок проектирования веб сервиса?

Question

[wawa]

1)Я написал какие проблемы должно решать моё ПО.
2) Из этого я выделил объекты предметной области.
Что делать дальше не ясно:
а) из (2) спроектировать интерфейс или
б) из (2) спроектировать схему БД или
в) из (2) спроектировать API (будет SPA)?
Каков порядок?
Можно кратко объяснить на пальцах?
Есть ли хорошие статьи или книги признанных гуру в это вопросе (м.фаулер, р.мартин,...)? Интересует некое краткое введение, позволившее разобраться именно в азах (ибо талмуд скорее запутает и отодвинет меня от практики).

Answer 1

[Артемий]

Не большой эксперт в маркетинге, но Вы забыли первым пунктом провести анализ рынка провести. Если спроса нет, то смысла делать нету, если это как бизнес планируется. А с технической точки зрения оптимальный вариант запилить MVP.

Comments

[wawa]

извините, но вопрос не об этом

[Артемий]

Это Вы извините, что ответ дал не линейный. Напишите потом по результату правильно я сказал или нет).
Если линейно отвечать, то Вам надо сделать проект системы. Я бы начал с ролей и доступного функционала, потом модель данных и скетчи интерфейса запилил. Дальше уже вопрос выбора методологии реализации проекта и технологического стека.

[wawa]

Артемий Прототипы, спасибо. То что вы описали - это всё делается до /во время шага (2). А что потом? я имею ввиду пункты а,б,в. Можно именно по этим пунктам пройтись?

[Артемий]

Это все взаимозависимые вещи, они параллельно развиваются в процессе проектирования. Изменения в одном элементе приводят к изменениям в других элементах. Тем не менее я считаю базовым элементом схему данных, т к на нее опираются API и интерфейс.

Answer 2

[stratosmi]

MVP

Comments

[wawa]

stratosmi, ок. Но и для MVP нужен какой-никакой алгоритм (последовательность) разработки. Можно объяснить как вы это делаете касаемо пунктов а,б,в?

Answer 3

[Vitaliy Orlov]

Любой веб-сервис, этот в конечном итоге интерфейс к базе данных, а точнее к данным которые в ней хранятся. Поэтому, в начале структура бд, затем апи (т.е. методы доступа к данным в базе), затем уже само приложение, которое будет использовать эти методы апи. Приложение уже дальше разделится на дизайн (т.е. макет приложения) и разработку SPA

Comments

[wawa]

ок. и так продолжая мой список:
3) схема БД
4) ендпойнты АПИ
5) UI
так?
а когда на 5ом шаге взаимодействие UI<->API приводит к N+1 проблеме, это признак ошибки на более раннем шаге или это норм и просто нужно подпилить API?

[Vitaliy Orlov]

wawa, обычно между п.1 и п.2, составляется список задач для решения "проблем" - этап называется проектирование. Исходя из него и разрабатывается все остальное. Если возникает проблема UI<->API, то это проблема именно проектирования. Она будет решаться по-ситуации и может затронуть любые этапы разработки (схема базы, endppoint-ы, UI). Например, изначальные требования были сделать авторизацию пользователей по email, но потом решили сделать двухфакторную авторизацию через соц. сети и смс. Такое изменение затронет и базу и endpoint-ы и UI.

Если же речь про то, что при разработке UI потребуются дополнительная информацию которую не предоставляют endpoint-ы, то это так же ошибка проектирования, тк все структуры данных и их формат должны быть определены на этапе проектирования.

Answer 4

[Сергей Егоров]

Идеальный сценарий проектирования - сначала писать тесты. Пишите тесты API например на Javascript + Node.js + Jasmine + Request. В тестах реализуйте запросы к API максимально удобным на ваш взгляд методом. Написали тест, можете реализовать конечную соответствующую точку подключения API. БД на начальном этапе вообще можно не использовать, оперируйте данными в памяти, в массивах или хешах для ускорения.