Бизнес логика приложения определяется

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

Добавить к сведениям о нотациях можно еще две:

• BPMN (Business Process Model and Notation) — нотация и модель бизнес-процессов, система обозначений позволяющая моделировать бизнес-процессы
• EPC (Eevent-driven process chain) — событийная цепочка процессов используется для бизнес-моделирования, может быть применена для настройки системы планирования ресурсов предприятия и для улучшений бизнес-процессов.

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

Категории бизнес-задач организации

• управление клиентской базой — группа задач по сопровождению новых клиентов, оперативное управление, снятие клиентов с сопровождения, проведение ABC и XYZ анализов
• управление контактами — организация контроля и аналитика любых видов контактной информации (контактные данные, проведение встреч, переговоры, переписка)
• управление продажами — полное регулирование вопросов отдела продаж от предварительных контактов до заключения сделки
• управление сервисным обслуживанием — обеспечивание процессов отдела сервисного обслуживания
• управление претензиями и рекламациями — учёт обращений клиентов, взаимодействие с отделами для устранения проблем, взаимодействие с поставщиками товаров или услуг
• управление качеством менеджмента — контроль и аналитическая работа по определению уровня качества менеджмента в соответствии с обозначенными стандартами
• управление маркетинговыми процессами — обеспечение проведения маркетинговых исследований и анализ результатов
• управление заданиями и поручениями — построение маршрутов задач и контроль их выполнения, делегирование отдельных поручений по ответственным лицам
• контроль работы персонала — предоставляет аналитические результаты для управления подчинёнными сотрудниками, сводные анализы результативности работы и другой информации по отделам

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

#8 Бизнес логика или детали реализации? — Vue.js: концепции

Перспективные модели бизнес-процессов

Существуют четыре основных перспективы, в которых можно рассматривать модель бизнес-процесса:

• функциональная модель — описывает состав выполненных работ и отвечает на вопрос: «что делают участники?»
• поведенческая модель — описывает последовательность действий, расписание и другие принципы бизнес-правил, отвечает на вопрос: «как работают?»
• информационная модель — описывает бизнес-сущности предметной области бизнес-процессов и указывает на информационные объекты, которые обрабатывают участники бизнес-процессов, отвечает на вопрос: «что обрабатывают?»
• организационная модель — описывает состав исполнителей, иерархию подчинения, соподчинённость, указывает ответственные лица для каждого действия, отвечает на вопрос: «кто выполняет?».

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

Что такое бизнес-логика и как ее изолировать

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

Условия, корректирующие проект бизнес-процесса

Основные факторы влияния на модель бизнес-процесса представлены в следующей схеме:

Прокомментирую каждый из представленных блоков:

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

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

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

В следующей статье этой серии будут рассмотрены некоторые основные схемы формализации бизнес-процессов.

Источник: dzen.ru

Какая часть шаблона проектирования MVC представляет бизнес-логику?

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

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

и в другом веб-сайте Я прочитал следующее определение с примером:

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

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

user3260672 16 авг. 2015, в 22:26
Поделиться
Модель должна быть там, где сделана бизнес-логика
smoggers 16 авг. 2015, в 19:49

в самом строгом смысле ничего из вышеперечисленного. Asp.Net MVC — это структура представления. M Одел является бизнес — данных , которые вы хотите отобразить, то V IEW путь отображения данных, и C ontroller обрабатывает взаимодействия между View, модели и бизнес — логики в других уровнях приложения. Вы можете выполнять всю свою бизнес-логику в контроллере (или модели), если ваше приложение достаточно маленькое, но во многих случаях оно не обрабатывается ни на одном из этих трех уровней.

Claies 16 авг. 2015, в 19:56
user3260672 16 авг. 2015, в 20:16

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

Claies 16 авг. 2015, в 20:18

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

Источник: overcoder.net

Определение, что такое бизнес и что такое логика приложения

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

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

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

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

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

Логика приложения

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

Основная проблема и вопрос

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

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

Примеры (прочитайте этот раздел, если вопрос все еще неясен для вас)

Примеры, из которых приходит неизвестность:

• при описании «деловые люди» могут упоминать или не упоминать:

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

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

Class CalculatorModel extends Model < public int firstNumber; public int secondNumber; public int result; public void calculate() < this->result = this->firstNumber + this->secondNumber; > >

Тогда контроллер будет выглядеть так:

Class CalculatorController extends Controller < public void onCalculateButtonClick() < this->model->calculate(); > >

Давайте не будем обращать внимания на то, что бизнес сказал, что по щелчку мы должны выполнить вычисление и поместить эту часть в контроллер, который предназначен для логики приложения, потому что MVC заявляет, что контроллеры должны обрабатывать такие вещи, в любом случае у нас другая проблема — где мы обновляем first а также second Number поля? Если этот подход используется, то он просто становится неясным, поскольку разные люди могут и не могут упомянуть его, что не делает его ни бизнесом, ни логикой приложения, ни обоими из них, что, конечно, не имеет никакого смысла.

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

Class CalculatorController extends Controller < public void updateNumbers() < this->model->firstNumber = input1->text; this->model->secondNumber = input2->text; > public void onCalculateButtonClick() < this->updateNumbers(); this->model->calculate(); > >

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

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

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

Надеюсь, я ясно дал понять, и вы сможете полностью понять проблему, чтобы иметь возможность помочь и / или, возможно, высказать свое мнение о правильном способе разработки приложений с использованием Model-View-Controller.

Источник: stackru.com