Народ, ну кто тему ценную удалил? Тут у 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, конечно, это стеб был чистой воды. Однако, эта тема запустила некий мыслительный процесс, результатами которого хотел бы с Вами поделиться. Однако, к сожалению, вопросов она родила еще больше... К самой моей больной теме - на чем писать Сервер Приложений, или что использовать в качестве СП и на чем писать бизнес-логику.

С Уважением,
Георгий

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

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

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

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

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

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

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

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

С Уважением,
Георгий

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

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

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

С Уважением,
Георгий

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

Множество плюсов:
Например, заказ можно отгрузить если:
тип клиента: розница - по предоплате 100% или разрешению того-то и 50% или разрешению того-то и менее 50% оплаты.
тип клиента: текущий клиент, договор, пришел аванс >40%
тип клиента: текущий клиент, рамочный договор, баланс по договору не менее 20% от стоимости отгрузки

В зависимости от БП становятся возможны различные переходи и доступность элементов управления. И печать документов.

И еще - можно регламентировать время выполнение типовых операций, с их учетом планировать смены и распределять задания, контролировать нагрузку и кто как быстро справляется с тем или иным процессом.

А еще - прикрутить поколоночную СУБД, оттуда и lookup доставать с огромной скоростью, и для BI впоследствии использовать. Множество идей. Странно, что все с нуля пишут. неужели ничего полу-готового нет..

С Уважением,
Георгий

ViPRos, ок, мы поняли что у Вас это все есть :) Ну еще iskra framework. Причем я представляю, сколько было вгрохано десятков человеко-лет.

Вопрос: где-то еще есть?