Приложение
Хотелки: заводит бизнес, хочет деньги в долг давать. Нужно
- Появился портальчик, возможно с мобильным приложением или мордой
- Приложение о двух концах: что бы приходили люди - должниик, им должнакрасиво предоставлена быть идея, какие то планы займа, звездочки можно будет рисовать ит.п., удобный пользовательский портал, подтолкнуть человека взять кредит. Второе, функциональность, что бы для себя любимого был тоже какое-то приложение, где можно было бы увидеть должников, когда кто взял кредит и когда вернет, и сколько черной прибыли бизнес получает, сколько от меня ушло, сколько обманулось.
- Первая часть приложения мотивирует взять кредит и там все педельно понтно как принять участие в этой офере.
- Мир современный, и че там, мобильная приложуха, красивые бантики. Воможно бизнес разовьется и будет что0то вроде модели смол маркета, может быть нагрузки будут офигеть большие. но пока это только стартапчик
Это то, что на момент этого времени бизнес выдает.
Тех лид, архитектор, скрам мастер, девелопер, тестировщик и бизнес аналитик - Я!
С чего начала:
Анализ требований и вычленение основной информации
Мобильная / Десктопная версия сайта ИЛИ Десктоп / мобильное приложение
Несколько ролей: Админ, клиенты, все на разных частях портала
UI/UX
Статистика по первому порталу (работает с клиентами)
Потенциально большая нагрузка на приложение
Потенциально схоже с моделью Small Market-a (возможно зайдут микросервисы)
Анализ верхнеуровневых архитектур, которые могут подойти под эти требования
По времени
Гексагональная - можно будет использовать разные блоки из цепочки для разных ролей, а также легко подсоединить разные версии UI
Микросервисная - независимые части работы портала: клиенты и админы - моб приложение и десктоп. Составной ui, который использует микросервисы.
Анализ имплеметационной архитектуры
- Необходимо несколько удаленных серверов для решения проблем с потенциальной высокой нагрузкой на сайт.
- MVP ~ MVVM - нет смысла перезагружать вьюшки, сделать основную статичной, а дополнения динамичными.
Анализ баз данных
- Потенциально 2 базы данных: 1-ая нереляционная, что бы хранить общую информацию для всех; 2-ая реляционная для хранения информации по клиентам + учет ролей;
Наблюдения:
- Лучше не начинать с микросервисной архитектуры начальную разработку приложения, потому что процесс получится достаточно объемным и будет тормозить развитие бизнес модели на начальных этапах;
- При этом если проект взлетит, то можно использовать микросервисную архитектуру, потому что она позволит справиться с высокими нагрузками, это обеспечит безопасность, потому что микросервисы изолированы и обращаются по API, можно будет гарантировать, что информация по статистике с сайта, будет отдана только тому сервису, которому она нужна. При этом еще и количество команд дожно быть равноценным количеству микросервисов.
- Есть возможность начать с монолитного приложения, либо с гексагональной архитектуры, да займет больше времени чем монолит, но ее будет намного проще менять и поддерживать разные кейсы, а также использовать разные частички для разных кейсов и ролей
- Как только в продакшн придут реальные пользователи и у нас будут микросервисы или гексагональная архитектура, имеет смысл начать поддерживать blue green deployment
- При этом, внутренности приложения, а вернее код имеет смысл структурировать используя паттерн