Облачное коммерческое объектно-ориентированное бизнес-приложение

George Nordic
Дата: 07.04.2016 12:21:04
Народ, ну кто тему ценную удалил? Тут у pisun'a душа болит, совета просит. Хорошо, что я сохранить успел.
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), наладили интеграцию с бэк-офисом, пора и про бизнес-аналитику подумать, но это уже отдельная песня.

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

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

    С Уважением,
    Георгий
  • Garya
    Дата: 07.04.2016 12:30:59
    Модератор: Тему удалил я, решив, что автор решил постебаться.
    Если это не стеб, обсуждайте, не возражаю.
    Axeleron
    Дата: 07.04.2016 12:38:02
    Garya

    Pisun до этого постинга в форуме Работа, если не ошибаюсь, рассуждал по поводу потери времени коммерческими программистоми из-за того, что в мужском туалете отсутствуют писсуары, а только кабинки. Рассчитывал потери от данного факта в количестве ненаписанных сотен строк коммерческого кода из-за каждого такого похода в туалет. Так что стеб это. В том форуме его тему быстро удалили модераторы.
    George Nordic
    Дата: 07.04.2016 12:51:26
    Garya, конечно, это стеб был чистой воды. Однако, эта тема запустила некий мыслительный процесс, результатами которого хотел бы с Вами поделиться. Однако, к сожалению, вопросов она родила еще больше... К самой моей больной теме - на чем писать Сервер Приложений, или что использовать в качестве СП и на чем писать бизнес-логику.

    С Уважением,
    Георгий
    Leonid Kudryavtsev
    Дата: 07.04.2016 13:51:19
    George Nordic
    Итак, коллеги, кто что думает про типовую архитектуру? Какой сервер приложений использовать, на чем писать бизнес-логику?

    1. Нужно определиться с термином бизнес-логика. Под ним тоже, много чего понимают. Например валидация входных данных, это бизнес логика или UI ?

    2. Тут тоже возможен смешанный подход. AFAIK например в OeBS часть бизнес логики на стороне апп-сервера (Forms, OAF), часть критической бизнес логики (расчеты, проведение транзакций) в БД.

    В принципе, можно посмотреть достоинства и недостатки всех подходов, для современных a la WEB приложений:

    2.1. Все на сервере приложений. Как крайний случай, Java, бизнес объекты в классах, Hibernate в полный рост.
    Недостатки:
    2.1.1. Данные в БД, а ВСЯ обработка на сервере приложений.

    Недостатки:
    Значительная потеря производительности на передаче данных и конвертации (ORM) данных.
    Увеличение трудозатрат при разработке/сопровождении т.к. конвертацию данных и лишний слой (ORM) в той или иной форме все равно нужно поддерживать.

    Достоинства:
    Еще один уровень абстракции при грамотной архитектуре, добавляет возможность масштабировать систему методом добавления блейдов с апп-серверами.
    Это так же может повысить отказоустойчивость к аппаратным сбоям (упал один апп-сервер)
    Насколько это компенсируется недостатки - не понятно.

    Спорное:
    Приложение может не зависить от вендора СУБД. Можно расматривать как достоинство, можно как недостаток.

    2.1.2. Все в БД или максимально близко к БД. Например PL/SQL HTTP картридж, Oracle APEX.
    Достоинства:
    Можно обеспечить максимально высокую производительность.

    Недостатки:
    Меньшее кол-во развитых фреймворков, фраймворки сильно привязаны к вендору и зависят от его капризов и не всегда логичных решений (вендора).

    2.1.3. Промежуточный подход

    Какая-то бизнес-логика (валидация и прочее) на апп-сервере, сложные бизнес процессы (вычисления,проводка транзакций и пр) в слое БД.

    Достоинства: компромиссный подход, теоретически можно взять самое лучшее от разных систем

    Недостатки:
    В штате сотрудников нужно держать специалистов по двум разным веткам продуктов
    Сложная архитектура, можно легко попасть в какую нибудь крайность или нагородить велосипедостроение

    Масштабирование СУБД обычно более дорогое, чем масштабирование апп-сервера. Поэтому AFAIK, например в OeBS, можно выделить даже 3-и слоя абстракции:

    UI-бизнес логика: Forms или OAF
    Основная бизнес логика в БД
    "Тяжелая" бизнес логика в виде concurent процессов

    AFAIK Другие системы также часто содержат что-то подобное concurrent manager'у из OeBS с целью вывести "тяжелые процессы" из СУБД или, как минимум, изолировать их работу от остальной работы СУБД (фоновое выполнение).

    IMHO & AFAIK
    Leonid Kudryavtsev
    Дата: 07.04.2016 14:00:11
    George Nordic
    ...Теперь к СУБД. Основные - это MS Sql и Oracle, ну и еще тенденция с Open Source, значит и PostgreSQL надо не забыть....

    "при всем богатстве выбора, другой алтернативы нет" ( C ) реклама 90-х

    1) MS SQL и Oracle это IMHO достаточно "сильные" БД, под которые можно найти специалистов.

    При этом, если брать учетные системы, то MS предлагает Axapta / Navision, а Oracle OeBS. Не знаю как сейчас, но вроде раньше на основе Акспате, Нависион полно было "самописок". И некоторые, вполне даже "тиражируемые".

    2) Если PostgreSQL, то ничего не хочу сказать плохого, но боюсь, найти специалистов готовых на Pg-языке писать сотни тысяч строк кода для бизнес-логики, будет достаточно сложно.

    Т.ч. остается только вариант: ВСЕ на сервер приложений и там for'ами, for'ами... Java и Hibernate в полный рост )))

    3) Ну и не забывает "наше все", т.е. 1C /сам с ним не знаком/
    George Nordic
    Дата: 07.04.2016 14:14:12
    Leonid Kudryavtsev, спасибо!
    1. Нужно определиться с термином бизнес-логика. Под ним тоже, много чего понимают. Например валидация входных данных, это бизнес логика или UI ?

    Тут тонкий момент. Например, если мы ограничимся маской ввода - это чистый UI. А вот lookup и валидация (например, поиск существующего контрагента) - это чистая бизнес-логика.

    Еще. А от чего зависит маска ввода? Кол-символов, там? Это же все может меняться, так что если мы завяжемся на UI, то надо будет отслеживать и БЛ, и изменение UI! Это сделает сопровождение системы весьма трудоемким.

    Поэтому на уровне БЛ необходимо предусмотреть настройку и элементов UI.
    Типа таблицы:
    Обязательное поле или нет
    Выводимое имя полное
    краткое
    Подсказка (все это - в разрезе языков)
    Тип данных: int, str...

    Str - максимальная длинна
    пароль / нет
    по какому полю lookup (и что из lookup доступно в разрезе безопасности)

    int
    Минимальне заначение
    Максимальное значение
    допустим ли ввод 0
    допустим ли ввод отрицательных значений
    real
    тоже + сколько знаков после запятой выводить и учитывать.

    Т.е. формировать словарь данных, и элементов данных, которые используются в системе и в UI.
    Еще и отображение бы - сколько может занимать на странице - это необходимо если мы будем авторазмещать элементы.

    В Microsoft Dynamics AX это называется АОТ. Хотелось бы узнать, есть ли фреймворки / сервера приложений, где это все уже реализовано.

    С Уважением,
    Георгий
    WebSharper
    Дата: 07.04.2016 14:19:18
    George Nordic,

    George Nordic
    Тут тонкий момент. Например, если мы ограничимся маской ввода - это чистый UI. А вот lookup и валидация (например, поиск существующего контрагента) - это чистая бизнес-логика.


    Если валидация ввода имеет значение с точки зрения бизнес логики (то есть какой бы UI не был данные считаются корретными только если они подпадают под условие) - это бизнес логика.
    George Nordic
    Дата: 07.04.2016 14:21:55
    Leonid Kudryavtsev, вот по второму полностью согласен - лучше все делать на AOS, оставляя в БД как можно меньше. Или то, что требует моментальной реакции (lookup?) или тяжелые расчеты, которые требуют ресурсов и могут быть запущены на периодической основе, когда нагрузка на систему низкая (но что нельзя вынести в аналитическую БД) - расчет себестоимости, например.

    Разноску заказов бы еще туда... но тут много бизнес-логики может быть задействовано, так что надо или на уровне БЛ, или гибрид.

    В общем, чем меньше пишем на уровне БД, тем проще сопровождать / портировать систему.

    С Уважением,
    Георгий
    ViPRos
    Дата: 07.04.2016 14:56:58
    George Nordic,