Моя жёсткая самостоятельная архитектурная пробация по запуску вместе с коллегами, возможно, очередного, но хотелось бы верить - более инновационного Интернет-портала в сфере недвижимости для ЕС и США, где царят очень устаревшие решения. На факультативе к основной работе решил взвалить на себя функции и архитектора, и (как бывает в малом бизнесе) руководителя разработки. Как решился? Исключительно благодаря развитию AI в программировании (я конечно не адепт nocode, но для меня AI заменил мидлов и сделал достаточным работу только джунов), тк без оного взяться за что-то подобное было бы и смешно (не сильно то и профильно мне, к тому же тащить такое без бюджета - это лютая смелость), и инфантильно (зачем идти на 100% провал). Отмечу, что вероятность успешной разработки и сейчас то составляет 3/4, но тем не менее 75% того, что получится - это уже много, к тому же практика!
Качественные отличия проекта: возможность открыть записи на просмотр объектов недвижимости, обеспечение специальной эксклюзивно разработанной методике защиты от фейковых объявлений, внутренний факторинг (предоплата за арендаторов вперёд и подстраховка платежей на случаи просрочек), ну и конечно совместная аренда с подбором соседей по "коливингу".
Исходная ситуация и задача: задача - создание платформы недвижимости (аренда / покупка) с функционалом каталога объектов, онлайн подписания и управления контрактами в версии RC, а в более поздних версиях - расширенные функции в виде подписания смартконтрактов.
При этом - без использования каких-то готовых решений, тк большинство из представленных на рынке - мягко говоря устарели, а домклик или яндекс realty, увы, не продаются. Очевидно такая амбициозность показывает потребность масштабирования.
Дополнительная вводная - проект сразу планируется глобальным, так что i18n - наш лучший призрак сквозь весь проект.
Позитив - это в чистом виде greenfield проект, опыт в коде - 20 лет, опыт в devsecops со стороны cybersecurity, но вцелом понимаю концепцию.
Негатив - опыт работы в архитектуре (всего архитектурно я сделал меньше 10 проектов и все с поддержкой сильных архитекторов) не велик, хотя и есть опыт шефства (2 года) на очень большом финтех проекте в Ю.Америке, но когда ты в составе команды в 50 человек, со стороны консалтингово-аутсорсинговой линии, а общий штат только технических сотрудников Ваших компаний переваливает за 5000 человек, то всё гораздо проще, чем ехать де-факто одному с двумя помощниками.
Подготовка
Чтобы понять бизнес-логику - на этапе 1 работа выстраивалась с бизнес-девелоперами и финансистами, так как необходимо было хотя бы примерно понять точки нагрузок, что очень сильно зависит именно от бизнесовой составляющей проекта.
Язык программирования
Для меня один из самых простых моментов в подобных проектах - это выбор языка программирования для бэкенда. С учётом даже тех вводных, что были - это либо Rust, либо Go.
Почему не Node.js или Python:
1) у нас со старта достаточно большой микросервисный блок
2) зависимости (например в npm - вечная чехарда, хотя с AI стало намного проще) - так что сразу нет скажем всему, что на npm
К тому же основа нашего проекта - это многопоточность!
Rust - не выбран прежде всего по его более подходящей специфике для написания драйверов, и сложностей в работе с большим разрозненным API, а также его минус в перспективах столкнуться с гемороем на звене сети и JSON, где Rust не так силён.
Ну и признаться заменяемость команд на Go повыше, чем на Rust.
Очевидные плюсы Go для данного проекта: сам пишу на нём (потому да, признаюсь, выбор был навязан), скорость, простота, высшая адаптивность к OpenAPI, высокая стабильность, высшая прямая многопоточность, идеал для DCM/Hexagonal, простейший для DevOps/Docker, ну и моё любимое - бинарник вообще без зависимостей!
Фреймворки мы не брали (по крайней мере на старте), так как планируем обеспечивать и защищённость, и дополнительную структурность за счёт большого количества Middleware, которыми хотелось бы управляться напрямую и с полным контролем. Хотя данный момент спорный и было бы интересно услышать мнение как архитекторов, так и разработчиков.
Архитектура
Архитектуру я применил наверное самую закономерную для подобного проекта в LEAN реализации, когда нет ни особого бюджета, ни команды. С другой стороны хотя проект и находится в LEAN, но мир наш современный, а проект имеет все шансы на быстрое мастабирование, а поэтому была выбрана микро-сервисная модель с модульной архитектурой DCM (domain-centric modular architecture). При этом контейнеризация делается гибридно.
Итак DCMA архитектура была взята по следующим причинам:
1) надо двигаться очень быстро, а в команде я и два помощника
2) нам не до бюрократии, нет времени и ресурсов даже тесты писать
3) пайплайны есть, но горят сроки и людей нет
4) прицел на эволюциюи легкость масштабирования
5) отказоустойчивость за счет модульности
6) сервисы вполне себе автономны, а за счет message broker ещё более отказоустойчивы
7) не стыдно показать
Моё понимание выбора архитектуры также базируется на следующих best practice, что удалось изучить/прочувствовать за последние годы:
Если же с юморком относиться, то я бы сравнил выбор архитектуры и то, что потом происходит в процессе разработки со пероидом перехода от бандитизма к бизнесменам...
Собственный опыт показал, что на старте БД лучше использовать хостовую, как и Nginx роутинг, так как после роста и например при потребностях перехода на Kubernetes именно с БД и роутингом будут самые большие пляски с бубном. Но это на моём опыте, если у кого другой опыт и рекомендации - пишите в комментах.
Качественная архитектура и структурный подход дали свои плоды - примерно через 20 часов работы фронтовика и бэкенда, буквально за несколько итераций (2 часа) все 6 микросервисов, Kafka, PostgreSQL и конечно фронт были запущены! Отдельный плюс - это объём контейнеров, не могло не порадовать, что общий объём такого зверька идеален и не выходит за рамка 1Гб, что показывает прекрасные перспективы будущих итераций реализации проекта.
Конечно, до MVP ещё далеко, но показательно, что подобный достаточно большой ресурс теперь можно реализовать с технической точки зрения - втроём. Де-факто работал я (архитектура, руководство разработкой) и несколько джунов, которые превратились в AI операторов (я всегда за применение всего, что горит, если это ускорит написание кода). Из средств AI мы используем реально всё, что горит - Codex, ChatGPT5 сам по себе, Grok являются основными игроками оркестра, но также на подтанцовке применяем и DeepSeek, и Claude. И да, нисколько не стесняемся нашего AI каминг-аута.
Также буду рад советам/критике от профессионалов в разработке и архитектуре.