Как спроектировать архитектуру большого проекта с начальным знанием программирования?

Question

[RGoldvarg]

Всем привет! Я, безусловно, понимаю, что вопрос из серии "у тебя все хорошо с головой?! Нет опыта, нет архитектуры!".

Но все же, я хотел бы с Вами посоветоваться, т.к. сейчас нужно подготовить MVP и спланировать архитектуру большого проекта (проект будет представлять собой клиент-серверное приложение (WEB и Mobile).

Как мне кажется, архитектуру логичней разделить на микро-сервисы. Проект планирую разработать на Python/Django/PostgreSQL/MongoDB.

У меня базовые знания Python, SQL, и Django. К сожалению, на этапе разработки MVP нет возможности привлекать сторонних разработчиков с бОльшим опытом.

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

Спасибо!

Comments

[Adamos]

Имхо, вопрос из другой серии. "Нет необходимости развивать и поддерживать прототип - ничего страшного, что у него нет архитектуры" ;)

Answer 1

[Saboteur]

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

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

Как говорят - оптимизация до оптимизации не нужна.

У меня был опыт запуска интернет-магазина во времена, когда их было десяток на всю страну. Первый интернет-магазин мы писали почти полгода, внедрив в него тысячи фич, которые оказались невостребованными. Через год проект себя отбил, и мы заказали не редизайн а весь магазин с нуля. Разработка шла 2 месяца, обошлась в 4 раза дешевле. Функционал стал гораздо удобнее. И мы поняли, что в первый раз надо было тоже пойти по более простому пути, тогда мы мы запустились на 4 месяца раньше и отбились бы за полгода.

Comments

[RGoldvarg]

Спасибо! Хороший совет!

Answer 2

[amambaru]

Микросервисы значительно облегчат корректировку после MVP. Облегает горизонтальное масштабирование при росте нагрузки. При условии, что вы их правильно разделили.
Но при этом микросервисы дают много доп. проблем - накладные расходы на коммуникацию и управление.
Так ли они вам нужны?

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

Тут главное чтобы пробовать, проверять и переделывать. Много раз.

Answer 3

[Ptolemy_master]

Попробуйте начать с описания функционала. Что должна уметь делать система в минимальной версии? Выбрасывайте все лишнее. Запишите функции в виде списка, без деталей, например: "отправка и сохранение данных в серверной БД". Избавляйтесь от любых финтифлюшек, без которых может обойтись MVP.
Затем переходите к интерфейсу. Определите, что именно должна делать система, как это будет выглядеть. На бумаге нарисуйте экраны вашего будущего приложения. Отработайте с карандашом сценарии, вот буквально проговаривайте "пользователь кликает на эту кнопку, открывается такое-то окно".
После этого вам станет ясно, на какие логические модули можно разбить приложение, запишите их.
Теперь разберитесь с горизонтальными уровнями.
Первый слой обычно - это интерфейс веб- и мобильного приложений.
Второй слой - обработка пользовательских данных (что куда отправляется, какие окна открываются и т.д.).
Третий слой - работа с данными (какие объекты создаются, что с ними происходит).
Сама база данных - создайте объекты и связи между ними, можно использовать какое-нибудь приложение для моделирования типа Visio.
Затем в каждом уровне в соответствии со сценариями определяйте объекты, функции. Если не знакомы с ООП, познакомьтесь, это не займет много времени, но сэкономит вам его потом.

Answer 4

[TomasHuk]

Если перефразировать известную фразу:

Что бы вы не писали, все равно придется 3 раза переписывать.

Так что начните писать код, через некоторое время появится структура и видение проекта.

Answer 5

[Сергей Горностаев]

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

Вам кажется. Но вы — не Google.

Comments

[Александр Кузнецов]

Огромная благодарность за ссылку, отличная статья.

Answer 6

[tema_sun]

В вашем случае методолгия "хренак-хренак и в продакшн" подойдет как нельзя лучше. Я не шучу. Наговнокодьте что-то работающее, ничего страшного в этом нет.

Answer 7

[Станислав Б]

Микросервисы + отсутствие опыта = головная боль и нерабочий код.

Answer 8

[asd111]

1. Спроектируйте сначала API. Т.е. весь список URL и что по какому URL будет происходить. А еще лучше составить ТЗ. Например
ТЗ https://github.com/sat2707/hlcupdocs/blob/master/T...
запросы

GET /<entity>/<id> для получения данных о сущности
GET /users/<id>/visits для получения списка посещений пользователем
GET /locations/<id>/avg для получения средней оценки достопримечательности
POST /<entity>/<id> на обновление
POST /<entity>/new на создание

2. Затем проектируете БД и реализуете необходимые SQL запросы и запросы к mongoDB.
3. Затем начинайте реализовывать один URL за другим по очереди.
Шаги 2 и 3 можно делать в любой последовательности, но начать желательно с API, т.е. с полного списка URL приложения.

Answer 9

[x67]

Если вопрос "как?", то ответом будет плохо) Да, вы что то там придумаете, только потом вылезут косяки, серьезные недочеты, узкие места. Если нет денег, то лучше представить как это может выглядеть, разделить на мелкие части и отдельно разбираться в каждой из них, спрашивая у опытных кодеров, а нормально ли так, а что будет если вот так.

Answer 10

[Дмитрий Евграфович]

Почитайте для начала про принципы solid и поищите на хабре статью про гексагональную архитектуру (хороший пример реализации этих принципов на практике). Также на ютубе есть лекции Сергея Немчинского по архитектуре и ооп https://www.youtube.com/watch?v=S-RjiMAxHio&list=P... Микросервисы - это частный (и достаточно радикальный) случай изоляции компонентов приложения, вам же для начала хотя бы монолитное приложение более-менее изолированно сделать, чтобы через полгода не оказалось, что ради внедрения одной фишки нужно перепиливать 97% кода. Плюс посмотрите, как делается rest api, оно не везде подходит, правда.

Answer 11

[Сергей Шарков]

Для начала нужно определиться хотя-бы с минимальным набором функционала, которым должен будет обладать проект. После того, как набросали самые важные пункты, начинаем продумывать, какие данные нам для выполнения понадобятся. Т.е. к примеру обычный вход на сайт:
У нас есть Аккаунт, для него нужно знать id, login, pass, login_time. У каждого аккаунта есть свой User: id, name, eMail, itc. И так далее разбираете каждый пункт функционала и смотрите все ли необходимые данные у нас есть.

Также при проектировании базы обращайте внимание на типы связей https://technet.microsoft.com/ru-ru/library/ms1906... и опирайтесь на https://habrahabr.ru/post/254773/ .

После проектирования базы, начинаем писать классы обертки на клиенте/сервере, в зависимости от типа проекта и добавляем необходимые методы по сбору/обновлению/добавлению данных. И там уже будет точнее видно, есть ли у вас вся необходимая информация для работы или нужно еще что-то.

В конце берете визуальную часть и связываете ее с моделями. На этом этапе заполнятся все пробелы в моделях, если они останутся