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


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

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

Отдельное спасибо автору, за разрешение отдельной публикации.

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

Где наша бизнес логика, сынок?
Введение
За годы развития мы продвинулись от десктопа к клиент-серверной архитектуре, потом к 3-х звенной конструкции, к n-звенной, к сервис ориентированной. Во время этого процесса многие вещи изменились, но многие привычки остались. Зачастую, сопротивление изменениям происходит от привычек. Однако, во многих случаях оно процедурное. Эта статья описывает, что мы делаем неправильно и возможные решения.
О статье
То, что я здесь опишу, один из методов построения n-звенных систем с точки зрения проектирования и архитектуры. Эта статья не фокусируется на коде. Есть много методов построения n-звенных систем, это только один из них. Если вы строите систему, я надеюсь, вы найдете хороший совет, методику или шаблон использования этого подхода. Хотя данная статья может предлагать несколько отправных точек из «стандартных методов», все в этой статье базируется на Шаблонах и Методах Microsoft и описывается в Designing Data Tier Components and Passing Data through Tiers и других документах.

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

Цель
Спросите любого разработчика, где должна быть бизнес логика, и получите ответ: «Конечно же в бизнес слое». Спросите того же разработчика, где находится бизнес логика в их организации, и снова услышите: «Конечно же в бизнес слое».

У вас не должно быть не малейших сомнений на счет того где должна быть бизнес логика – в бизнес слое. Не часть бизнес логики – вся бизнес логика должна быть в бизнес слое. После прочтения данной статьи, многие разработчики поймут что то, что они считали правдой о своих системах, таковой не является.

Термины
Эти термины часто используются вместе, но в данной статье я буду использовать их так, как опишу здесь.
Звено (tier)
Когда я использую слово звено, я подразумеваю физическое звено состоящее из физического сервера или группы серверов, выполняющих одинаковую функцию и сгруппированных только для повышения емкости.
Слой (layer)
Когда я использую слово слой, я подразумеваю сегмент системы, который ограничен собственным процессом или модулем. Множество слоев может содержаться в одном звене, но любой из них должен иметь возможность быть легко перенесенным на другое звено.
Развитие проблемы
Десктоп
На настольных приложениях бизнес логика содержится на одном звене со всеми остальными слоями. Т.к. нет необходимости разделять слои, они зачастую перемешаны и не имеют четких границ.

image

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

image

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

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

image

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

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

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

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

Сервер базы данных – это уровень хранения. Базы данных разработаны для хранения, получения и обновления данных с максимально высокой эффективностью. Функционал зачастую является СУПОм (Создать, Удалить, Получить, Обновить). Некоторые базы данных СУПОм и являются, но разговор не об этом.

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

Удалить Покупателя
И все это относится не только к сложным вещам. Давайте представим себе простую задачу и такую, которую зачастую даже не относят к бизнес логике. Задача – Удалить Покупателя. Практически во всех системах, что я видел, удаление покупателя обрабатывается исключительно хранимой процедурой. Однако в удаление покупателя довольно многие решения должны быть приняты на уровне бизнес логики. Можно ли удалить покупателя? Какие процессы должны быть запущены до и после? Какие предосторожности должны быть соблюдены? Из каких таблиц записи должны быть удалены или обновлены в последствие?

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

Хранимые процедуры, если они есть, должны оперировать только одной таблицей; исключение – это процедуры запрашивающие выборку из нескольких таблиц для выдачи данных. В этом случае, хранимые процедуры работают как представления (view). Представления и хранимые процедуры должны использоваться для консолидации значений, но исключительно для более быстрой и эффективной работы с данными в бизнес слое.

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

Я часто встречал хранимые процедуры вроде этой:sp_DeleteCustomer(x) Select row in customer table, is Locked field If true then throw error Sum total of customer billing table If balance > 0 then throw error Delete rows in customer billing table (A detail table) if Customer table Created field older than one year then Insert row in survey table Delete row in customer table

Регулярно часть бизнес логики отъезжает в бизнес слой.Business Layer (C#, etc) Select row in customer table, is Locked field If true then throw error. Sum total of customer billing table If balance > 0 then throw error. if Customer table Created field older than one year then Insert row in survey table Call sp_DeleteCustomer sp_DeleteCustomer(x) Delete rows in customer billing table (A detail table) Delete row in customer table

В этом случае, часть бизнес логики была перемещена, но не вся. Некоторые таблицы обрабатываются и в слое бизнес логики. База данных не должна иметь ни малейшего представления о том, какие таблицы формируют покупателя в бизнес слое. Для всех трех операций, бизнес слой должен выдать SQL команду или вызвать три отдельные хранимые процедуры для реализации функционала в приведенной sp_DeleteCustomer. Передав всю бизнес логику в бизнес слой, мы получим:Business Layer (C#, etc) Select row in customer table, is Locked field If true then throw error. Sum total of customer billing table If balance > 0 then throw error. if Customer table Created field older than one year then Insert row in survey table Call sp_DeleteCustomer Delete rows in customer billing table (A detail table) Delete row in customer table

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

Переведя даже модификацию таблиц в бизнес слой, мы получим следующие преимущества:

  • Перенос базы данных может быть осуществлен с меньшими усилиями, т.к. все эти хранимые процедуры не нужно отлаживать для каждой СУБД.
  • Модификация проще, т.к. вся логика содержится в одном слое, а не в двух.
  • Отладка проще – логика не размазана по двум слоям.
  • Другая логика не сможет проскользнуть в хранимую процедуру только потому, что «так проще».
В виду того, что такой метод требует три успешных обращения к базе данных вместо одного, ваш узел бизнес логики должен быть подключен к базе данных по отдельному высокоскоростному сегменту, типа гигабита. Отправка 300 байт вместо 100 байт станет непринципиальной. Большинство баз данных поддерживают пакетную передачу SQL запросов, и все три запроса могут быть посланы в одном пакете, уменьшив нагрузку на сеть. Для выдачи таких запросов следует использовать слой доступа к данным, а не включать запросы прямо в код.

Некоторые администраторы баз данных и даже разработчики могут не принять этот уровень интеграции и настаивать на реализации таких пакетных обновлений в хранимых процедурах. Это выбор, который вы должны сделать, и он очень зависит от вашей базы данных и ваших приоритетов. Т.к. практически все современные базы данных используют механизмы кэширования запросов, выигрыш в производительности в большинстве случаев минимален, а четкие технологические причины не нагружать логикой хранимые процедуры есть. Если вы выберите оставить такие пакетные обновления в хранимых процедурах, вы должны быть очень осторожны, чтобы не допустить проскальзывания другой бизнес логики в хранимые процедуры, и ограничить свои хранимые процедуры СУПОвыми операциями, без каких либо условных операций и другой бизнес логики.

Форматирование
Давайте разберем еще один пример, обнаруженный мной и сеющий зерна войны среди разработчиков – является это бизнес логикой или нет. Я расскажу, почему я считаю это бизнес логикой, а не пользовательским интерфейсом или хранением. Этот пример не относится к легко реализуемому форматированию. Пример, который я буду использовать, — телефонные номера. Каждая страна имеет свой собственный формат отображения телефонных номеров в приятной глазу манере. В некоторых странах их даже больше одной. Ниже несколько примеров:

Кипр: +357 (25) 66 00 34 +357 (25) 660 034 +357 25 660 034 +357 2566 0034 Германия: +49 211 123456 +49 211 1234-0 Северная Америка (США, Канада) +1 (423) 235-2423 +1-423-235-2423 Россия: +7 (812) 438-46-02 +7 (812) 438-4602

В Германии есть даже специальный официальный стандарт для форматирования – DIN 5008.

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

Договоримся форматировать телефоны следующим образом:

  • Данные поступают в различных форматах.
  • У каждой страны есть свой уникальный способ отображать телефоны.
  • Форматы некоторых стран не просты и меняются в зависимости от первых цифр.
  • Первые несколько цифр (обычно код страны и региона) не всегда имеют фиксированную длину. Например, в России, 812 – код города Санкт-Петербург, 495 – Москва, но некоторые регионы имеют 4 знака (3952). Это приводит и к изменению и общей длины, и формата, в зависимости от регионального кода.
  • При выходе новых законов, появлении новых операторов, интеграции Евросоюза, обновления телефонных систем и еще множестве всего, форматы и длины телефонов меняются довольно часто в глобальном масштабе. За недавнее время Кипр сменил свой код страны дважды: один раз при обновление системы, второй раз из-за возросшего числа сотовых операторов. Имея сотни стран во всем мире, следует ожидать изменений на регулярной основе.
Обычно делается следующее, все не цифровые символы убираются и номер становится похожим на: Phone: 35725660034

Иногда отделяется код страны и номер становится таким: PhoneCountry: 357 PhoneLocal: 25660034

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

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

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

Еще чаще телефонные номера хранятся дважды. Один раз в чистом виде для хорошей индексации и поиска, и второй – в отформатированном для отображения. В дополнении к проблемам, описанным выше, получаем проблемы избыточных записей и обновления.

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

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

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

Я еще вернусь в статье к этой проблеме.

Сегодняшние системы
Клиент-сервер
В клиент-серверных приложениях бизнес логика обычно имеется и на клиенте, и на сервере.

image

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

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

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

Сценарий 1
Типичное распределение бизнес логики по n-звенной системе:

image

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

Сценарий 2
Другой типичный сценарий:

image

Обычно некоторые бизнес правила приложения переходят в бизнес слой, но то, что было в базе данных, так в ней большей частью и остается.

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

image

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

Консолидация
Вместо всего вышеперечисленного, бизнес слой должен содержать все бизнес правила.

image7

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

  • Вся бизнес логика находится в одном месте и может быть легко проверенна, отлажена и изменена.
  • Нормальный язык разработки может быть использован для реализации бизнес правил. Такие языки более гибкие и более подходят для бизнес правил, чем SQL и хранимые процедуры.
  • База данных становится слоем хранения и может заниматься эффективным получением и хранением данных без ограничений относящихся к слою бизнес логики или представления.
Приведенный сценарий – это цель. Однако, некоторое дублирование, особенно для проверки данных, должно быть и на клиенте. Эти правила должны быть поддержаны и бизнес слоем. Кроме этого, в некоторых системах отдельные высоко емкие операции, такие как пакетные обновления, могут привести к исключениям и должны быть размещены в базе данных. Потому более реалистичных подход представлен ниже. Обратите внимание, что вся бизнес логика должна быть реализована в бизнес слое, и те минимальные наборы, присутствующие в других слоях, являются просто дублями исключительно для повышения производительности или отключения тех или иных компонент пользовательского интерфейса.

image

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

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

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

Дешевле
Звучит несколько странно, что покупка железа может сделать дешевле. Но при внедрении серверов среднего звена, практически никакого дополнительного ПО, кроме ОС, не требуется. А стоимость наращивания мощности сервера базы данных существенна по следующим причинам:
  • Сервера баз данных, как правило, более высокого класса, чем сервера среднего звена, и стоят дороже.
  • Базы данных зачастую лицензируются на процессор и добавление процессора – дорогостоящая процедура в терминах лицензий. Лицензионные сборы могут составлять от 5000 до 40000 долларов на процессор.
При переносе логики на среднее звено, вы можете существенно сократить нагрузку на базу данных и предотвратить преждевременное наращивание ее мощностей.
Проще
В добавление к стоимости, обновление среднего звена обычно проще чем обновление базы данных. У баз данных есть врожденный предел того, на сколько они могут быть увеличены простым добавлением железа. В какой-то момент нужно начинать использовать другие технологии вроде деления, кластеризации, репликации и т.п. Но ни одна из этих технологий не является простой, и все требуют существенных вложений в железо, миграцию и сильно влияют на существующие системы.

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

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

image

Если те же данные привести в относительных значениях, их можно легко сравнить:

image

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

Вырасти середину
Если большая часть бизнес логики реализована в базе данных, вам будет нужна более мощная база данных.

image

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

image

Бутылочное горлышко
Давайте посмотрим еще раз на один из предыдущих графиков:

image

Какое единственное узкое место в системе? Какое из звеньев имеет выраженный предел наращивания? Это однозначно база данных. Все упирается в базу данных.

image

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

Сложности
Есть несколько сложностей для перехода в среднее звено, и не все они заключаются в том, что нужно по-разному программировать.
Привычки
Есть поговорка: «сложно избавиться от старых привычек». Это применимо и к команде. В команде вам нужно убедить не только себя, но и большинство команды.
Процедуры
Многие компании имеют устоявшиеся политики безопасности, предписывающие обеспечение безопасности в базе данных, а использование хранимых процедур в качестве представлений не дает достаточного контроля. Изменение корпоративных политик безопасности для перехода в n-звенный мир может оказаться очень сложным, если не невозможным. В .Net безопасность, как и в новых технологиях Microsoft, ориентирована на корпоративную безопасность в среднем звене как никогда ранее, но многие компании все еще опираются на базы данных и либо не заботятся об изменениях, либо не хотят менятся.
Администраторы баз данных
Это рискованное утверждение. Настолько рискованная, что есть еще кое-что, что нужно сказать. Если вы администратор БД или разработчик, пожалуйста, не воспринимайте то, что я хочу сказать как стереотип или правду о всех администраторах баз данных. Однако, это превалирует и часто встречается. Если вы администратор БД, который не попадает под это описание – браво! Вы Президент баз данных, а не лорд баз данных.

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

У многих администраторов БД очень мало знаний о том, зачем нужны изменения в сторону n-звенной архитектуры, или им просто всё равно. Для них любое звено всего лишь еще один клиент, и все для них клиент-серверная архитектура. Они заботятся лишь о работе базы данных и идут на сделку с разработчиками, только если она не доставит им каких-либо хлопот.

Администраторы баз данных не мигрируют по компаниям с такой частотой как разработчики, и многие из них руководят корпоративной базой данных на протяжении последних 10 и даже 20 лет. База данных очень важная для них вещь, и они не хотят идти ни на какие сделки. Они построили свое королевство и не хотят потерять контроль. Заставить такого администратора отдать часть безопасности и реализации можно только в серьезной битве и при поддержке менеджмента.

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

Инструментарий
Большая часть доступных сегодня инструментов, нестабильны или не предоставляют средств реализации бизнес логики. Многие инструменты акцентированы исключительно на масштабируемость, пул соединений и изоляцию базы данных, и не нацелены на реализацию потребностей бизнес логики.
Решения
Архитектура
Я обнаружил большую пользу в регулярном аудите архитектуры системы, при котором помечается некорректное размещение бизнес логики. Чем раньше они обнаружены, тем проще и дешевле их исправить. Если у вас нет специального главного архитектора, тогда разработчики из команды могут проверять друг друга. Если что-то найдено не в том месте, разработчик может оповестить команду и тимлидера.
Обучение ассистентов
Очень полезно обучать ассистентов администратора базы данных. Администраторы так долго реализовывали бизнес логику, что для них тяжело определить: где бизнес логика, а где хранилище. Ассистенты обычно делают только то, что от них требуют, как правило, следуя указаниям администратора.

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

Обучение менеджеров
Часто встречается сопротивление менеджмента, хотя, это скорее простое препятствие, чем сложное. Менеджменту наплевать, стала ли легче ваша работа, но их заботят накладные расходы, время разработки, преимущества для бизнеса, ну и не плохо бы им рассказать о текущих потерях.

Основное препятствие на пути изменения менеджмента будет сопротивления администратора базы данных. Так что, сдайте менеджмент с потрохами и пусть они сами разбираются с администратором.

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

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

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

Пожалуйста, обратите внимание на Designing data tier components and passing data through tiers.

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

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

UPD: по подсказке maovrn перенесено в «Проектирование и рефакторинг».UPD1: Для тех кто в танке: 1. На Хабре есть правила оформления переводов см. помощь 2. Для тех, кто не может осилить п.1. автор статьи Chad Z. Hower aka Kudzu 3. Для тех, кто читает только середину без начала и конца — статье три года. Потому, как минимум некорректно объявлять автора статьи безграмотным на основание того, что он не читал на момент публикации материалов, выпущенных после публикации. 4. Если данный апдейт вас задел — это ваши проблемы.

habr.com

ЛОГИКА - это... Что такое БИЗНЕС-ЛОГИКА?

 БИЗНЕС-ЛОГИКА В разработке информационных систем - совокупность правил, принципов, зависимостей поведения объектов предметной области (области человеческой деятельности, которую система поддерживает). Иначе можно сказать, что бизнес-логика - это реализация правил и ограничений автоматизируемых операций. Является синонимом термина "логика предметной области" (англ. domain logic)

Словарь бизнес-терминов. Академик.ру. 2001.

  • АККАУНТ
  • БИЗНЕС-МОДЕЛИРОВАНИЕ

Смотреть что такое "БИЗНЕС-ЛОГИКА" в других словарях:

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

  • Логика бизнеса — Бизнес логика в разработке информационных систем совокупность правил, принципов, зависимостей поведения объектов предметной области системы. Иначе можно сказать, что Бизнес логика это реализация правил и ограничений автоматизируемых операций.… …   Википедия

  • Бизнес процесс — представляет собой систему последовательных, целенаправленных и регламентированных видов деятельности, в которой посредством управляющего воздействия и с помощью ресурсов входы процесса преобразуются в выходы, результаты процесса, представляющие… …   Википедия

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

  • Бизнес-требования к информационной системе — Бизнес требования на разработку (доработку) информационной системы разрабатываются заказчиком на самых ранних стадиях, как правило, до инициации проекта и включают следующие разделы Содержание 1 Общие положения 2 Характеристика объекта авт …   Википедия

  • Бизнес моделирование — деятельность по выявлению и описанию существующих бизнес процессов (анализ бизнес процессов), а также проектированию новых (проектирование бизнес процессов). Бизнес моделированием также называют дисциплину и отдельный подпроцесс в процессе… …   Википедия

  • Моделирование бизнес-процессов — Бизнес моделирование деятельность по выявлению и описанию существующих бизнес процессов (анализ бизнес процессов), а также проектированию новых (проектирование бизнес процессов). Бизнес моделированием также называют дисциплину и отдельный… …   Википедия

  • Реинжиниринг бизнес-процессов — У этого термина существуют и другие значения, см. Реинжиниринг. Реинжиниринг бизнес процессов (англ. Business process reengineering) фундаментальное переосмысление и радикальное перепроектирование бизнес процессов для достижения… …   Википедия

  • Крупный бизнес — (Big bisness) Понятие крупного бизнеса, развитие и прибыль Информация о понятии крупного бизнеса, развитие и прибыль Содержание Содержание Динамика развития Прибыль и рентабельность Производительность труда Комплексная эффективность Крупный… …   Энциклопедия инвестора

  • РАССРЕДОТОЧЕННАЯ ЛОГИКА — (distributed logic) Компьютерная система, которая дополняет основной компьютер удаленными от него терминалами, способными решать некоторые расчетные задачи, либо электронными устройствами, которые могут принимать некоторые решения,… …   Словарь бизнес-терминов

Книги

  • Бизнес-психология, Бардиер Г.Л.. В монографии, посвященной бизнес-психологии как части активно формирующейся в настоящее время отечественной экономической психологии, делается упор на исследовательский научно-психологический… Подробнее  Купить за 847 грн (только Украина)
  • Бизнес-психология, Бардиер Г.Л.. В монографии, посвященной бизнес-психологии как части активно формирующейся в настоящее время отечественной экономической психологии, делается упор на исследовательский научно-психологический… Подробнее  Купить за 739 руб
  • Бизнес-психология (2-е изд., испр.), Бардиер, Галина Леонидовна. В основу книги положен отработанный на практике курс лекций по бизнес-психологии, поэтому она с одинаковым успехом может быть рекомендована как руководителям и сотрудникам фирм, так и людям,… Подробнее  Купить за 539 руб
Другие книги по запросу «БИЗНЕС-ЛОГИКА» >>

dic.academic.ru

Логика бизнеса - это... Что такое Логика бизнеса?

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

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

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

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

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

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

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

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

См. также

Wikimedia Foundation. 2010.

  • Логгин Рот
  • Логика норм

Смотреть что такое "Логика бизнеса" в других словарях:

  • Моделирование бизнеса — Бизнес моделирование деятельность по выявлению и описанию существующих бизнес процессов (анализ бизнес процессов), а также проектированию новых (проектирование бизнес процессов). Бизнес моделированием также называют дисциплину и отдельный… …   Википедия

  • АйТи — У этого термина существуют и другие значения, см. Айти (значения). АйТи Тип Закрытое акционерное общество Год основания 1990 Основатели Тагир Яппаров и Игорь Касимов …   Википедия

  • Masterforex-V — (Мастерфорекс 5) Masterforex V это обучающий интернет проект в области валютного рынка Форекс Разоблачение обучающего проекта Masterforex V, организатор и преподаватели мошеннической академии Мастерфорекс 5, методы обмана клиентов проекта… …   Энциклопедия инвестора

  • Крупный бизнес — (Big bisness) Понятие крупного бизнеса, развитие и прибыль Информация о понятии крупного бизнеса, развитие и прибыль Содержание Содержание Динамика развития Прибыль и рентабельность Производительность труда Комплексная эффективность Крупный… …   Энциклопедия инвестора

  • ИСТОРИОГРАФИЯ — (от история (см.) и греч. grapo пишу, букв. описание истории) 1) История ист. науки, являющейся одной из важнейших форм самопознания человеческого общества. И. наз. также совокупность исследований, посвященных определенной теме или исторической… …   Советская историческая энциклопедия

  • HSBC — (Эйч Эс Би Си) Сведения о банке HSBC, активы и отделения Информация о банке HSBC, активы и отделения, стратегия и цели Содержание Содержание Определения описываемого предмета Группа Деятельность HSBC — невидимка О — коротко, по… …   Энциклопедия инвестора

  • IPO — (Публичное размещение) IPO это публичное размещение ценных бумаг на фондовом рынке Сущность понятия публичного размещения (IPO), этапы и цели проведения IPO, особенности публичного размещения ценных бумаг, крупнейшие IPO, неудачные публичные… …   Энциклопедия инвестора

  • Инвестиции — (Investment) Инвестиции это капитальные вложения для получения прибыли Виды инвестиций, инвестиционные проекты, инвестиции в фондовый рынок, инвестиции в России, инвестиции в мире, во что инвестировать? Содержание >>>>>>>>>> …   Энциклопедия инвестора

  • Инвестор — (Investor) Инвестор это лицо или организация, совершающее вложения капитала с целью получения прибыли Определение понятия инвестор, частный, квалифицированный и институциональный инвестор, особенности работы инвестора, известные инвесторы,… …   Энциклопедия инвестора

  • Холдинг — (Holding) Определение холдинга, типы холдига, холдинговые компании Информация об определении холдинга, типы холдига, холдинговые компании Содержание Содержание Характерные черты холдинга Типы холдинга Холдинговые Проблемы банковских холдингов… …   Энциклопедия инвестора

Книги

  • Логика бизнеса, Н. К. Моисеева, А. В. Сидняков, А. В. Селиванов, И. В. Познышева. Посвящена актуальным проблемам организации бизнеса в условиях развития информационных технологий и обострения конкуренции. Приводятся современные достижения отечественной и зарубежной науки и… Подробнее  Купить за 826 грн (только Украина)
  • Логика бизнеса, Н. К. Моисеева, А. В. Сидняков, А. В. Селиванов, И. В. Познышева. Посвящена актуальным проблемам организации бизнеса в условиях развития информационных технологий и обострения конкуренции. Приводятся современные достижения отечественной и зарубежной науки и… Подробнее  Купить за 702 руб
  • Нейрокомпьютерная парадигма и общество, Петрунин Ю.Ю.. Коллективная монография посвящена использованию нейрокомпьютерных и некоторых связанных с ними моделей в различных областях социально-гуманитарного знания (политология, социология,… Подробнее  Купить за 689 руб
Другие книги по запросу «Логика бизнеса» >>

dic.academic.ru

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

В этой статье я попробую сам разобраться в себе и в своих аргументах. Для начала попробую оппонировать автору статьи, перевод которой нашел на хабре Где наша бизнес-логика, сынок?. Её писал такой же идеалист, которым я был еще лет 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. Минус остается лишь в одном — не очень удобно без объектного языка реализовывать бизнес-логику, но так как часто это логика работы не с одним объектом, а опять же это групповые операции над многими сущностями в базе данных, то не все так однозначно.

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

habrahabr.ru

Бизнес-логика — Википедия (с комментариями)

Материал из Википедии — свободной энциклопедии

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

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

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

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

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

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

См. также

К:Википедия:Статьи без источников (тип: не указан)

Напишите отзыв о статье "Бизнес-логика"

Отрывок, характеризующий Бизнес-логика

– Капитан, ради Бога, я контужен в руку, – сказал он робко. – Ради Бога, я не могу итти. Ради Бога! Видно было, что юнкер этот уже не раз просился где нибудь сесть и везде получал отказы. Он просил нерешительным и жалким голосом. – Прикажите посадить, ради Бога. – Посадите, посадите, – сказал Тушин. – Подложи шинель, ты, дядя, – обратился он к своему любимому солдату. – А где офицер раненый? – Сложили, кончился, – ответил кто то. – Посадите. Садитесь, милый, садитесь. Подстели шинель, Антонов. Юнкер был Ростов. Он держал одною рукой другую, был бледен, и нижняя челюсть тряслась от лихорадочной дрожи. Его посадили на Матвевну, на то самое орудие, с которого сложили мертвого офицера. На подложенной шинели была кровь, в которой запачкались рейтузы и руки Ростова. – Что, вы ранены, голубчик? – сказал Тушин, подходя к орудию, на котором сидел Ростов. – Нет, контужен. – Отчего же кровь то на станине? – спросил Тушин. – Это офицер, ваше благородие, окровянил, – отвечал солдат артиллерист, обтирая кровь рукавом шинели и как будто извиняясь за нечистоту, в которой находилось орудие. Насилу, с помощью пехоты, вывезли орудия в гору, и достигши деревни Гунтерсдорф, остановились. Стало уже так темно, что в десяти шагах нельзя было различить мундиров солдат, и перестрелка стала стихать. Вдруг близко с правой стороны послышались опять крики и пальба. От выстрелов уже блестело в темноте. Это была последняя атака французов, на которую отвечали солдаты, засевшие в дома деревни. Опять всё бросилось из деревни, но орудия Тушина не могли двинуться, и артиллеристы, Тушин и юнкер, молча переглядывались, ожидая своей участи. Перестрелка стала стихать, и из боковой улицы высыпали оживленные говором солдаты. – Цел, Петров? – спрашивал один. – Задали, брат, жару. Теперь не сунутся, – говорил другой. – Ничего не видать. Как они в своих то зажарили! Не видать; темь, братцы. Нет ли напиться? Французы последний раз были отбиты. И опять, в совершенном мраке, орудия Тушина, как рамой окруженные гудевшею пехотой, двинулись куда то вперед. В темноте как будто текла невидимая, мрачная река, всё в одном направлении, гудя шопотом, говором и звуками копыт и колес. В общем гуле из за всех других звуков яснее всех были стоны и голоса раненых во мраке ночи. Их стоны, казалось, наполняли собой весь этот мрак, окружавший войска. Их стоны и мрак этой ночи – это было одно и то же. Через несколько времени в движущейся толпе произошло волнение. Кто то проехал со свитой на белой лошади и что то сказал, проезжая. Что сказал? Куда теперь? Стоять, что ль? Благодарил, что ли? – послышались жадные расспросы со всех сторон, и вся движущаяся масса стала напирать сама на себя (видно, передние остановились), и пронесся слух, что велено остановиться. Все остановились, как шли, на середине грязной дороги.

wiki-org.ru

Бизнес логика. Всегда ли нужно на нее опираться при создании бизнеса

 

Статьи > Раздел "Быть или не быть бизнесу" > Бизнес логика. Всегда ли нужно на нее опираться при создании бизнеса Александр Карпов, руководитель открытого интернет-проекта smart-venture.ru, автор книги "Создание и развитие эффективного бизнеса с нуля"

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

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

Несомненно, перед тем как создавать бизнес желательно проработать все основные вопросы. Для этого можно воспользоваться, например, технологией создания бизнеса, представленной на этом сайте.

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

Отсутствие каких-либо планов по созданию бизнеса – это одна крайность, а попытка учесть все "до винтиков" – другая.

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

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

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

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

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

Почему-то многие начинающие предприниматели при разработке маркетинговой стратегии в ее основу закладывают самые (или почти самые) низкие цены на продукты/услуги.

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

С точки зрения бизнес логики это вполне разумное умозаключение, но практика доказывает обратное.

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

С точки зрения бизнес логики все магазины у дома уже давно должны были бы развалиться. Хотя, нужно отметить, что наше правительство очень активно работает в этом направлении. Многие законы направлены на развал малого бизнеса.

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

Итак, бизнес логика говорит о том, что магазины у дома не могут выдержать сватку с крупными магазинами, поэтому они должны исчезнуть. Но все мы знаем, что такие небольшие магазинчики есть во многих жилых домах.

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

Мало кто захочет поехать в гипермаркет из-за "батона хлеба". Такая поездка позволит сэкономить "три копейки", но потребует гораздо больше времени. Кроме того затраты на бензин могут перекрыть всю эту экономию.

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

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

Я так категорично утверждаю, потому что два моих приятеля работают начальниками производства в двух разных типографиях, расположенных в Москве. Они не жалуются на отсутствие заказов и низкий уровень оплаты труда.

Когда они сделали расчет стоимости производства моих книг, то у меня в голове мгновенно возник только один вопрос: какие идиоты делают им заказы на производство книг?

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

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

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

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

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



Свои комментарии к этой статье Вы можете направлять по адресу [email protected], указав свое Ф.И.О., должность и название организации, в которой Вы работаете (или только Ф.И.О., если Вы сейчас пока нигде не работаете). Ваши комментарии будут размещены под данной статьей.

Если у Вас возникли какие-то вопросы по данной статьей Вы также можете направить их по адресу [email protected] Автор статьи ответит на Ваши вопросы в течение нескольких дней с момента получения.



smart-venture.ru

Бизнес-логика — Википедия (с комментариями)

Материал из Википедии — свободной энциклопедии

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

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

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

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

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

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

См. также

<imagemap>: неверное или отсутствующее изображение

В этой статье не хватает ссылок на источники информации.Информация должна быть проверяема, иначе она может быть поставлена под сомнение и удалена.Вы можете [http://o-ili-v.ru/wiki/index.php?title=%D0%91%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%BB%D0%BE%D0%B3%D0%B8%D0%BA%D0%B0&action=edit отредактировать] эту статью, добавив ссылки на авторитетные источники.Эта отметка установлена 1 сентября 2014 года.
[[К:Википедия:Статьи без источников (страна: Ошибка Lua: callParserFunction: function "#property" was not found.)]][[К:Википедия:Статьи без источников (страна: Ошибка Lua: callParserFunction: function "#property" was not found.)]][[К:Википедия:Статьи без источников (страна: Ошибка Lua: callParserFunction: function "#property" was not found.)]]Ошибка Lua: callParserFunction: function "#property" was not found.Бизнес-логикаОшибка Lua: callParserFunction: function "#property" was not found.Бизнес-логикаОшибка Lua: callParserFunction: function "#property" was not found.Бизнес-логика

Напишите отзыв о статье "Бизнес-логика"

Отрывок, характеризующий Бизнес-логика

– Ой, пожалуйста, так не думай! – воскликнула я. – Она тебя так любит! И она тебя никогда не оставит. – Да нет... она сказала, что у всех нас есть своя жизнь, и мы должны прожить её так, как каждому из нас суждено... Это грустно, правда? Но Стелла, видимо, просто не могла долго находиться в печальном состоянии, так как её личико опять радостно засветилось, и она уже совсем другим голоском спросила: – Ну что, будем смотреть дальше или ты уже всё забыла? – Ну, конечно же, будем! – как бы только что очнувшись от сна, теперь уже с большей готовностью ответила я. Я не могла ещё с уверенностью сказать, что хотя бы что-то по-настоящему понимаю. Но было невероятно интересно, и кое-какие Стеллины действия уже становились более понятными, чем это было в самом начале. Малышка на секунду сосредоточилась, и мы снова оказались во Франции, как бы начиная точно с того же самого момента, на котором недавно остановились... Опять был тот же богатый экипаж и та же самая красивая пара, которая никак не могла о чём-то договориться... Наконец-то, совершенно отчаявшись что-то своей юной и капризной даме доказать, молодой человек откинулся на спинку мерно покачивавшегося сидения и грустно произнёс: – Что ж, будь по-вашему, Маргарита, я не прошу вашей помощи более... Хотя, один лишь Бог знает, кто ещё мог бы помочь мне увидеться с Нею?.. Одного лишь мне не понять, когда же вы успели так измениться?.. И значит ли это, что мы не друзья теперь? Девушка лишь скупо улыбнулась и опять отвернулась к окошку... Она была очень красивой, но это была жестокая, холодная красота. Застывшее в её лучистых, голубых глазах нетерпеливое и, в то же время, скучающее выражение, как нельзя лучше показывало, насколько ей хотелось как можно быстрее закончить этот затянувшийся разговор. Экипаж остановился около красивого большого дома, и она, наконец, облегчённо вздохнула. – Прощайте, Аксель! – легко выпорхнув наружу, по-светски холодно произнесла она. – И разрешите мне напоследок дать вам хороший совет – перестаньте быть романтиком, вы уже не ребёнок более!.. Экипаж тронулся. Молодой человек по имени Аксель неотрывно смотрел на дорогу и грустно сам себе прошептал: – Весёлая моя «маргаритка», что же стало с тобою?.. Неужели же это всё, что от нас, повзрослев, остаётся?!.. Видение исчезло и появилось другое... Это был всё тот же самый юноша по имени Аксель, но вокруг него жила уже совершенно другая, потрясающая по своей красоте «реальность», которая больше походила на какую-то ненастоящую, неправдоподобную мечту...

o-ili-v.ru


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