Зарегистрируйтесь
Страницы: 1
Описание бизнес-логики
07.04.2008 17:27:57
заказчик хочет документ «Описание бизнес-логики» (Описание бизнес-логики модуля системы).
Не могу найти ни ГОСТ, ни примера описания.
Кто-нибудь писал сей док-т? Очень нужен пример или хотя бы структура дока.
Сообщений: 753 Баллов: 602 Рейтинг: 6 Авторитет: 6 Регистрация: 07.06.2007
Мне нравится 0
07.04.2008 17:32:01
Возможно имеется ввиду [b:2rh7asmd]бизнес-процессов[/b:2rh7asmd]?
Работаю по-старинке.
Не определившийся
Сообщений: 10 Баллов: 5 Рейтинг: 0 Авторитет: 0 Регистрация: 24.06.2007
Мне нравится 0
07.04.2008 17:34:07
В том-то и дело, что нет. Именно бизнес-логики (логики работы приложения, если я правильно понимаю).
Сообщений: 753 Баллов: 602 Рейтинг: 6 Авторитет: 6 Регистрация: 07.06.2007
Мне нравится 0
07.04.2008 17:36:53
Может это поможет?
Для иллюстрации рассмотрим возможности обеспечения качества за счет организации прикладной функциональности программной системы. Совокупность реализуемых прикладных функций также называют логикой предметной области или бизнес-логикой.
КАК ПИСАТЬ БИЗНЕС ЛОГИКУ В DJANGO PYTHON? КАК СОЗДАТЬ ПРАВИЛЬНЫЕ СЕРВИСЫ В DJANGO?
Организация кода, реализующего бизнес-логику, влияет на такие свойства программной системы, как расширяемость, открытость, сложность поддержки. Возможность вносить изменения в программную систему в разумные сроки и за разумные средства часто оказывается важным потребительским свойством системы. При этом вопросы организации программного кода зачастую не считаются достаточно важными, чтобы посвящать им специальные усилия архитектора (если таковой на проекте имеется), и отдаются на откуп программистам. Что отнюдь не сказывается благоприятным образом на качестве создаваемой системы.
Рассмотрим вопрос рационального выбора варианта организации бизнес-логики. Наша основная цель – научиться избегать грубых ошибок за счет применения простой схемы выбора варианта.
Как мы выбираем?
«Святая простота»
Распространенный способ выбора организации функциональности выглядит примерно следующим образом: «Почему так сделал?» – «Не знаю. я так привык. ». Такой способ можно назвать «святая простота», так как выбор, в сущности, ничем не обоснован. Такая ситуация обычно складывается, если от программистов требуется, чтобы это хоть как-то заработало, а обоснованием никто не интересуется.
Проблемы такого подхода очевидны. Потребительские качества программного продукта оказываются зависящими от квалификации того парня, которому выпало ваять структуру объектов или функций для приложения. Если процесс не контролировать должным образом, можно бесконечно бороться с ошибками и проблемами в продукте, связанными с неудачным выбором структуры программы.
«Идеологический подход»
Также распространенный, но недалеко ушедший от предыдущего способ писания программ: «Потому что правильно!». Разработчик, возможно, прочитал книгу по данной технологии и с этого момента всегда делает так, как в этой книге велено (варианты – изучил «суперуниверсальный» шаблон, скачал «рекомендуемый» пример и т.д.). Здесь личные предпочтения принимают форму твердой убежденности в «правильности» того или иного подхода.
Что такое бизнес-логика? (на примере Django)
При таком подходе проблемы возникают тогда, когда технологически красивое решение оказывается не соответствующим решаемой задаче. То есть подход может работать вполне успешно, однако бездумное следование авторитетам вовсе не гарантирует от неудачных решений и низкого качества продукта в результате.
Проблемы сознательного выбора
Вопросы организации программного кода зачастую непонятны руководителю проекта. Если «грабли» в долгосрочной перспективе менеджера не волнуют либо технологические вопросы ему вообще не интересны, то на выбор решения может элементарно не выделяться времени, как на низкоприоритетную задачу.
Другая проблема – отсутствие контроля качества решения. Вопрос организации функциональности часто оказывается в компетенции отдельного программиста, пусть даже это Ведущий Разработчик. А программисту интереснее писать код, ему хочется скорее сделать работоспособную версию, пусть «кривоватую», зато будет зримый результат! Размышления о том, как оптимально сконструировать систему, чтобы минимизировать проблемы в перспективе, плохо сочетаются с желанием немедленно кодировать то, что кажется понятным.
В результате разработчики начинают кодировать в соответствии с подходами, перечисленными выше. На крайний случай это называется «быстрое прототипирование» либо «наши ребята за один вечер любую задачу порвут на британский флаг». Впоследствии тем же ребятам приходится проявлять чудеса изобретательности, чтобы справиться с проблемами, возникающими из-за несоответствия архитектуры требованиям, предъявляемым к программной системе. За это программист получает отдельное спасибо, обычно заслуженное. И только он сам понимает реальную степень кривизны своего решения и осознает, что «если б было время подумать тогда, в самом начале. можно было бы так красиво сделать. а теперь уж не переделаешь. ». Но на следующем проекте повторяется та же история.
Попытаемся определить, как же именно можно «сделать красиво», если до начала кодирования найдется время подумать. Для этого рассмотрим типовые варианты организации бизнес-логики и предложим схему выбора варианта на основе простейших критериев.
Из чего мы выбираем
Существует множество разных подходов к описанию и реализации бизнес-логики. Можно сказать, что у каждого коллектива разработчиков так или иначе формируется свой подход, что выражается в методах проектирования структуры приложения, правилах кодирования и т.д.
Однако все чаще предпринимаются попытки систематизации и классификации подходов к проектированию для описания профессионального опыта в этой области. Один из способов систематизации приемов и методов проектирования структуры программных систем – шаблоны проектирования или шаблоны архитектуры (также называемые в русском переводе «паттернами», от англ. pattern – образец, модель, шаблон) [1], [2]. В частности, существует три типовых подхода к организации бизнес-логики, называемых сценарий транзакции, модель предметной области и модуль таблицы. Данные подходы в деталях рассмотрены в [1] (вплоть до фрагментов программного кода). Здесь мы рассмотрим основные особенности этих типовых решений и на их примере сформулируем соображения по выбору варианта организации бизнес-логики для проектируемой системы.
Сценарий транзакции (функциональный подход)
Это простейший подход к описанию бизнес-логики. За термином «сценарий транзакции» кроется функция системы, реализующая определенную функцию прикладной логики. Пример – расчет стоимости заказа, формируемого в системе.
При таком подходе программная система представляет собой набор функций, в котором каждая функция соответствует операции, которую приложение выполняет для пользователя. Это старая добрая процедурная модель, хорошо известная разработчикам. Проектируется иерархия функций, возможно повторное использование функций нижних уровней. Существуют давно и хорошо отработанные методологии, а также стандарты функционального моделирования, с помощью которых можно проектировать функциональную структуру программной системы в сложных случаях.
Несомненное достоинство подхода – простота реализации в программном коде. Этот вариант по плечу каждому программисту, включая новичка, едва освоившего свой первый язык программирования. Однако у функционального подхода есть и определенные недостатки.
С возрастанием сложности прикладной логики становится чрезвычайно сложно формировать структуру, не содержащую дублированных функций. А попытка переделать имеющуюся сложную структуру при изменении прикладной логики быстро приводит к тому, что функциональная структура превращается в «помойку» и выходит из-под контроля разработчиков. Все это, в конечном счете, осложняет развитие и поддержку системы.
Модель предметной области (объектный подход)
Этот подход наиболее сложен в реализации, но и наиболее продуктивен. Разрабатывается объектная модель предметной области – по крайней мере, для основных понятий. Например, для интернет-магазина могут быть созданы объекты «клиент», «товар», «корзина», «заказ» и т.д.
Вместо того, чтобы помещать бизнес-логику расчета стоимости в одну или несколько процедур, для каждого объекта реализуется функциональность исходя из зоны ответственности этого объекта. Например, объект «заказ» содержит алгоритм вычисления стоимости заказа на основе цен входящих в него товаров, при этом алгоритмы определения цен на товары реализуются отдельно, в объектах «товар». Если для разных товаров применяются разные алгоритмы вычисления цены, это достаточно легко реализовать в модели за счет создания разных типов товаров.
Достоинством модели предметной области традиционно признается гибкость. Объектный подход предоставляет в распоряжение разработчика множество способов моделирования отношений и распределения ответственности между объектами, что позволяет настраивать бизнес-логику в очень широких пределах. Кроме того, важной особенностью объектного подхода является то, что объекты могут близко соответствовать понятиям прикладной области, что в принципе позволяет разработчику и заказчику «говорить на одном языке».
Еще одним доводом в пользу объектного моделирования является то, что подавляющее большинство типовых решений – шаблонов проектирования – создано именно для применения в объектной модели. Шаблоны позволяют разрабатывать объектные структуры с заданными свойствами. В частности, создатели шаблонов уделяют значительное внимание последствиям применения шаблонов и возможностям внесения изменений в объектные структуры, предлагаемые шаблонами.
Однако за все приходится платить. В случае объектного подхода за исключительную гибкость приходится платить необходимостью выработки определенного, своеобразного стиля мышления. Новичкам приходится затрачивать много времени даже на то, чтобы разобраться в имеющейся объектной структуре (например, в шаблоне), не говоря уже о самостоятельном проектировании объектной структуры. Не всем удается преодолеть барьер освоения этой технологии; многие разработчики, даже работая на объектно-ориентированном языке и применяя объектные библиотеки, фактически используют процедурный стиль программирования.
Другая особенность модели предметной области – необходимость создания сложных программных механизмов взаимодействия объектных структур с реляционными базами данных. Разработка такого механизма обычно обходится дорого (хотя на этот счет тоже имеются типовые решения), и это, конечно, не упрощает жизнь в случае применения объектной модели.
Модуль таблицы (смешанный подход)
Перечисленные выше методы организации бизнес-логики представляют собой два «крайних» случая. Третий случай – смешанный, гибридный подход, сочетающий в себе определенные достоинства (и недостатки) функционального и объектного подходов.
Типовое решение «модуль таблицы» предусматривает, как и в модели предметной области, отдельные объекты для товаров, заказов и т.д. Однако, в отличие от «настоящей» модели предметной области, в модуле таблицы для работы со всеми (к примеру) заказами, содержащимися в базе данных, применяется только один объект. Именно этот единственный объект содержит логику обработки заказов. А чтобы работать с отдельным заказом, следует указывать его уникальный идентификатор.
Перечитайте предыдущий абзац.
Вас не пугает то, что в нем написано? И вам все понятно? Тогда, скорее всего, для вас не будет иметь значения недостаток данного подхода – сложность разработки и сложность восприятия кода. С точки зрения прозрачности, читабельности кода модуль таблицы заметно проигрывает «настоящей» модели предметной области (конечно, предполагается, что разработчик в каждом случае использует максимум возможностей сделать код простым и понятным). При несложной логике предметной области модуль таблицы проигрывает в простоте реализации и функциональному подходу.
Основные преимущества модуля таблицы – простота взаимодействия с базой данных и гибкость структурирования бизнес-логики по сравнению с функциональным подходом. Возможно также применение шаблонов проектирования. Однако по сравнению с моделью предметной области гибкость и возможности применения шаблонов в модуле таблицы существенно ограничены.
Целесообразность применения модуля таблицы также зависит от уровня поддержки структуры множества записей в конкретной среде разработки (включая удобство отображения множества записей на базу данных и на элементы графического интерфейса). Развитая поддержка набора данных (DataSet) в среде Microsoft .Net во многих случаях оправдывает применение этой платформы разработки.
Что мы выбираем
Особенности подходов
Перечислим основные особенности рассмотренных типовых решений, позволяющие сравнивать эти решения между собой и выбирать подход, соответствующий задаче.
Сценарий транзакции (функциональный подход): предельно прост, плохо работает при сложной логике, затрудняет развитие системы.
Модель предметной области (объектный подход): наиболее сложный и затратный, позволяет реализовать сложную бизнес-логику, дает возможность «цивилизованно» развивать систему; для простых систем подход целесообразен, только если уже «обкатан» разработчиком.
Модуль таблицы (смешанный подход): обеспечивает определенное сочетание простоты и гибкости, однако гибкость ограничена, а эффективность подхода зависит от среды разработки.
На основе рассмотренных особенностей можно сформулировать несколько критериев и предложить упрощенную схему выбора подхода на основе качественной оценки критериев.
Качественные критерии и схема выбора
Особенности типовых решений показывают, что решение по выбору подхода можно принять на основе качественной оценки следующих критериев:
— опыт команды разработчиков;
— стабильность бизнес-логики (ожидаемая стабильность функциональных требований);
— сложность бизнес-логики (функциональная сложность задач, решаемых программной системой);
— среда разработки (удобство работы с множеством записей).
Схема принятия решения на основе этих критериев приведена на рисунке.
Упрощенная схема выбора типового решения для реализации бизнес-логики
На схеме хорошо видно, что в некоторых случаях выбор сделать очень легко. Например, когда приложение простое, изменений не предвидится, да и с объектной моделью связываться непривычно – с чистой совестью применяем простой функциональный подход. С другой стороны, команда фанатов объектного подхода будет строить объектную модель предметной области во всех случаях – и правильно сделает (учитывая то, что такая команда вряд ли будет заниматься тривиальными проектами).
Пограничные ситуации требуют оценки стабильности и сложности разработки. На предлагаемом уровне это не должно вызвать затруднений.
Данная методика предназначена в первую очередь для оперативного «прокручивания» в голове с целью избежать грубых ошибок при выборе программного решения. Подобная систематизация также представляется полезной как первый шаг программиста к сознательному и ответственному проектированию приложений, в противоположность «проектированию на лету».
В реальных проектах, как обычно, все обстоит сложнее. Например, вопрос организации бизнес-логики может теряться на фоне массы других вопросов разработки архитектуры. Однако это не значит, что решение нужно пускать на самотек. Приведенная схема показывает, что можно предельно упростить принятие решения, не теряя при этом возможность выявить «подводные камни».
Вкратце
Решение по организации прикладной логики программной системы непосредственно влияет на качество создаваемого изделия. Это решение может и должно приниматься сознательно, исходя из требований и применяемых технологий. В идеале при выборе программного решения следует учитывать гораздо больше факторов, чем мы здесь упоминаем. Однако использование предлагаемой схемы выбора может стать первым шагом к формированию привычки выбирать обоснованное решение по организации бизнес-логики.
Источник: techwriters.ru
Описание бизнес логики программы
Ключевой вопрос: Из каких объектов, свойств, функций и взаимосвязей должен состоять продукт, чтобы с желаемым качеством удовлетворить потребности потребителей?
Непротиворечивость и полнота бизнес-логики продукта определяют его возможности по созданию, масштабированию и дистрибуции ценности до потребителя.
1. Артефакты и документы
Модель предметной области
Модель, определяющая сущности и их взаимосвязи, из которых состоит та или иная система. Чем сложнее продукт, амбиции по усилению ценности или масштабированию, тем большее значение принимает правильно выстроенная бизнес-логика этого продукта. Именно она является ограничителем роста и источником технического долга.
Нефункциональные требования
Описание требований к общим свойствам продукта или его частей, не связанных с пользовательскими функциями. Например, требования по доступности, совместимости, портируемости, надежности, масштабируемости, безопасности и т.д.
Перечень ключевых терминов продукта или элементов, из которых состоит технологическая система продукта, и их определений. Необходима для того, чтобы сотрудники компании разговаривали на одном языке, сокращая двусмыленность и неопределенность.
Дизайн система
Формализация предметной области продукта при помощи элементов пользовательского интерфейса. Определяет не только атомарные единицы, из которых состоит интерфейс (кнопки, цветовая палитра, шрифты, расстояния между элементами, комбинации из примитивов и т.д.), но и паттерны и метаформы взаимодействия пользователя с ним.
2. Модели и инструменты
Entities Analysis
Модель описания бизнес-логики продукта, представленная в виде перечня главных объектов системы (сущностей), их взаимосвязей и атрибутов. Правильный выбор сущностей и их взаимосвязей является ключевым фактором для построения масштабируемых, гибких и консистентных продуктов. Популярные типы связей между сущностями: ассоциация, генерализация, композиция, агрегация, абстракция. Для каждой связи определяется тип кратности. Для сущностей могут быть определены её атрибуты.
Sequence Diagrams
Диаграммы последовательности используются для отображения информации, которая передается между объектами или процессами системы при их взаимодействии во время выполнения сценария пользователя. Последовательность передачи сообщений реализована через временную шкалу.
Источник: productframework.ru
Что такое бизнес-логика? Определение и примеры
Бизнес-логика относится к правилам или командам, которые позволяют базе данных взаимодействовать с приложением конечного пользователя. Полезно изучать различные компоненты бизнес-логики, чтобы компания могла создавать эффективные процедуры обработки данных и оптимизировать ежедневные производственные усилия. В этой статье мы определяем бизнес-логику, объясняем ее назначение и делимся примерами бизнес-логики.
Что такое бизнес-логика?
Бизнес-логика — это набор компьютерных алгоритмов, содержащих рекомендации по созданию, хранению и обработке данных во внутреннем программном обеспечении или на сервере компании. Обычно он описывает серию протоколов, которые возникают после того, как сотрудники создают или изменяют строки данных. Например, бизнес-логика для розничного магазина может содержать информацию о запасах и может помочь отслеживать, сколько продуктов вы продаете за определенный период времени. Бизнес-логика также может определять, как вычислять числовые данные для различных целей, включая информацию о продажах и налогах.
Вот несколько ключевых терминов для изучения бизнес-логики:
- База данных: здесь описываются категоризированные наборы данных, хранящиеся на жестком диске компьютера, часто с использованием специализированного программного обеспечения. Сотрудники используют базы данных для доступа к бизнес-логике для достижения рабочих целей.
- Программное обеспечение для управления данными: здесь описывается программное обеспечение, которое вы можете использовать для управления данными из нескольких баз данных. Он также преобразует данные в более доступные форматы для использования нетехническими сотрудниками.
- Рабочий процесс: слово, описывающее шаги, необходимые для выполнения действия с использованием данных. Рабочие процессы бизнес-логики позволяют сотрудникам выполнять определенные процедуры, например компилировать различные продукты, которые покупает клиент.
- Триггер: это слово описывает код в рабочем процессе, который генерируется после одного события в рабочем процессе. Например, щелчок по имени человека в программном обеспечении для расчета заработной платы может привести к тому, что на экране появится его платежная информация.
Какова цель бизнес-логики?
Бизнес-логика позволяет компании управлять и получать доступ к большим объемам данных для повседневной работы и практики. Он переводит протоколы компании в полезные данные для компьютерных систем, чтобы сотрудники могли отслеживать важные задачи и обновлять информацию. Компании может потребоваться бизнес-логика, чтобы лучше гарантировать, что любые повседневные задачи, связанные с несколькими категориями данных, могут оставаться работоспособными и эффективными.
Программы для Windows, мобильные приложения, игры — ВСЁ БЕСПЛАТНО, в нашем закрытом телеграмм канале — Подписывайтесь:)
Например, рассмотрим компанию, которая использует кассовую программу для управления запасами и покупками. Технический специалист может ввести бизнес-логику в эту программу, чтобы определить шаги для ввода информации о кредитной карте, создания точных квитанций и других подобных задач. Чтобы выполнить одну из этих задач, сотрудникам нужно только выполнить эти введенные шаги в программе кассового аппарата, чтобы изменить данные, а не прочитать сами данные.
Каковы компоненты бизнес-логики?
Вот основные компоненты бизнес-логики:
Согласованность данных
Согласованность данных относится к данным, которые человек вводит в соответствии с рекомендациями по бизнес-логике, и соответствует другой информации в базе данных. Когда данные непротиворечивы, сотрудники могут выполнять рабочие процессы и более легко просматривать одну и ту же информацию.
Например, рассмотрим сотрудника, вводящего информацию о клиенте в форму с помощью внутреннего программного обеспечения. Для обеспечения согласованности данных форма позволяет сотруднику вводить только определенную информацию в определенном формате, например числовые значения при вводе даты рождения или номера телефона.
Участник контроля
Контроль участников относится к тому, как база данных определяет, какие сотрудники видят определенные строки данных в соответствии с рекомендациями бизнес-логики. Для бизнес-логики важно определить полезную информацию для просмотра определенными сотрудниками, чтобы они могли упростить свое взаимодействие с компьютерной системой.
Например, рабочие процессы бизнес-логики могут позволить менеджеру по продажам просматривать столбцы данных, касающиеся квот продаж для всех людей в компании, в то время как сотрудник розничной торговли может видеть только данные, касающиеся своей собственной квоты продаж.
Проверка модификации
Подобно контролю участников, проверка модификации относится к тому, как база данных определяет, какие сотрудники могут изменять определенные строки данных. Некоторые данные могут иметь решающее значение для повседневных операций компании, поэтому для бизнес-логики важно указать, какие пользователи могут вносить более значительные корректировки.
Например, рассмотрим компанию, которая соблюдает юридические требования в отношении того, какую информацию о персонале они могут хранить. Рабочие процессы бизнес-логики могут разрешать только сотрудникам отдела кадров изменять данные для личных дел, поскольку их обучение требует, чтобы они понимали эти правила.
Примеры бизнес-логики
Рассмотрим эти примеры бизнес-логики, которую компания может включать:
Поток данных
Поток данных определяет, как база данных обрабатывает и фильтрует информацию, когда пользователь выполняет действие. Он также определяет, какие события должны произойти, чтобы произошло другое событие.
Чтобы создать поток данных, вы обычно определяете причинно-следственные связи между строками данных и учитываете различные способы, которыми пользователь может выполнять это действие. Например, поток данных может описывать шаги, необходимые человеку для входа на веб-сайт, включая информацию об имени пользователя, пароле и дополнительном секретном вопросе.
Проверка данных
Проверка данных описывает тщательный процесс поддержания точных и высококачественных данных. Чтобы использовать проверку данных в вашей бизнес-логике, вы можете создать процедуру тестирования в программе базы данных, чтобы лучше убедиться, что люди могут вводить правильные данные в нужном месте. Например, проверка данных может определить, вводит ли человек правильное написание и формат данных почтового адреса.
Вот некоторые распространенные типы проверки достоверности данных:
- Проверка типа данных: проверяет, отражает ли введенная строка данных правильную классификацию, например текст или числовые данные.
- Проверка длины: проверяет, содержат ли введенные данные правильный объем информации, в том числе не являются ли они слишком длинными для определенной скобки.
- Проверка диапазона: наблюдает, соответствуют ли числовые данные заранее определенному диапазону чисел и целых чисел, например, от 10 до 100.
- Проверка порядка данных: чтобы определить, отражают ли введенные данные логический порядок, например дату доставки посылки, записанную после того, как клиент заказал время, которое она несет.
- Проверка уникальности: для наблюдения за тем, дважды ли человек вводит одну и ту же строку данных в одну и ту же программу, что может привести к появлению определенных ошибок.
Транзакция базы данных
Транзакция базы данных описывает процедуры для изменения данных из одного состояния в другое. Важно писать транзакции базы данных для бизнес-логики, потому что это позволяет точно корректировать большие объемы данных, что может повлиять на несколько областей повседневной деятельности компании.
Например, рассмотрим сотрудника банка, который переводит деньги с одного счета на другой с помощью программного обеспечения для работы с данными. Для обеспечения согласованности данных программное обеспечение позволяет сотруднику вводить в форму только определенные числовые значения, чтобы они могли переводить правильную сумму денег между счетами.
ACID и бизнес-логика
При описании свойств транзакций базы данных многие люди ссылаются на аббревиатуру ACID. Вот определения каждого термина ACID и их связь с бизнес-логикой:
- Атомарность: это свойство описывает, как человек изменяет несколько разделов данных одним действием, учитывая при этом все аспекты этих данных. Например, если клиент покупает предмет, свойство атомарности показывает, что транзакция удалила этот предмет из вашего инвентаря.
- Непротиворечивость: как и вышеупомянутый компонент бизнес-логики, это свойство подчеркивает, что человек может изменять данные только при определенных условиях. Он также показывает, что данные до транзакции отражают точное состояние после транзакции.
- Изоляция: это свойство описывает, как данные, используемые во время транзакции, невидимы для некоторых пользователей, пока вы не завершите их полностью, то есть другой человек не может использовать их для другой транзакции в то же время. Например, некоторые банковские приложения позволяют клиентам совершать только один банковский перевод в день, чтобы включить свойство изоляции.
- Долговечность: после завершения транзакции свойство долговечности описывает, насколько постоянны эффекты данных, что означает, что они могут оставаться активными, если база данных когда-либо выйдет из строя в будущем. И наоборот, в нем показано, как база данных может восстановить себя до состояния до транзакции, если во время процесса произойдет сбой.
Преобразование данных
Преобразование данных описывает правила изменения раздела формата или структуры данных. Это может включать добавление строк данных, объединение разделов или их воспроизведение в базе данных другого типа. Люди, пишущие бизнес-логику, могут преобразовывать данные, чтобы оптимизировать поток информации между разными сотрудниками или модернизировать систему, которую компания использует для выполнения важных действий.
Например, рассмотрим театральную компанию, которая переходит на новое программное обеспечение для продажи билетов в середине сезона. В результате они преобразуют данные, хранящиеся в их старой программе, чтобы сделать их читаемыми для новой.
Расчет данных
Расчет данных — это процесс объединения числовых данных для создания суммы, которую можно использовать для нескольких приложений, включая производственные затраты. Компании обычно используют специальные цифровые инструменты для точного расчета числовых данных и их интерпретации по прямому назначению.
Например, человек, пишущий бизнес-логику, может включить алгоритм расчета налоговой информации с использованием определенной математической формулы. Сотрудник может использовать эту бизнес-логику, чтобы добавить сумму налога к покупке клиента, чтобы получить их общую сумму.
Уведомление о данных
Уведомления о данных описывают окна, которые появляются, когда человек получает доступ к определенным данным или выполняет рабочий процесс. Люди, которые пишут бизнес-логику, могут включать уведомления, чтобы сотрудники могли лучше понять, на какой информации в базе данных следует сосредоточиться.
Например, рассмотрим потоковую компанию, которая позволяет подписчикам смотреть 10 бесплатных видео в день. Алгоритм, встроенный в систему данных, может уведомлять маркетинговую команду, когда человек нажимает на свое 11-е видео. После этого эта команда может отправить клиенту сообщение, рекламирующее обновление подписки, которое увеличивает количество видео, которые они могут смотреть, до двадцати.
Источник: buom.ru