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