Pull to refresh

Облачное коммерческое объектно-ориентированное бизнес-приложение для платного туалета или мысли об архитектуре

Reading time 5 min
Views 3.2K
Коллеги, всем доброго дня. На sql'e кто-то создал шутливую тему, но модераторы вырезали ее под корень. Однако, эта тема запустила некий мыслительный процесс, результатами которого хотел бы с Вами поделиться. Однако, к сожалению, вопросов она родила еще больше.
Итак, удаленный пост:
pisun
Облачное коммерческое объектно-ориентированное бизнес-приложение для платного туалета
У меня есть средний бизнес — три платных туалета. Считаю, что пришло время автоматизировать бизнес-процессы моего бизнеса с помощью коммерческих объектно-ориентированных облачных бизнес-приложений.

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

Сколько строк коммерческого кода должно содержать облачное коммерческое объектно-ориентированное бизнес-приложение для платного туалета?

Какие есть готовые коробочные облачные коммерческие объектно-ориентированные бизнес-приложения для платного туалета?


И некоторые мои мысли, которые, возможно, будут кому-то интересны.

Давайте разложим архитектуру на 3 основных составляющих:
* это фронт (то, что видит клиент, с чем он работает)
* сервер приложений (отвечает за обработку бизнес-логики)
* база данных (где хранятся данные)

так же надо учесть два важных момента: учетная система — это не самоцель. Нельзя просто так хранить все данные — они зачем-то нужны. Вопрос, какие данные мы будем хранить, для чего они нужны:
* для ведения финансовой деятельности предприятия
* для предоставления регламентрованной отчетности контролирующим органам
* для изучения потребностей клиента и возможностей их максимально удовлетворить (анализ поставляемых продуктов и услуг, изучение поведенческих моделей, прогнозирования спроса на основе исторических данных)
Следовательно, мы храним те данные, которые нам будут необходимы в дальнейшем — для ведения управленческого и бухгалтерского учета и бизнес-аналитики. Так же, для ведения бухгалтерского и кадрового учета необходимо вести учет ряда документов строгой отчетности — чеки/акты/счета/приказы и т.д., но ряд этих функций относятся к бэк-офису и могут вестись в отдельной системе.
Однако, иногда необходимо предусмотреть и фиксирование операций из фронт-системы (чеки, авторизация на выполнение операций по банковской карте и т.п.). А это иногда требует отдельного ряда решений по интеграции с платежными системами и/или POS-системами, а так же обеспечения безопасности подобных операций и восстановлению истории операций при сбое.
Таким образом, мы подходим к немаловажным вещам — это backup, который, в принципе, возможен стандартными средствами СУБД, и безопасности.

Вернемся к архитектуре:
* сервер приложений (отвечает за обработку бизнес-логики)
* база данных (где хранятся данные)
Вопрос, на каком из этих слоев необходимо обеспечивать безопасность и разделение доступа?

Есть 3 подхода:
1. На уровне сервера приложений
Мы даем всего несколько ролей, и Сервер приложений (AOS) под ними уже обращается к БД, разграничение ролей к БД — зашито в СП, разграничение по данным / на уровне записей ведется средствами AOS.
Плюсы: Легкость администрирования. Нет сильной зависимости от СУБД.
Минусы: Бизнес-аналитика обычно цепляется напрямую в БД, и видит все, без учета ограничений на уровне СП. Реализация доступа бизнес-аналитики через СП — очень нетривиальна и может сильно нагрузить СП.

2. На уровне СУБД
Все роли пользователей, уровень доступа, разграничение по данным / на уровне записей задаются на уровне СУБД. Таким образом, надо сильно допиливать сервер приложений, чтобы не усложнять администрирование системы: настроили в рабочем месте администратора, и автоматом роли применились на уровне БД.
Плюсы: BI / отчетная система может цепляться непосредственно к БД под тем или иным пользователем, нет необходимости в дополнительном контроле прав доступа
Минусы: Сложность реализации, так как имплементация данного механизма сильно зависит от использования той или иной СУБД.
Сложность тестирования — выпадают нули, и надо понять, почему так: это ошибка в логике приложения или в настройке прав доступа. Возможно, дублирование администрирование — завели пользователя, прицепили к нему бизнес-логику, а потом донастроили права в БД.

3. Смешанный
Мы даем всего несколько основных ролей, и ряд «типовых», различие в доступе которых отличается на уровне фильтров.
Сервер приложений (AOS) для ряда основных ролей — обращается к БД, разграничение ролей к БД — зашито в СП
Для «типовых» — АОС заходит с ограничением на каждую роль, дополнительные ограничения по данным / на уровне записей ведется средствами СУБД с помощью фильтров.
При всех плюсах — легкости администрирования, несложной настройке BI-систем (фактически, придется дублировать фильтры для пользователя в СУБД и BI системе) это самый трудозатратный способ реализации.

Итак, если с фронтом определиться несложно — мы живем в век мобильности, следовательно, надо предусмотреть что наше приложение будут открывать с любого вида устройств. Значит, надо будет писать «тонкие клиенты» под iOS / Android / Win / Linux или просто написать фронт, который будет открываться в любой среде — например, из любого браузера. Так как с Java сейчас неопределенная ситуация, кто-то отказывается от JVM, кому-то запрещено политиками безопасности, то я бы смотрел в сторону HTML 5 (6...). Хотя, опять же, вопрос, будет смотреться Ваше приложение на мониторе 24" и на телефоне 4" — тут или автомасштабирование, или подмена клиента (выводим только основное, или бьем по экранам / элементам) или снова — писать тонкие клиенты…
Ладно, давайте представим, что мы выбрали HTML5. Ок, даже Grid можно реализовать.
Теперь к СУБД. Основные — это MS Sql и Oracle, ну и еще тенденция с Open Source, значит и PostgreSQL надо не забыть. Если предполагается большое кол-во распределенных инсталляций, то надо присмотреться к Hadoop / Mongo и т.п., но это не реляционные СУБД, решающие определенные задачи, вы не не поисковик или соц.сеть собираетесь делать? Давайте пока на первых 3 остановимся, а лучше — хотя бы с одной начнем. Или предусмотрим некую независимость от СУБД, оставив только присущие всем СУБД функции.

На чем же реализовывать бизнес-логику? Что станет связующим элементом между браузером и СУБД?

А вот открытый вопрос. Я бы и сам послушал коллег

Если мы предпочитаем технологии Oracle — тогда oracle apex. Если перерастем — то Fusion Middleware в полный рост + WebLogic
Если мы склоняемся с Open Source — тогда Apache Tomcat. Да, если инсталляция большая, тогда бы еще и балансировщик нагрузки, типа PgBouncer и Nginx. Если распределенная — то еще и менеджер ресурсов кластера Pacemaker, обмен сообщениями между узлами кластера Corosync и т.п.
Если сторонник технологий MS — то Студию и вперед. Увы, не подскажу готовых AOS в их стеке. Только сторонние фреймворки типа К2.

Собрали сервер приложений, интегрировались с банк-клиентом (возможно, задействовав брокер гарантированной доставки сообщений Apache ActiveMQ), наладили интеграцию с бэк-офисом, пора и про бизнес-аналитику подумать, но это уже отдельная песня.

Итак, коллеги, кто что думает про типовую архитектуру? Какой сервер приложений использовать, на чем писать бизнес-логику?

Кто что думает?

С Уважением,
Георгий
Tags:
Hubs:
0
Comments 2
Comments Comments 2

Articles