Лонг Кэт / Блог
Архитектура информационной системы: что это такое, зачем в этом разбираться заказчику и примеры подходов
В данной статье мы рассмотрим, почему заказчику важно разбираться (хотя бы на базовом уровне) в архитектуре IT-продуктов. Обсудим, на что обратить внимание при старте проекта, как архитектура может развиваться в дальнейшем, и как избежать существенного увеличения бюджета в случае неверно выбранной архитектуры на начальном этапе разработки. Также представим нашу архитектуру, которую считаем оптимальной для большинства информационных систем.
Этот материал актуален для закрытых корпоративных информационных систем, таких как собственные ERP и CRM системы, которыми пользуются до тысячи сотрудников внутри компании.
Этот материал актуален для закрытых корпоративных информационных систем, таких как собственные ERP и CRM системы, которыми пользуются до тысячи сотрудников внутри компании.
Архитектура информационной системы
Перед началом разработки информационной системы необходимо определиться с архитектурой приложения. Что же такое архитектура приложения? В Википедии дается следующее определение:
"Архитектура системы — принципиальная организация системы, воплощенная в её элементах, их взаимоотношениях друг с другом и со средой, а также принципы, направляющие её проектирование и эволюцию".
Простыми словами, это способ организации всего кода и компонентов системы, своего рода фундамент в строительстве.
Архитектура включает в себя заранее продуманные подходы к структуре системы, взаимодействию клиентской части (того, что видит пользователь) с данными на сервере. Она определяет, какие модули или отдельные сервисы есть внутри продукта, кто будет их развивать, наличие публичных или закрытых API. Также архитектура охватывает выбор языка программирования, фреймворков, паттернов, базы данных и прочего технологического стека.
Большинство дискуссий на тему архитектуры связано с выбором подхода: монолитное ПО или микросервисная архитектура. Мы подробно рассмотрели эту тему в отдельной статье, доступной по ссылке https://longcatdev.com/blog/monolit_microservice
"Архитектура системы — принципиальная организация системы, воплощенная в её элементах, их взаимоотношениях друг с другом и со средой, а также принципы, направляющие её проектирование и эволюцию".
Простыми словами, это способ организации всего кода и компонентов системы, своего рода фундамент в строительстве.
Архитектура включает в себя заранее продуманные подходы к структуре системы, взаимодействию клиентской части (того, что видит пользователь) с данными на сервере. Она определяет, какие модули или отдельные сервисы есть внутри продукта, кто будет их развивать, наличие публичных или закрытых API. Также архитектура охватывает выбор языка программирования, фреймворков, паттернов, базы данных и прочего технологического стека.
Большинство дискуссий на тему архитектуры связано с выбором подхода: монолитное ПО или микросервисная архитектура. Мы подробно рассмотрели эту тему в отдельной статье, доступной по ссылке https://longcatdev.com/blog/monolit_microservice
Какую архитектуру мы используем
Наш подход основан на использовании монолитной архитектуры с четким разделением на front-end и back-end. Это позволяет нам создавать надежные и масштабируемые системы, отвечающие потребностям современного бизнеса.
Back-end: сердце системы
Back-end представляет собой серверную часть, реализующую основную ценную логику системы. Здесь происходит обработка данных, выполнение бизнес-процессов и обеспечение безопасности.
Front-end: удобство для пользователя
Front-end — это клиентская часть, предоставляющая пользователю интуитивно понятный интерфейс для работы с системой.
Back-end: сердце системы
Back-end представляет собой серверную часть, реализующую основную ценную логику системы. Здесь происходит обработка данных, выполнение бизнес-процессов и обеспечение безопасности.
Front-end: удобство для пользователя
Front-end — это клиентская часть, предоставляющая пользователю интуитивно понятный интерфейс для работы с системой.
Взаимодействие между front-end и back-end
Общение между front-end и back-end происходит с помощью REST API. Это архитектурный стиль взаимодействия между сервером и клиентом, который обеспечивает гибкость и масштабируемость системы.
Преимущества использования REST API
Преимущества использования REST API
- Возможность использования back-end с различными видами клиентских приложений
- Легкость интеграции web-интерфейса и мобильных приложений
- Повышенная отказоустойчивость системы
Технологии, используемые в разработке
Back-end разработка
Базы данных
Мы используем реляционные базы данных, преимущественно PostgreSQL. Это позволяет нам:
Вывод — данная архитектура по нашему мнению оптимальна в случае разработки MVP версии большой системы, или в случае разработки системы, в которой в дальнейшем будет работать до 1000 человек.
- Язык программирования: PHP
- Фреймворк: Laravel
- Архитектурный паттерн: MVC (Model-View-Controller)
Базы данных
Мы используем реляционные базы данных, преимущественно PostgreSQL. Это позволяет нам:
- Эффективно структурировать данные
- Легко устанавливать связи между различными элементами системы
- Обеспечивать быстрый доступ к информации
- Подход: SPA (Single Page Application)
- Фреймворк: VueJS
- Дизайн: Material Design, реализуемый с помощью Vuetify
Вывод — данная архитектура по нашему мнению оптимальна в случае разработки MVP версии большой системы, или в случае разработки системы, в которой в дальнейшем будет работать до 1000 человек.
Дальнейшее развитие архитектуры
Когда информационная система (ИС) продолжает развиваться и наступает момент, когда выбранная архитектура уже не удовлетворяет запросам (например, на ней трудно реализовать поддержку требуемой нагрузки), бизнес сталкивается с двумя основными вариантами:
Бизнес может выбрать вариант с развитием текущей системы, например, преобразовать монолит в микросервисы. Или, как многие делают, развивать внутри монолита модули, а самые чувствительные из них вывести за его пределы. В любом случае, вариантов много, и, по нашему мнению, развивать выбранную архитектуру правильнее, чем строить новую информационную систему. Исключением может быть случай, когда, например, разработанная для одной компании система настолько хороша, что инвестор хочет превратить её в публичный продукт, которым будут пользоваться миллионы людей.
- Разработать новую информационную систему, предусмотрев гораздо более сложную архитектуру (например, с использованием микросервисов).
- Развивать текущую архитектуру.
Бизнес может выбрать вариант с развитием текущей системы, например, преобразовать монолит в микросервисы. Или, как многие делают, развивать внутри монолита модули, а самые чувствительные из них вывести за его пределы. В любом случае, вариантов много, и, по нашему мнению, развивать выбранную архитектуру правильнее, чем строить новую информационную систему. Исключением может быть случай, когда, например, разработанная для одной компании система настолько хороша, что инвестор хочет превратить её в публичный продукт, которым будут пользоваться миллионы людей.
Остались вопросы? Свяжитесь с нами удобным способом или оставьте заявку и мы ответим на ваши вопросы