Где наша бизнес-логика для идеалиста? Бизнес логики


Где наша бизнес-логика для идеалиста? / Хабр

В этой статье я попробую сам разобраться в себе и в своих аргументах. Для начала попробую оппонировать автору статьи, перевод которой нашел на хабре Где наша бизнес-логика, сынок?. Её писал такой же идеалист, которым я был еще лет 10 назад. Поэтому по сути в этой статье я буду спорить сам с собой. Дело в том, что чем больше приложений я разрабатываю тем больше красивые теории перестают вписываться в идеальные схемы. Идеальные схемы хороши тем, что они просты. Вас спрашивают где бизнес слой? И ты легко можешь сказать на стороне клиента или на стороне сервера. Если смешенно многозначительно крутят носом и говорят «гавно-код». С этим я не согласен. Реальный мир не вкладывается в идеалистические концепции, точнее его можно туда запихнуть, но мы от этого скорее потеряем. Поэтому вначале подсознательно я понимал, что есть разные случаи. А теперь все более пытаюсь сформулировать, что влияет на то или иное решение по размещению бизнес логики. Здесь мы оставим красивые теории без аргументации молодым утопистам желающим простых решений.
Объектное и процедурное программирвоание в свете баз данных

Автор упомянутой статьи пишет:

… давайте четко определим: что же такое бизнес логика.… Сервер базы данных – это уровень хранения. Базы данных разработаны для хранения, получения и обновления данных с максимально высокой эффективностью.… Базе данных не должно быть дела до того, что такое покупатель, она должна заботиться только об элементах, используемых для хранения покупателя. У базы данных не должно быть возможности разобраться, какие таблицы должны хранить объект покупатель, и она должна работать с таблицами не обращая внимания на объект покупатель. Задача базы данных – хранить ряды в таблицах, которые описывают покупателя. Кроме базовых ограничений вроде каскадной целостности, типов данных, индексов и пустых значений, база данных не должна иметь функционального знания о том, что же из себя представляет покупатель в бизнес слое.

причем пишет об этом как о определении. А обосновывает только когда говорит о клиент-серверной архитектуре:

Достаточно быстро стало понятно, что можно сократить нагрузку на сеть и централизовать логику для уменьшения постоянных затрат на развертывание, перенеся большую часть бизнес логики на сервер. Архитектурно сервер был хорошо подготовленным местом в клиент-серверной системе, но база данных как платформа давала мало возможностей. Базы данных были спроектированы для хранения и выдачи и в их архитектуру не были заложены возможности расширения в направлении бизнес логики. Языки хранимых процедур в базах данных были разработаны для базовых преобразований данных, чтобы поддержать то, на что не хватало SQL. Языки хранимых процедур разработали для быстрого исполнения, а не для обслуживания сложных задач бизнес логики.

В большинстве случаев среднее звено существовало только для управления пулом соединений, но в некоторых случаях бизнес логика начала перемещаться в среднее звено потому, что языки разработки (C++, VB, Delphi, Java) гораздо лучше подходили для реализации бизнес логики, чем языки хранимых процедур. Вскоре стало очевидно, что среднее звено –это наилучшее место для бизнес логики.

Так и завязывается противоречие. Получается, что "бизнес логика начала перемещаться в среднее звено потому, что языки разработки (C++, VB, Delphi, Java) гораздо лучше подходили для реализации бизнес логики". Но какие характеристики упомянутых языков разработки лучше, чем процедурный язык SQL? Условия и циклы, разделение на процедуры есть и у SQL. Этим SQL ничем не отличается от любого процедурного языка, такого как C++, VB, Delphi, пока в действие не вступает объектная методология. Поэтому утверждение «языки хранимых процедур разработали для быстрого исполнения, а не для обслуживания сложных задач бизнес логики» очень поверхностное и достаточно спорное.

Язык SQL в части управления процедурной логикой ничем не отличается от других языков. Но действительно в нем не реализована объектная методология, которая позволяет управлять более сложной логикой. Поэтому отсюда будем утверждать, что если Вы не используете объектную методологию для управления бизнес логикой — вам должно быть все равно на чем писать алгоритмы — на SQL или Cи. А соответственно, совершенно без разницы будет ли на сервере находится т.н. средний слой скажем на Cи, который будет обращаться к базе данных, используя ее как хранилище, или же в базе данных будут хранимые процедуры SQL, которые так же будут обращаться к таблицам данных. Последние даже предпочтительнее, т.к. устраняет избыточный слой.

Но подчеркну, что все это справедливо только для не объектных языков. Когда же мы хотим получить преимущества от объектной методологии, вот только тогда мы и идем на то, чтобы данные в базе данных отделить от бизнес логики, и бизнес логикой управлять отдельно и на другом языке отличном от SQL.

Реляционная модель базы данных — это часть бизнес-логики

Когда автор статьи пишет "Сервер базы данных – это уровень хранения. Базы данных разработаны для хранения, получения и обновления данных с максимально высокой эффективностью.… Базе данных не должно быть дела до того, что такое покупатель, она должна заботиться только об элементах, используемых для хранения покупателя. У базы данных не должно быть возможности разобраться, какие таблицы должны хранить объект покупатель, и она должна работать с таблицами не обращая внимания на объект покупатель." — он не совсем точен. Сервер базы данных, конечно же выполняет задачу хранения данных, но это совсем не единственная его задача. На сервере базы данных также происходит обработка данных. Автор хочет свести обработку данных к элементарным операциям insert, update, delete над одной таблицей и сказать нам, что все остальное является бизнес-логикой, которую нужно отделить.

Но он забывает, что реалиционная модель данных, представляет данные в т.н. 3-ой нормальной форме, чтобы исключить избыточность хранения данных. Уже одно это говорит о том, что данные в базе данных не хранятся в одной таблице, а реляционно разложенны по набору таблиц. И совершенно не возможно обновить данные о «покупателе» используя только одну таблицу. Автор прямо не говорит о объектной методологии, но использует слово «объект покупатель». Думаю излишнее говорить, что объект покупатель прямо не соответствует таблице покупатели. Объект покупатель как правило выбирается сложным select`ом из набора связанных (join) таблиц. А как же он представляет обновление данных объекта покупатель? Не будет ли он в бизнес-логике с его ограничением на работу с одной таблицей на SQL заниматься логикой хранения реляционных данных? Именно такая логика хранения данных объекта покупателя в нескольких реляционных таблицах очевидно и должна быть реализованна в одной хранимой процедуре.

Еще мы должны договорится о том, что данные хранящиеся в таблицах базы данных это первичные данные, а то, что мы вытаскиваем из нее для обработки или для показа пользователю — это вторичные данные. Поэтому когда мы говорим о бизнес-логике, мы должны отдавать себе отчет, что когда мы разрабатывали реляционную модель данных мы уже задали часть правил бизнес-логики. Модель хранения данных уже накладывает определенные условия на бизнес-модель логики. С помощью хранимых процедур мы можем абстрагироваться от способа хранения данных, и тогда предоставить наружу данные в смысле объектов, а не реляционных таблиц. Тогда бизнес-логика будет работать со вторичными данными в объектной методологии.

В этих двух разделах я пока просто убрал перегибы, на которых настаивал автор, и думаю есть его последователи. Далее мы пойдем дальше и посмотрим в каких случаях эффективно, а в каких не эффективно использовать объектную методологию работы с бизнес-логикой.

Пошатнем мир идеалиста

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

Одно из приложений, которое я реализовывал, была реализация платежной системы в банках. По сути это одна форма, представляющая формуляр платежного поручения. Кроме всего прочего, этот форма умела осуществлять т.н. попутные конвертации. Причем конвертации могли быть различные: когда не хватает денег на платеж должно быть предложенно конвертировать из другой валюты, причем сумму и комисию за платеж можно конвертировать с разных валют, можно брать овердрафт на платеж, а тариф конвертировать, можно частично платить тем что имеешь, а не достающую сумму конвертировать ну и т.п. достаточно сложная бизнес-логика достаточно жестко переплетенная с интерфейсом пользователя.

Но один из заказчиков в один прекрасный день захотел, чтобы платежные поручения обрабатывались и проводились в системе автоматически, причем платежное поручение нужно было проверить на соответствие ряду требований, если не хватает денег также как и ранее в диалоге с банковским работником создать конвертацию или взять овердрафт, но в этот раз надо было исключить из этого процесса банковского работника полностью. Были установленны приоритеты валют — в каком поряке конвертировать, в каких случаях, что и как разрешенно, а в каких случаях выдавать на проверку банковскому работнику. Цель вполне понятна в 90% случаев банковский работник полностью разгружался от работы по верификации платежных поручений.

Итак, встал простой вопрос — в диалоге пользователя в 90% случаев отпала необходимость. Если предположить, что раньше мы хорошо отделили интерфес пользователя от бизнес-логики, то у нас уже реализована бизнес-логика в сложном наборе объектов. Проблема только в том, что инициация работы этой бизнес-логики ориентировалась на диалог пользователя. А сейчас нам надо было выбирать платежные поручения из базы данных, заменить логику инициации по диалогу пользователя другой логикой автоматической обработки, обработать уже имеющейся логикой, и записать проведенное платежное поручение обратно в базу данных. Причем проводка платежного поручения — это автоматическое создание баланса и еще одна сложная процедура. Причем не забыть еще конвертации, овердрафты, которые отражаются в балансе конечно отдельными документами и по другим статьям.

Встает вопрос — зачем всю эту информацию откачивать из базы данных, обрабатывать и записывать обратно? Такой необходимости вообще нет, т.к. пользователь полностью исключен из автоматической обработки платежей. Соответственно, все это может решиться на уровне обработки данных, которым и занимается в полной мере сервер базы данных.

А ведь, то что мы раньше выделили бизнес-логику в объектной методологии нам совсем не пригодилось, т.к. нам стало нужно иметь просто одну хранимую процедуру, которая просто проведет платежное поручение из очереди. Да в этом случае бизнес-логика попадает в хранимые процедуры.

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

3-х звенная архитектура, предполагает, что бизнес-логика находится на сервере (среднее звено) и для данной задачи минует клиента. Но во-первых, мы ввели лишние звено, а во-вторых, оно снова же выполняет в данной задаче роль клиента — откачивает данные из базы данных, их обрабатывает и записывает назад. И все это только для того, чтобы было удобно на объектном языке обрабатывать бизнес-логику. Не велика ли цена?

Второй случай не заставил себя долго ждать. Нужно было реализовать систему коммунальных платежей. По сути это еще одна надстройка над платежной системой. Коммунальные платежи содержат некоторую дополнительную специфичную информацию, такую как описание услуги, показание счетчиков, задолженности, и ряд технических о том через какую систему они платятся, как часто и т.п. И уже потом на основании коммунального поручения создается настоящие платежное поручение. Функция банка тут в том, чтобы накопить у себя из различных каналов поступления оплаты по услугам и одним сводным платежом сделать перевод на счет предприятия предоставляющего услуги. Поэтому коммунальные поручения с привязанными к ним платежными поручениями собираются в пакеты. И опять же в пакеты попадают поручения по определенной бизнес-логике, и опять же в этом отсутствует интерфейс пользователя. Пакеты формируются автоматически по определенным критериям. И мир вертится без участия пользователя.

Теперь наученные тем, что бизнес-логика эффективна в базе данных логику формирования реального платежа на основании коммунального поручения мы осуществляли хранимой процедурой. Причем она использовалась как при создании коммунального поручения через интерфейс, а также как API к внешним (например, бухгалтерским) программам по отношению к банковской системе, а так же как прием коммунальных поручений через интернет-банк. Было ли это возможно если бы бизнес-логика была бы не в хранимой процедуре, а например в объектах на C#? Да, возможно, но путем введения совершенно излишнего среднего звена с дублированием методов получения/записи данных в базу данных.

Но когда мы доходим до пакетов, бизнес-логика диктует нам необходимость отбирать платежи по определнным признакам, проставлять одинаковые признаки (такие как принадлежность пакету, статус, текстовое пояснение пользователю) сразу большому набору платежей, осуществлять подсчет общей суммы и количества платежей в пакете используя функции SUM(), COUNT()… и я бы очень удивился если все это было бы реализованно в объектно ориентированной методологии, а не с использвоанием SQL. И когда в заключении после формирования пакета надо сформировать сводный платеж, и не уметь его сформировать из SQL — это разве достоинство того, что бизнес-логика находится не в базе данных?

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

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

Другая крайняя точка зрения

Если автор обсуждаемой статьи высказывает (на мой взгляд не достаточно обоснованно) одну крайнию точку зрения, согласно которой в базе данных не должно быть бизнес-логики. То можно высказать и другую крайнию точку зрения, согласно которой вся бизнес-логика может находится в базе данных. Единственно чего мы при этом лишаемся — это отсутствие объектной методологии в работе с бизнес-логикой.

В каких случаях это может быть оправдано?

Не так давно я писал о своем стартапе по созданию браузерной игры. И там действительно используется именно такой подход — вся бизнес-логика в базе данных. Чем это вызвано?

Веб-разработка, все таки достаточно специфична — клиентом является браузер и управляется всегда другим скриптовым языком (JavaScript). А задача сервера сводится к формированию HTML страниц для клиента. В этой связи у нас пропадает возможность управлять клиентом с помощью объектно-ориентированного языка (если только не считать JavaScript — объектным языком, которым он в полной мере не является). Соответственно, пропадает основной стимул вытаскивать данные из базы, чтобы создавать бизнес-модель вне базы в клиенте.

Почти тоже самое и на сервере. Тут конечно мы не лишены объектной методологии, если например, используем ASP.NET. Но задача сервера сводится к формированию HTML — страниц. А точнее к наполнению HTML — страниц данными, которые получаются хранимыми процедурами как правило простым select- запросом. Да, конечно еще остаются реакции на нажатие кнопок и клики на check-боксы и т.п. Но в отличии от офисных приложений с формами, где осуществляется достаточно сложная логика взаимодействия с пользователем, веб-страницы крайне упрощены, т.к. реакция как правило сводится к формированию другой HTML — страницы с другими данными.

В голом остатке, в веб-приложениях остаются задачи, которые выполняются «за кадром». К примеру, в браузерной игре (экономической стратегии с элементами РПГ), которую я реализовываю — это такие задачи, как проверка процесса производства по созданию продуктов, расчет характеристик рынка (цен покупки), осуществление закупок, выборы в гильдиях, осуществление долгосрочных поставок и т.п. Все они выполняются с определенной переодичностью в игре, они составляют 60-80% всей бизнес-логики, и все они происходят «за кадром» игрока. И было бы странно, если бы пришлось для осуществления этих задач вытаскивать первичные данные и представлять их в виде объектной модели, только затем, чтобы записать эти данные после обработки обратно. Выборки данных (select-запросы) так или иначе реализуются хранимыми процедурами.

Остаются лишь реакции на нажатия кнопок, и прочие взаимосвязи с интерфейсом. Но для JavaScripta опять все сводится к получению порции данных, и написания клиентских алгоритмов, которые вряд ли можно назвать бизнес-логикой, это скорее логика отображения интерфейса. А оставлять бизнес-логику, которая будет обслуживать интерактив работы с пользователем через HTML — страницы в объектной модели, но из-за простоты этого интерактива это скорее накладно, чем дает какие -то преимущества.

Вот и получается, что для веб приложений практически вся бизнес-логика находится в базе данных. Это опять же позволяет независимо работать ядру игры в базе данных, не зависимо от работы веб-сервера. Позволяет писать любые другие клиенты, обращаясь к хранимым процедурам как к API. Минус остается лишь в одном — не очень удобно без объектного языка реализовывать бизнес-логику, но так как часто это логика работы не с одним объектом, а опять же это групповые операции над многими сущностями в базе данных, то не все так однозначно.

Других архитектурных минусов, наличия бизнес-логики в базе данных попросту нет.

habr.com

database - Бизнес-логика: база данных или прикладной уровень

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

  • ремонтопригодность
  • надежность

Re. ремонтопригодность: для обеспечения эффективной будущей разработки бизнес-логика относится к той части вашего приложения, которая проще всего отлаживать и контролировать версию.

Re. надежность: когда существует значительный риск несогласованности, бизнес-логика принадлежит слою базы данных. Реляционные базы данных могут быть разработаны для проверки ограничений на данные, например. не позволяя значения NULL в определенных столбцах и т.д. Когда в дизайне приложения возникает сценарий, когда некоторые данные должны находиться в определенном состоянии, которое слишком сложно выразить с помощью этих простых ограничений, может иметь смысл использовать триггер или что-то похожее в слое базы данных.

Триггеры - это боль, чтобы быть в курсе событий, особенно когда ваше приложение должно работать на клиентских системах, к которым у вас даже нет доступа. Но это не означает, что невозможно отслеживать их или обновлять. Аргументы С.Лотта в его ответе, что это боль и хлопот, полностью верны, я второй раз и буду там. Но если вы сохраняете эти ограничения в виду, когда вы впервые создаете свой уровень данных и воздерживаетесь от использования триггеров и функций для чего угодно, кроме абсолютных потребностей, это управляемо.

В нашем приложении большинство бизнес-логик содержится в уровне модели приложения, например. счет-фактура знает, как инициализировать себя из данного заказа клиента. Когда куча разных вещей изменяется последовательно для сложного набора изменений, подобных этому, мы сворачиваем их в транзакции, чтобы поддерживать согласованность, вместо того, чтобы выбирать хранимую процедуру. Вычисление итогов и т.д. Осуществляется с помощью методов в модельном слое. Но когда нам нужно денормализовать что-то для производительности или вставить данные в таблицу "изменения", используемую всеми клиентами, чтобы выяснить, какие объекты они должны истекать в кеше сеанса, мы используем триггеры/функции на уровне базы данных, чтобы вставить новую строку и отправьте уведомление (Postgres listen/notify stuff) из этого триггера.

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

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

Конечно, все меняется, когда вы выходите за пределы области РСУБД в системы хранения данных, такие как Amazon SimpleDB и Google BigTable. Но это другая история:)

qaru.site

Бизнес-логика Википедия

Бизнес-логика — в разработке информационных систем — совокупность правил, принципов, зависимостей поведения объектов предметной области (области человеческой деятельности, которую система поддерживает). Иначе можно сказать, что бизнес-логика — это реализация правил и ограничений автоматизируемых операций. Является синонимом термина «логика предметной области» (англ. domain logic).

Проще говоря, бизнес-логика — это реализация предметной области в информационной системе. К ней относятся, например, формулы расчёта ежемесячных выплат по ссудам (в финансовой индустрии), автоматизированная отправка сообщений электронной почты руководителю проекта по окончании выполнения частей задания всеми подчиненными (в системах управления проектами), отказ от отеля при отмене рейса авиакомпанией (в туристическом бизнесе) и т. д.

В фазе бизнес-моделирования и разработки требований бизнес-логика может описываться в виде:

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

На жаргоне разработчиков программного обеспечения «бизнес-логикой» также называются программные модули, её реализующие, и уровень системы, на котором эти модули находятся (англ. business logic layer, domain logic layer).

В многоуровневых (многослойных) информационных системах этот уровень взаимодействует с нижележащим уровнем инфраструктурных сервисов (англ. infrastructure layer), например, интерфейсом доступа к базе данных или файловой системе (англ. data-access layer, DAL) и вышележащим уровнем сервисов приложения (англ. application services layer), который уже, в свою очередь, взаимодействует с уровнем пользовательского интерфейса (англ. user interface layer) или внешними системами.

См. также[ | код]

ru-wiki.ru

Бизнес-логика

Материал из Seo Wiki - Поисковая Оптимизация и Программирование

Бизнес-логика — в разработке информационных систем — совокупность правил, принципов, зависимостей поведения объектов предметной области (области человеческой деятельности, которую система поддерживает). Иначе можно сказать, что Бизнес-логика — это реализация правил и ограничений автоматизируемых операций. Является синонимом термина «Логика предметной области» (Domain Logic).

Проще говоря, бизнес-логика - это реализация предметной области в программной системе. К ней относятся, например, формулы расчёта ежемесячных выплат по ссудам (в финансовой индустрии), автоматизированная отсылка е-мейла руководителю проекта по окончании выполнения частей задания всеми подчиненными (в системах управления проектами), отказ от отеля при отмене рейса авиакомпанией (в туристическом бизнесе) и т. д.

В фазе бизнес-моделирования и разработки требований бизнес-логика может описываться в виде:

  • текста
  • концептуальных аналитических моделей предметной области (онтологии)
  • бизнес-правил
  • разнообразных алгоритмов
  • диаграмм деятельности
  • графов и диаграмм перехода состояний
  • моделей бизнес-процессов.

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

На жаргоне разработчиков ПО «бизнес-логикой» также называются программные модули, её реализующие, и уровень системы, на котором эти модули находятся (Business Logic Layer, Domain Logic Layer).

В многоуровневых (многослойных) информационных системах этот уровень взаимодействует с нижележащим уровнем инфраструктурных сервисов (Infrastructure Layer), например, интерфейсом к базе данных или файловой системе (Data-Access Layer, DAL) и вышележащим уровнем сервисов приложения (Application Services Layer), который уже, в свою очередь, взаимодействует с уровнем пользовательского интерфейса (User Interface Layer) или внешними системами.

См. также

en:Business logic es:Lógica de negocio it:Business logic ja:ビジネスロジック ko:비즈니스 로직

www.sbup.com

Бизнес-логика — заметки Максимала

Самые главные причины, по которым очень многие, казалось бы умные, люди терпят поражение или очень долго развиваются в бизнесе: огромная волатильность параметров, немалая роль случая, частая победа нестандартных и алогичных ходов. Школа и университет учат «делайте как написано — будут хорошие отметки». А в жизни всё не так. Нигде не написано, как делать. В жизни, для начала, надо просто делать; потом делать не как написано; потом делать хорошо; потом можно и выпендриваться, уча других, как надо делать.

Друг рассказал пару месяцев назад:

Подняли цены на оборудование в интернет-маганизе в среднем на 15%. Продажи резко пошли вверх.

Надо сказать, что до этого они продавали товар с минимальной наценкой. Они были на первых позициях в Яндекс.Маркете по своей сфере (потому что предлагали самые низкие цены). Я совершенно точно знаю, что дешевле них не продавал никто. Часто шли на ухищрения, чтобы опустить цены ниже планки, установленной главными дилерами оборудования. Из-за этого, минимум два крупнейших поставщика от них отказались, когда узнали про то, что они демпингуют цены. (Производители и дилеры договариваются о планках рыночных цен, а вы как думали). Конечно же, по вышеперечисленным причинам еле сводили концы с концами.

Теперь, когда они стали «как все», и даже дороже, у них есть стабильный прирост покупателей. И тенденции к снижению нет и подавно.

При этом, все же не дураки и прекрасно понимают, что товар абсолютно тот же, что и был. Только дороже.

Как подобные ситуации можно объяснить логически?! Только я знаю, как. Никак.

Ладно. Раз заметка о логике, добавим немного логики. Катя объяснила этот эффект синдромом дешёвого пива (за справками лучше к ней). И вернёмся к ребятам. Теперь у них в загашнике появилось волшебное слово. Скидка! Раньше они не могли позволить себе сделать даже четырёхпроцентную скидку постоянным заказчикам, иначе работали бы себе в убыток. Теперь они безболезненно могут сделать и 10, и 15 процентов, оставаясь в прибыли. При отсутствии слова «скидка» клиенты могут уйти, даже не посмотрев на то, что у тебя самые низкие цены на рынке. А слово «скидка» магическим образом действует на покупателей, начисто обрубая способность логически мыслить.

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

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

maximals.ru

Логика бизнеса

Продукты и услуги

Линейка продуктов, разработанных «Логикой бизнеса» (ГК «АйТи»), получила название «Логика ECM» (ранее «БОСС-Референт»). Она включает СЭД на различных платформах, электронные хранилища данных и архивы документов, решения для юридически-значимого документооборота.

В качестве базовых платформ могут выступать системы IBM Notes/Domino, IBM FileNet, Alfresco / МСВСфера Инфооборот и JBoss.

По результатам исследований IDC Россия «Программное обеспечение для управления контентом в России 2013-2014» и TAdviser «Российский рынок СЭД/ECM 2013-2015», решения семейства «Логика ECM» занимают лидирующие позиции на рынке систем электронного документооборота.

По результатам 2013 года «Логика бизнеса» стала лучшим партнером IBM в области интеграции программных решений, а система «Логика ЭХД. Финансовые документы» первой в России получает специальный статус IBM Authorized Software Value Plus в области ECM-решений.

В 2014 году компания первой в России получила статус IBM FileNet Support Provider и стала лучшим партнером в области ASL-решений.

По итогам 2015 года компания стала лучшим технологическим партнером IBM в области ECM.

В 2012 году компания стала единственным в России «платиновым» партнером ABBYY и остается им по итогам работы и 2013 году, и в 2014 году.

По состоянию на 2016 год линейка продуктов «Логика ECM» включает в себя восемь решений:

«Логика СЭД» на платформах Alfresco / МСВСфера Инфооборот, IBM Notes/Domino, IBM FileNet и JBoss

Информационная система «Логика СЭД» предназначена для автоматизации управленческого документооборота и делопроизводства. Созданная в 1996 году и долгое время известная под именем «БОСС-Референт», она по праву считается одним из лидеров на российском рынке решений класса ЕСМ (Enterprise Content Management).

«Логика ЭХД» на платформах IBM FileNet и ABBYY FlexiCapture

«Логика ЭХД» — это набор решений для создания финансовых и технических электронных хранилищ данных (ЭХД) уровня Enterprise. Решения построены на платформах IBM FileNet и ABBYY FlexiCapture.

«Логика ЭА» на платформе IBM FileNet

Решение для организации надежного хранения и удобного использования электронных документов в соответствии с внутренними требованиями компаний и требованиями законодательства по архивному хранению.

«Логика СЭД. Госуправление» на платформе JBoss

Система «Логика СЭД. Госуправление» разработана на основе СПО-платформы JBoss. Решение предназначено для автоматизации управленческого документооборота и делопроизводства, отвечает требованиям органов государственной власти и позволяет построить единую систему управления документами на нескольких иерархических уровнях органов власти или предприятий холдинга.

«Логика СЭД. Управление договорами» на платформе Alfresco

Решение «Управление договорами» на платформе Alfresco — удобный и легкий способ внести в эту деятельность должный уровень формализации и упорядочивания, одновременно предоставив всем участникам процесса удобный инструмент, поддерживающий их деятельность на любом этапе жизненного цикла договора.

Мобильный клиент СЭД — «Логика ECM. Mobile»

Приложение «Логика ECM. Mobile» — это клиент для iPad, который может работать с любыми СЭД, разработанными на разных платформах. Мобильный клиент позволяет сделать работу руководителя удобной: он всегда имеет доступ к необходимым документам и может принимать решения по ним в любой момент.

«Логика ECM. Бизнес-платформа» на СПО Alfresco

Построенная на свободном ПО Alfresco, открытая к интеграции и расширению сервисная ECM-платформа позволяет быстро и эффективно решать задачи по управлению корпоративным контентом и контент-ориентированными бизнес-процессами в современной организации.

Показатели деятельности

2016: Рост продаж на 30% до 1,8 млрд руб

По итогам работы в 2016 финансовом году оборот компании достиг 1,8 млрд рублей. Четвертый год подряд оборот растет примерно на 30% по отношению к предыдущему финансовому году.

Структура оборота компании выглядит следующим образом:

  • Услуги по внедрению своих решений и консалтинг в области ECM — 67%
  • Продажа лицензий вендоров (IBM, ABBYY, Alfresco/МСВСфераИнфооборот) — 18%
  • Продажа собственных лицензий — 15%

История

2017: Создание центра ретроконверсии и сканирования

Услуги сканирования архивных и текущих документов в рамках выполнения комплексных проектов для своих заказчиков ГК «АйТи» оказывает с 2007 года. В конце 2016 года для обобщения этого опыта и максимально эффективного оказания услуг создан Центр сканирования и ретроконверсии компании «Логика бизнеса» (входит в ГК «АйТи»).

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

Центр оснащен профессиональным сканирующим оборудованием всех основных типов (промышленные поточные сканеры, книжные сканеры, широкоформатные сканеры) и может выполнять работы по переводу в электронный вид документов разных форматов (от А5 до А0+), на различных носителях (современные документы, кальки, синьки) и разного качества (ветхие документы, документы с физическими повреждениями). Центр работает как с расшиваемыми документами, так и с документами без возможности расшивки (книги, архивные дела).

Высокое качество работ по созданию поисковых атрибутов обеспечивают собственные программные решения и технологии распознавания компании ABBYY. На каждом этапе проекта производится многоступенчатый организационный и программный контроль качества обработки информации.

Центр может выполнить перевод в электронный вид всего объема архивных документов организации или только наиболее актуальной его части. Возможны варианты предоставления оборудования с персоналом для выполнения проекта или поставка решения для электронного архива «под ключ».

Эксперты Центра создали специализированные решения по оцифровке кредитных досье банка, созданию электронных архивов кадрового делопроизводства и технической документации.

Сканирование проводится на территории заказчика или с вывозом документов на производственные площадки Центра.

За последнее время специалистами Центра были выполнены масштабные проекты по наполнению электронных архивов технической документации АК «Транснефть» и ООО «ЕвросибЭнерго — тепловая энергия».

2015: Рост оборота на 30% до 1,4 млрд руб

По итогам работы в 2015 финансовом году компания достигла оборота в 1,4 млрд рублей, который третий год подряд вырос почти на 30% по отношению к периоду год назад. Согласно оценке аналитиков TAdviser, это примерно втрое больше темпа роста российского рынка ECM, который демонстрирует рост на фоне всеобщего кризиса, ставшего причиной того, что российский рынок ИТ в целом стагнирует второй год подряд.

Структура оборота компании:

  • Услуги консалтинга в области ECM — 56%
  • Продажа лицензий вендоров (IBM, ABBYY) — 24%
  • Продажа собственных лицензий — 20%

2014

Рост оборота до 1 млрд рублей (+30%)

По итогам работы в 2014 финансовом году компания достигла оборота в 1 млрд рублей. Второй год подряд рост выручки компании составил порядка 30% по отношению к 2014 году, что в 2-2,5 раза больше показателей роста всего рынка ECM. По предварительной оценке аналитической компании IDC Russia, российский рынок ПО для управления корпоративным контентом вырос в рублях в 2014 году на 10-15%.

Структура оборота компании:

  • Услуги консалтинга в области ECM — 57%
  • Продажа лицензий вендоров (IBM, ABBYY) — 25%
  • Продажа собственных лицензий — 18%
Интервью Виктора Вайнштейна

Осенью 2014 года генеральный директор компании Виктор Вайнштейн дал второе интервью TAdviser.

2013

Рост продаж на 30% до 760 млн руб

По итогам 2013 финансового года, который закончился в «Логике бизнеса» 1 апреля 2014, рост бизнеса компании составил 30%, что гораздо выше общерыночной динамики. Оборот составил 760 млн рублей. Структура оборота: 50% — сервисы, 20% — платформенные лицензии от компаний-поставщиков, 20% — лицензии на собственные продукты и 10% — оборудование, необходимое в проектах. Продажи через партнерский канал увеличились на 65%.

Разделение на "Логика ЕСМ" и "Логика BPM"

Как стало известно CNews, правление группы «АйТи» приняло решение разделить на две части компанию «Логика бизнеса», объединяющую разработчиков систем электронного документооборота и консультантов по управлению бизнес-процессами.

Первая структура получила название «Логика ЕСМ» (Enterprise content management). Ее возглавил ветеран группы «АйТи» Вайнштейн Виктор, до этого в течение нескольких лет возглавлявший дочернюю компанию-разработчика «Аплана Софтвер» (ее гендиректором стала бывший заместитель Вайнштейна Прохорова Алла).

Направление ECM сосредоточится на разработке и внедрении линейки собственного ПО, в которую входят электронный документооборот, автоматизация архива, финансовых документов, экспертизы нормативно-правовых актов.

Вторую структуру – «Логика BPM» (Business process management) возглавила Каменнова Мария , до этого руководившая объединенной «Логикой бизнеса». Специалисты по BPM занимаются описанием и оптимизацией бизнес-процессов заказчиков, т.е. выстраиванием основных процессов предприятий под определенную методологию. Помимо консультирования компания предлагает внедрение немецкого решения Metasonic Suite.

После разделения ECM-направление получило значительно больше ресурсов, заявили CNews в «АйТи»: в него перешло 177 сотрудников, в то время как BPM занимается только 28 человек. Доля первой практики в общем обороте объединенного направления составляла 90%.

2012: Анонсирование новой компании

Председатель совета директоров группы компаний «АйТи» Тагир Яппаров и бывший генеральный директор компаний IDS Scheer и Software AG Россия Мария Каменнова, перешедшая на работу в «АйТи», объявили в январе 2012 года о запуске нового проекта – консалтинговой компании «Логика бизнеса».

«Логика бизнеса» объединила в себе компании «АйТи. Информационный менеджмент», «БОСС-Референт» и команду консультантов первой версии «Логики бизнеса». Поскольку одна «Логика бизнеса» уже была, новому проекту и было выбрано такое название. Напомним, что «Логика бизнеса» «первой версии» в 2005 году стала российским подразделением IDS Scheer, а позднее − Software AG.

Мария Каменнова уже возглавляла "Логику бизнеса" первой версии, так что теперь они с Тагиром Яппаровым реинкарнировали этот проект в новом качестве 

Как пояснили TAdviser представители «Логика бизнеса», структурно новая компания полностью войдет в группу компаний «АйТи». Что касается клиентов «БОСС-Референт», то их поддержка будет передана во вновь созданную бизнес-единицу.

Специализацией «Логики бизнеса» станет управление эффективностью бизнеса и управление корпоративными ресурсами (внедрение систем класса BPM и ECM). Мария Каменнова назначена главой консалтингового проекта, а руководителями ECM и BPM практики Георгий Подбуцкий (ранее замгендиректора «АйТи. Информационный менеджмент») и Андрей Коптелов (ранее директор по консалтингу Software AG в России) соответственно.

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

Как прокомментировал старт проекта Тагир Яппаров, бизнес-процессы предприятий не покрываются полностью учетными системами, которые они уже внедрили у себя. «Новые подходы к автоматизации бизнес-процессов и управлению неструктурированной информацией позволяют делать то, что осталось за рамками учетных систем. А это 80% контента и бизнес-процессов компании», - пояснил он актуальность выбранной специализации. 6 июля 2012 года компания "Логика бизнеса" (ГК АйТи) объявила об открытии филиала в Центральной Азии. Директором представительства назначен Яков Коробко. В задачу представительства входит продвижение и поддержка продаж ECM- и BPM-решений на рынках Казахстана, Кыргызстана, Таджикистана, Туркменистана и Узбекистана. Представительство компании в этом регионе возглавил Яков Коробко. Он работает на ИТ-рынке региона более 20 лет. Ранее возглавлял представительства компании Oracle в Узбекистане, компаний SAP и Software AG & IDS Scheer в Центральной Азии.

2010: Software AG приобретает IDS Scheer

В 2010 году компания IDS Scheer была приобретена Software AG.

2006: Смена названия на "IDS Scheer Россия и страны СНГ"

2006 - компания "IDS Scheer / Логика бизнеса" меняет название на "IDS Scheer Россия и страны СНГ"

2005: IDS Scheer приобретает 75% "Логики бизнеса"

2005 - компанией IDS Scheer приобретено 75% консалтинговой компании "Логика бизнеса", название меняется на "IDS Scheer / Логика бизнеса"

1992: Основание компании "Логика бизнеса"

В 1992 году была основана консалтинговая компания "Логика бизнеса".

www.tadviser.ru

ИТ блокнот /Николай Войнов/: Разработка бизнес-логики Drools

Вчера прочел отличную статью на DeveloperWorks - Implement business logic with the Drools rules engine - показывает возможности применения Drools rule engine, о которой я уже как-то упоминал. Статья особенно хорошо смотрится после запутанного (разделяй и властвуй) документа определяющего бизнес-правила.

Собственно про Drools было немного информации в "ипотечном андеррайтинге". Можно добавить что есть подключаемый модуль к Eclipse 3.2 и Eclipse 3.3, позволяющий синтаксическую проверку кода и отладку правил не выходя из Eclipse.

В статье нет практически ничего лишнего - вся информация полезна, отличный демонстрационный пример (ещу бы правда туда чего-нибудь вычисляемого), освещающий внутренние аспекты работы машины правил.

В отличии от определения бизнес-правил, дает необходимый минимум понятий по машинам правил. Фактически это продукционная система - антецедент, консеквент, рабочая память, алгоритм вывода (Рете), база знаний, и как это все вместе работает. В общем очень рекомендую почитать, сделать выводы и взять на вооружение. Пока же приведу пару врезок

Большинство вещей изменяются ...

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

  • Чтобы исправил дефекты в коде, найденные в течении разработки или после развертывания
  • Чтобы учесть особые условия, которые клиент не высказал в начале, не говоря уже о том, что бизнес-логика должна их учесть
  • Для решения проблем с изменением целей бизнеса клиентов
  • Чтобы согласовать использование гибкого или итеративного процесса разработки вашей организации

Учитывая эти возможности, приложения позволяющие производить изменения бизнес-логики без особых осложнений весьма полезны — особенно если разработчик, выполняющий изменение сложной логики if-else не тот человек, который писал код.

Когда использовать машину правил?

Не всем приложениям нужна машина правил. Если ваш код бизнес-логики включает скопление операторов if-else, нужно подумать о ее использовании. Поддержка сложной булевой логики может стать трудной задачей, и машина правил может помочь вам эту логику организовать. Изменения значительно реже приводят к ошибкам, если вы можете выразить логику, используя декларативный подход вместо императивного языка программирования.

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

  1. Код приложение должен быть перекомпилирован.
  2. Код передается в тестовую среду.
  3. Код проверяется аудиторами качества данных.
  4. Изменение одобряется в аритекторами окружения хостинга.
  5. Изменения планируются для развертывания.

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

Знания о ваших клиентах также может быть факторов в принятии этого решения. Даже если вы работаете с простым набором требований вызывающих простую реализацию в коде Java, вы вожможно знаете из предыдущих проектов что ваши клиенты имеют тенденцию (финансовые и политические причины) часто добавлять и изменять требования бизнес-логики на протяжении цикла разработки и даже после развертывания. Возможно в этом случае стоит выбрать машину правил с самого начала.

PS

До конца документ не перевел и не вычитывал, времени да и смысла особого нет, и так все довольно понятно. Если заинтересовал смотрите здесь. Мне же пока интересна JSR-94 совместимость - узнаю расскажу. Эх такую бы штуку в 2000 - закончил бы аспирантуру :)

Чешутся руки попробовать на чем-нибудь серьезном. Хочу попробовать реализовать учебный пример из документе определяющего бизнес-правила. Причем сразу хочется связать все вместе - Drools, AspectJ, какой-нить workflow (osworkflow рекомендовали) и nakedobjects также очень хочется попробовать. Где-то я уже думал о такой конфигурации новых приложений - Domain + BPM + BRM (предметная область, процессы, бизнес-правила)

nvoynov.blogspot.com


Смотрите также