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

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

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

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

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

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

Спасибо!
  • Вопрос задан
  • 5032 просмотра
Решения вопроса 4
saboteur_kiev
@saboteur_kiev Куратор тега Python
software engineer
К сожалению с начальным знанием программирования - никак.
Вы не можете привлекать сторонних разработчиков, но уже привлекаете их через Тостер.

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

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

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

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

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

Так что начните писать код, через некоторое время появится структура и видение проекта.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 7
sergey-gornostaev
@sergey-gornostaev Куратор тега Python
Седой и строгий
Как мне кажется, архитектуру логичней разделить на микро-сервисы.

Вам кажется. Но вы — не Google.
Ответ написан
tema_sun
@tema_sun
В вашем случае методолгия "хренак-хренак и в продакшн" подойдет как нельзя лучше. Я не шучу. Наговнокодьте что-то работающее, ничего страшного в этом нет.
Ответ написан
Комментировать
Микросервисы + отсутствие опыта = головная боль и нерабочий код.
Ответ написан
Комментировать
@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 приложения.
Ответ написан
Комментировать
x67
@x67
Если вопрос "как?", то ответом будет плохо) Да, вы что то там придумаете, только потом вылезут косяки, серьезные недочеты, узкие места. Если нет денег, то лучше представить как это может выглядеть, разделить на мелкие части и отдельно разбираться в каждой из них, спрашивая у опытных кодеров, а нормально ли так, а что будет если вот так.
Ответ написан
Комментировать
Почитайте для начала про принципы solid и поищите на хабре статью про гексагональную архитектуру (хороший пример реализации этих принципов на практике). Также на ютубе есть лекции Сергея Немчинского по архитектуре и ооп https://www.youtube.com/watch?v=S-RjiMAxHio&list=P... Микросервисы - это частный (и достаточно радикальный) случай изоляции компонентов приложения, вам же для начала хотя бы монолитное приложение более-менее изолированно сделать, чтобы через полгода не оказалось, что ради внедрения одной фишки нужно перепиливать 97% кода. Плюс посмотрите, как делается rest api, оно не везде подходит, правда.
Ответ написан
Комментировать
Amfitorin
@Amfitorin
Программист
Для начала нужно определиться хотя-бы с минимальным набором функционала, которым должен будет обладать проект. После того, как набросали самые важные пункты, начинаем продумывать, какие данные нам для выполнения понадобятся. Т.е. к примеру обычный вход на сайт:
У нас есть Аккаунт, для него нужно знать id, login, pass, login_time. У каждого аккаунта есть свой User: id, name, eMail, itc. И так далее разбираете каждый пункт функционала и смотрите все ли необходимые данные у нас есть.

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

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

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

Войдите, чтобы написать ответ

Похожие вопросы