Бизнес логика бизнес правила

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

• «Бизнес-логика — это часть вашей программы, которая кодирует реальные бизнес-правила». Большинство определений, которые я прочитал, являются круглыми, как это.
• «Бизнес-логика — это все уникальное для вашего конкретного приложения». Я не понимаю, чем это отличается от «ваше конкретное приложение — не что иное, как бизнес-логика», если только мы случайно не заново изобрели набор колес, для которых мы могли бы использовать существующее стороннее программное обеспечение. Отсюда и название вопроса.
• «Должен быть уровень бизнес-логики выше уровня доступа к данным и ниже уровня графического интерфейса». В коде, который я пишу, инициаторы доступа к базе данных должны знать, к каким данным они должны обращаться, и код пользовательского интерфейса должен знать много о том, что он отображает, чтобы правильно отображать его, и между ними действительно ничего не нужно делать. эти два места, кроме передачи больших двоичных данных между клиентом и сервером. Так что же на самом деле должно входить в уровень бизнес-логики?
• «Бизнес-логика должна быть отделена от логики представления». Большинство запросов к функциям, которые мы получаем, должны изменить логику представления по деловым причинам. Если одно из бизнес-правил состоит в том, чтобы по умолчанию отображать цены государственных облигаций США в 32-й записи (при этом пользователь также может настраивать пользовательский интерфейс), логике представления необходимо, по крайней мере, знать, что это правило существует, если оно не реализовано полностью. Кроме того, похоже, что основная часть UX-дизайна помогает пользователю понять бизнес-правила, которые пытается реализовать наше программное обеспечение.

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

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

Чтобы конкретизировать ответы: представьте, что вам нужно переопределить приложение Domino’s Pizza. Что такое бизнес-логика и какова не-бизнес-логика этого приложения? И как можно было бы поместить эту бизнес-логику для заказа пиццы в ее собственный «слой» кода, без того, чтобы большая часть информации о пицце перетекла на уровни доступа к данным и представления?

Обновление: я пришел к выводу, что моя команда, вероятно, делает 90% кода пользовательского интерфейса, и большая часть — но не все — того, что вы бы назвали бизнес-логикой, исходит от других команд или компаний. В основном наше приложение для мониторингафинансовые данные и почти все функции позволяют пользователям настраивать, какие данные они видят и как они их видят. Покупки или продажи не ведутся (хотя мы немного интегрируемся с другими приложениями нашей компании, которые это делают), а фактические данные поступают от множества внешних источников. Но мы разрешаем пользователям делать такие вещи, как отправка копий своих «мониторов» другим пользователям, поэтому детали того, как мы поступаем, вероятно, квалифицируются как бизнес-логика. На самом деле есть мобильное приложение, которое в настоящее время общается с некоторым из нашего внутреннего кода, и я точно знаю, какой частью нашего кода веб-интерфейса я хотел бы поделиться им с нашим пользовательским интерфейсом в идеальном мире (в основном это M в нашем квази-MVC), поэтому Я предполагаю, что это BLL для нас.

Что такое “бизнес логика”? И как начать ее понимать

Я принимаю ответ user61852, поскольку он дал мне гораздо более конкретное понимание того, что «бизнес-логика» делает и не относится к ней.

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

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

Если вы заказываете более 50 долларов, вы получаете бесплатные хлебные палочки с инкрустированным сыром.

«Если одно из бизнес-правил состоит в том, чтобы по умолчанию отображать цены государственных облигаций США в 32-х нотном виде (при этом пользователь также может настраивать его для пользовательского интерфейса), логике представления необходимо, по крайней мере, знать, что это правило существует», нет, нет и некоторые сказали бы, не должны. пользовательский интерфейс может иметь только метку / текстовое поле / виджет для отображения любой строки, которую бизнес-логика (или, скорее, модель, но . ) передала ей.

Я дам вам несколько советов, касающихся CRUD- приложений, поскольку у меня нет большого опыта в играх или графически насыщенных приложениях:

• Бизнес-логика обычно включает в себя правила, которые владелец бизнеса выучил или решил за годы своей работы, например: «отклонить новый кредит, если клиент еще не закончил платить последний» , или «мы не продаем завтрак» после 11 часов утра » или » по понедельникам и вторникам клиенты могут купить две пиццы по цене одной » .
• Конечно, уровень представления должен показывать сообщение, указывающее наличие скидки или причину отклонения кредита, но такой уровень не решает эти вещи, он только сообщает пользователю о том, что произошло под капотом.
• Бизнес-логика обычно включает в себя рабочий процесс , например: «этот элемент должен быть утвержден каким-либо менеджером в течение 3 рабочих дней или помещен в стадию« запроса информации », если клиент не представил требуемые документы, то элемент отклоняется» ,
• Уровень представления обычно не связан с такого рода рабочим процессом, он только отражает состояние рабочего процесса.
• Кроме того, уровень доступа к данным обычно прост, потому что решения уже приняты бизнес-логикой. Этот уровень затрагивается, когда вы решаете перенести данные с MS SQL Server на Oracle, например
• Это правда, что иногда GUI выполняет некоторую проверку, чтобы избежать обращений к серверу, но это нужно делать разумно, иначе у вас может быть много бизнес-логики на этом уровне.
• Большая часть вашего замешательства, возможно, возникла из-за того, что в вашем приложении нет разделения интересов, и фактически у вас слишком много бизнес-логики на уровне представления. Тот факт, что у вас (ошибочно) есть бизнес-логика на уровне приложений или на уровне доступа к данным, не меняет того факта, что это бизнес-логика.
• Такие вещи, как отображение расстояний в метрической системе вместо миль / ярдов / футов — это не логика представления, а бизнес-логика . Бизнес-уровень должен возвращать данные в требуемых единицах и сообщать уровню представления, какие единицы он обрабатывает, чтобы он отображал соответствующие метки, но это определенно проблема бизнес-логики.
• На бизнес-логику не должно влиять то, что вы сейчас используете Oracle вместо Postgres, или тот факт, что компания изменила свой логотип или таблицу стилей.
• Бизнес-правила существуют независимо от того, автоматизируете ли вы их , написав приложение. Они могут быть применены, даже когда бизнес использует низкотехнологичное решение, такое как ручка и бумага.
• Если у вас есть мобильная версия настольного приложения или веб-версия , каждая из этих версий имеет свой уровень представления , но (надеюсь), один и тот же бизнес-уровень.

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

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

Сохранение формата в cookie, также может быть реализовано на уровне представления.

Однако это может быть реализовано способом MVC. (Некоторые модели реализуют представление как собственный MVC, способный работать с предпочтениями.)

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

Сделайте обоснованное предположение о вашем заявлении.

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

• Выполнение поиска и предоставление представления для отображения.
• Поиск цен на облигации и предоставление для отображения.
• Сравнение урожайности и предоставление данных для отображения.
• Обработка заказов и хранение их в модели.

Если это сделано правильно, должна быть возможность предоставить несколько компонентов представления без изменения модели или бизнес-логики. Например, если текущим дизайном является веб-сайт, новый сервер представления для приложения iPhone или Android будет использовать существующую модель и бизнес-логику. Они могут вводить новые бизнес-функции для предоставления push-уведомлений при выполнении заказа, что может потребовать внесения изменений в несколько уровней.

Эта разбивка позволяет разделить проблемы.

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

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

Бизнес логика бизнес правила

В статье рассматривается проблема построения онтологии набора бизнес-правил контроля достоверности данных. Обосновывается необходимость обеспечения единого непротиворечивого представления версионных наборов бизнес-правил контроля достоверности данных. Предлагается онтологическое модельное представление набора бизнес-правил на основе аппарата дескрипционной логики.

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

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

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

1. Вигерс К.И. Разработка требований к программному обеспечению: пер. с англ. – М.: Русская Редакция, 2004. – 576 с.

2. Дубинин В.Н., Вяткин В.В. Семантический анализ описаний систем управления промышленными процессами на основе стандарта IEC 61499 с использованием онтологий // Известия высших учебных заведений. Поволжский регион. Технические науки. – 2010. – № 3 (15). – С. 3–15.

3. Фишбейн А.И. Представление наборов бизнес-правил контроля достоверности данных в виде онтологии на основе дескрипционной логики // Новые информационные технологии и системы: материалы конференции. – Пенза, 2012. – С. 329–332.

4. Фишбейн А.И., Шибанов С.В. Анализ избыточности версионного набора бизнес-правил контроля достоверности данных // Математическое и программное обеспечение систем в промышленной и социальной сферах. – 2014. – № 2. – С. 81–89.

5. Фишбейн А.И., Шибанов С.В. Перестраиваемая архитектура программных средств контроля достоверности данных в клиент-серверных информационных системах // В мире научных открытий. – 2014. – № 6.1 (54). – С. 399–423.

6. Шибанов С.В., Фишбейн А.И. Универсальный интерфейс взаимодействия компонент программных средств контроля достоверности данных // Перспективы науки. – 2014. – № 9 (60). – С. 91–100.

7. Horrocks I., Kutz O., Sattler U. The Even More Irresistible SROIQ // In Proc. of the 10th Int. Conf. on Principles of Knowledge Representation and Reasoning (KR 2006). – AAAI Press, 2006.

8. Rudolph S. Foundations of Description Logics // In Reasoning Web: Semantic Technologies for the Web of Data, 7th International Summer School, volume 6848 of Lecture Notes in Computer Science. Springer. – 2011. – P. 76–136.

9. The Description Logic Handbook. Theory, implementation and applications / Baader F., Calvanese D., McGuinness D., Nardi D., Patel-Schneider P. – New York: Cambridge University Press, 2003. – 574 p.

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

Достоверность является одним из важнейших свойств данных, обрабатываемых информационными системами (ИС) любого назначения. Достоверность данных обеспечивается за счет контроля соответствия данных семантическим ограничениям, выделенным в предметной области ИС. Такого рода ограничения называются бизнес-правилами (БП) и представляют собой определяющие или ограничивающие утверждения, относящиеся к конкретному аспекту работы ИС и фиксирующие закономерности в данных. Примеры БП: «количество студентов на курсе не может быть больше суммы количества бесплатных и платных мест», «размер выданной заработной платы должен равняться сумме оклада, надбавки за стаж и премии» [3, 6].

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

где b – бизнес-правило; id – идентификатор БП; P – предикат, определяющий, выполняется ли условие БП; x1…xn – данные, используемые бизнес-правилом; a – реакция на нарушение БП.

Подсистема контроля достоверности данных (КДД) должна хранить бизнес-правила и проверять данные на соответствие им. В процессе эксплуатации ИС бизнес-правила могут изменяться и корректироваться. [1] Это может быть связано с изменениями в законодательстве, расширением сферы деятельности организации, изменениями в предметной области, модификацией бизнес-процессов и так далее. Соответственно, подсистема КДД должна позволять добавлять новые БП, изменять и удалять уже существующие БП в процессе функционирования системы, не нарушая её работы. [5]

Множество всех бизнес-правил ИС образует бизнес-логику:

где B – бизнес-логика; bi – i-е бизнес-правило; n – количество бизнес-правил.

Множество бизнес-правил ИС может быть разделено на подмножества-наборы согласно различным принципам:

fl:B → Sl;

где fl – l-я функция, согласно некоторому принципу разбивающая B на наборы; B – бизнес-логика; Sl – множество наборов бизнес-правил, получившихся в результате разбиения B; – j-й набор бизнес-правил; k – количество получившихся наборов БП.

Зачастую бизнес-правила также имеют версии. Версией бизнес-правила является правило, связанное с другим, уже существующим, условием выбора между ними, и определяющее достоверность тех же данных. То есть выбор между тем, какое правило должно использоваться в некоторой ситуации, зависит от некоего условия, например для проверки некоторых данных могут использоваться разные версии правила, в зависимости от текущей даты. Таким образом, ИС имеет дело с версионными наборами БП [4].

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

Для представления бизнес-правил в качестве базовой предложена онтологическая модель, позволяющая описывать произвольные БП различных предметных областей и проводить анализ правил. Из семейства дескрипционных логик (ДЛ) – базового математического формализма онтологической модели – для решения поставленной задачи выбрана дескрипционная логика SROIQ(D) [7, 8].

Онтологическое модельное представление набора бизнес-правил контроля достоверности данных

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

Онтология O – это

где NC – множество концептов онтологии; NR – множество ролей онтологии; N – множество индивидов онтологии; TBox – набор утверждений о концептах онтологии; RBox – набор утверждений о ролях онтологии; ABox – набор утверждений об индивидах онтологии [8, 9].

Для онтологии представления версионного набора бизнес-правил контроля достоверности данных эти компоненты имеют следующий вид:

где NC,domain – понятия предметной области, задействованные в правилах; NC,br – бизнес-правила в виде правильных вариантов концепта, к которому относится правило; NC,nom – концепты-номиналы; NC,reaction – концепты, относящиеся к возможной реакции на нарушение БП; NR,domain – отношения между понятиями предметной области, задействованными в правилах; NR,prop – свойства концептов; NR,reaction – роли, относящиеся к возможной реакции на нарушение БП; AXC,domain,inclusion – аксиомы включения концептов-понятий предметной области; AXC,domain,eq – аксиомы эквивалентности концептов-понятий предметной области; AXC,br,eq – аксиомы эквивалентности концептов-БП; AXC,reaction,inclusion – аксиомы включения концептов, относящихся к возможной реакции на нарушение БП; AXC,br,reaction,inclusion – аксиомы включения концептов, определяющие реакцию на нарушение конкретного БП; AXC,ver,link,eq – аксиомы эквивалентности концептов, определяющие связи между версиями БП и условия выбора между ними; AXR,inclusion – аксиомы включения ролей; AXR,eq – аксиомы эквивалентности ролей; CHR,ref – характеристики рефлексивности ролей; CHR,asy – характеристики асимметричности ролей; CHR,dis – характеристики дизъюнктности ролей; CHR,trans – характеристики транзитивности ролей.

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

1. В ячейке (5; 6) должно быть значение 7.

2. Значение в ячейке (1; 2) должно быть меньше, чем в ячейке (2; 2).

3. Значение в ячейке (1; 2) должно быть меньше или равно, чем значение в ячейке (2; 2), и больше, чем значение в ячейке (3; 2). Это версия правила 2, и она должна использоваться, если отчёт, которому принадлежат ячейки, относится ко второму полугодию, в противном случае должно использоваться основное правило.

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

Пример 2. Сигнатура онтологии набора бизнес-правил из примера 1.

TBox содержит следующие аксиомы:

Ячейка5,6 ≡ Ячейка ∩ $номер_строки. ∩ $номер_столбца.

(БП1)

Ячейка1,2 ≡ Ячейка ∩ $номер_строки. ∩ $номер_столбца.

Ячейка2,2 ≡ Ячейка ∩ $номер_строки. ∩ $номер_столбца.

(БП2)

Ячейка3,2 ≡ Ячейка ∩ $номер_строки. ∩ $номер_столбца.

(БП3)

Помеченные БП1, БП2 и БП3 аксиомы, собственно, и являются бизнес-правилами КДД – они описывают условия, при соблюдении которых соответствующие данные считаются корректными. Фактически эти аксиомы являются определениями семантически правильных классов. [2] Индекс r используется, чтобы отметить такие правильные классы (концепты). Например, концепт – ячейка, имеющая индексы (1; 2) в таблице, для которой вдобавок выполняется соответствующее БП достоверности данных.

Методика построения онтологии набора бизнес-правил

Наиболее развёрнуто бизнес-правило КДД можно представить как контекстно-свободную формальную грамматику, с помощью формы Бэкуса – Наура.

БП ::= Условие_достоверности(Логическая_операция Условие_достоверности)*

Условие_достоверности ::= Логическое_выражение | Пусто

Логическое_выражение ::= Выражение (Логическая_операция | Операция_отношения) Выражение

Выражение ::= Константа | Переменная_концепт | Выражение Операция Выражение

Объектная_операция ::= иметь_значение | быть_частью | иметь_частью

Операция ::= Логическая_операция | Операция_отношения | Арифметическая_операция | Объектная_операция

Проводя соответствие с представлением наборов БП в виде онтологии, получаем следующий результат. Множество C,nom> содержит константы из выражений в бизнес-правилах. Множество C,domain> содержит переменные-концепты – задействованные в БП понятия предметной области. Множество C,br> содержит концепты-БП. Множество R,domain> содержит операции отношения, арифметические и объектные операции, представленные с помощью ролей.

Множество C,reaction> содержит концепты, относящиеся к возможной реакции на нарушение БП. В данной работе предлагается, что реакция на нарушение БП не произвольно описывается разработчиком правил, а выбирается из конечного числа доступных вариантов. Состав C,reaction> будет оставаться постоянным, поскольку зависит не столько от набора БП, сколько от возможностей ПС. Аналогично множество R,reaction> содержит роли, относящиеся к возможной реакции на нарушение БП. Для этого достаточно одной роли выполняет_действие.

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

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

Основные принципы создания аксиом определения концептов

Основные способы определения составного концепта – с помощью конъюнкции уже имеющихся в онтологии концептов, а также с помощью ограничения значения свойства (роли). Таким образом, предлагаются следующие варианты определения составных концептов:

1) новый концепт определяется как конъюнкция существующих концептов,

где Cnew – новый концепт; C1. Cn – уже существующие концепты, n ≥ 2. Этот вариант наиболее подходит для отображения в онтологию структуры ООП-классов, то есть, для отображения наследования классов;

Методика построения онтологии набора бизнес-правил

2) новый концепт определяется как конъюнкция существующих концептов и ограничений значения свойства (роли),

где Cnew – новый концепт; C1. Cn – уже существующие концепты; r1…rm – существующие роли; filler1…fillerm – заполнители ролей из объединения NC и NI, n ≥ 1, m ≥ 1. Это наиболее универсальный способ определения составного концепта;

3) новый концепт определяется как конъюнкция ограничений,

где Cnew – новый концепт; r1…rm – существующие роли; filler1…fillerm – заполнители ролей из объединения NC и NI, m ≥ 2. Этот способ в самостоятельном виде подходит для исключительных случаев, когда важно наличие и значение свойства, а не класс объекта.

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

Для ограничения значения свойства (роли) необходимо выбрать роль и заполнитель роли. Этот выбор должен совершаться согласно следующим правилам.

1. Выбор роли ограничивается предыдущим выбором концепта (концептов). Выбрать можно только роль, имеющую доменом выбранный концепт (или хотя бы один из выбранных концептов). Соответственно, если концепт не выбирался, то есть новый концепт описывается только с помощью ограничений, то данное условие снимается. То есть если выбраны концепты C1. Cn, то

где Mrole – множество доступных для выбора ролей; ri – i-я роль из NR; NR – множество ролей онтологии; D – заполнитель роли.

2. Выбор заполнителя роли ограничивается предыдущим выбором роли. Выбрать можно только заполнитель (концепт или экземпляр) из диапазона значений роли. То есть если выбрана роль r, то

где Mfiller – множество доступных для выбора заполнителей роли; filleri – i-й заполнитель роли из объединения NC и NI; NC – множество концептов онтологии; NI – множество индивидов онтологии; C – концепт из домена роли.

Пример процесса построения сигнатуры онтологии на основе БП согласно обозначенным принципам

Набор БП содержит единственное правило «Значение ячейки строки 25 столбца 1 больше значения ячейки строки 26 столбца 1 либо равно ему». В случае нарушения этого правила должна быть произведена запись в лог-файл. Это БП может быть представлено в следующем виде:

БП ::= (((Ячейка номер_строки 25) номер_столбца 1) содержит_значение Значение1) >= (((Ячейка номер_строки 26) номер_столбца 1) содержит_значение Значение2)

Согласно описанным ранее соответствиям:

Добавляя в NC составные концепты, получаем следующую сигнатуру:

TBox содержит следующие аксиомы:

Ячейка25,1 ≡ Ячейка ∩ $номер_строки. ∩ $номер_столбца.

Ячейка26,1 ≡ Ячейка ∩ $номер_строки. ∩$номер_столбца.

Выполнение_скр ипта ⊆ Реакция_на_ошибку

Заключение

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

Рецензенты:

Макарычев П.П., д.т.н., профессор, зав. кафедрой «Математическое обеспечение и применение ЭВМ», Пензенский государственный университет, г. Пенза;

Андреев В.Г., д.т.н., профессор, зав. кафедрой ЕНТД, Кузнецкий институт информационных и управленческих технологий, г. Кузнецк.

Источник: fundamental-research.ru

H Архитектура Enterprise на Yii2. Абстракция, инверсия зависимости, инкапсуляция бизнес-логики и управление изменчивостью в черновиках

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

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

• Применить промокод
• Отменить заказ
• Рассчитать размер вознаграждения продавцу

Как быть? Разрабатывать E-commerce сайты в стиле Enterprise: делить все на слои, хранить бизнес-логику в отдельном слое приложения, инкапсулировать изменчивость. И вообще, следовать принципам SOLID при написании кода.

На PHP в 2017 тоже можно писать качественный Enterprise, это уже не просто шаблонизатор. В статье рассказывается про некоторые вещи, которые обязательно применять при разработке Enterprise на примере PHP и Yii2 фреймворка.

• 1. Модульная слоистая архитектура
• 2. Инкапсуляция бизнес-логики
• 3. Абстракция и интерфейсы для нее
• 4. Инверсия зависимости
• 5. Управление изменчивостью
• 6. СОЛИД

1. Модульная слоистая архитектура

В настоящий момент мейнстримом является слоистая архитектура в ООП стиле. Программист видит информационную систему в виде слоев:

• Слой вью (представления);
• Доменный и сервисный слой (слой с бизнес-логикой);
• Слой моделей;
• Слой базы данных;
• Слои контроллеров c роутингом;

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

Но есть одна проблема — как правильно связать все эти маленькие компоненты, чтобы приложение выглядело как единое целое, а не как куча костылей и велосипедов? В борьбе за ответ на этот вопрос родился принцип IoC (Inversion of control или инверсия управления). Принцип гласит о том, что любой ваш класс или компонент не должен жестко зависеть от других, ваш код должен работать с тем, что ему передало приложение. Код должен быть слабосвязанным и каждая его структурная частичка (классметодкомпонент) должна выполнять лишь одну обязанность. Продолжим про инверсию зависимости в пункте 4, а пока отвлечемся на бизнес-логику и абстракцию.

2. Инкапсуляция бизнес-логики

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

Если мы отделим бизнес-логику, то получим:

• Тонкий слой контроллеров и модулей;
• Возможность тестировать в изоляции важнейшие бизнес-процессы;
• Переносимость кода.

• Отменить заказ;
• Добавить элементы в заказ;
• Отменить элемент заказа;
• Присвоить клиента заказу ;
• Присвоить продавца заказу;
• Изменить статус;
• Подсчитать сумму заказа;
• Подсчитать общее количество элементов в заказе.

В логике работы с моделями благодаря ActiveRecord имеются похожие штуки:

• save;
• delete;
• load;
• link и т.д.

$model = new Order; //Это слой моделей $db = Order::find(); //А это уже слой БД $db = $db->where([‘id’ => ‘1’])->one(); //Снова слой моделей

Чтобы закрепить, давай проведем соответствия «название метода» — «слой»:

• getFullName — выносим в модель ActiveRecord, слой моделей
• getUserByName — в ActiveQuery, слой работы с БД
• showFields — в виджет или вью-файл, слой отображения
• cancelCashboxTransaction — бизнес логика, сервисный или доменный слой

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

$order = Order::fineOne(1); yii::$app->order->cancel($order);

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

Order.php

Filling::class, ‘order’ => $order])->execute(); > public function cancel(OrderInterface $order) < return yii::createObject([‘class’ =>OrderCancel::class, ‘order’ => $order])->execute(); > public function recovery(OrderInterface $order) < return yii::createObject([‘class’ =>OrderRecovery::class, ‘order’ => $order])->execute(); > //.

Его можно добавить в секцию components конфига и использовать глобально откуда угодно.

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

3. Абстракция и интерфейсы для нее

Теперь об абстракции. Для описания бизнес-логики мы используем методологию ООП, важнейшим принципом которой является абстракция. Бизнес-логика обязательно должна работать не с каким-то конкретным Order и Element, а с абстрактным (в качестве вакуума выступает Yii). Это сильно упростит всем разработчикам понимание, что делает эта самая логика.

Только приложение знает, какой конкретно заказ (с какими полями) создается в системе и что является элементом заказа. Где-то элементом будет продукт питания, а где-то целый автомобиль. Наш заказ будет работать в любом случае, в этом суть полиморфизма. Для бизнес-логики предметной области «заказ» важны лишь пара свойств, которые следует описать в интерфейсе. Создаем папку interfaces и кладем туда интерфейс корзины, элемента и заказа.

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

По умолчанию вместе с модулем поставляется и реализация данного интерфейса в виде AR модели Element. Но модуль ни в коем случае не навязывает именно ее, конечный пользователь может «подсунуть» другую модель через Di-container.

А вот как эта абстракция используется в бизнес-логике Filling:

Filling.php

cart = $cart; $this->element = $element; > public function execute() < foreach($this->cart->elements as $element) < $elementModel = $this->element; $elementModel = new $elementModel; $elementModel->setOrderId($this->order->id); $elementModel->setAssigment($this->order->is_assigment); $elementModel->setModelName($element->getModelName()); ///Еще куча вызовов set > //. > >

Бизнес-логика заявляет в конструкторе, что ждет на вход тип Cart и OrderElement. Магия Yii2 в своем внутреннем реестре ищет подходящий тип, имплементирующий интерфейс типа и передает его на вход. Сам Filling работает с абстракцией.

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

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

4. Инверсия зависимости

Самая популярная на сегодня реализация принципа IoC (Inversion of Control, инверсия управления) — Dependency Injection (внедрение зависимостей). Здесь все очень просто. Допустим, есть модули:

• Корзина;
• Заказ, зависящий от корзины.

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

Вернемся к Filling, который зависит от некоего типа Cart (класс реализации обязательно должен содержать методы getElements и truncate). Ключевое слово тут — «некий», а не «конкретный». Мы видим четкую зависимость конкретного «заказа» от некой «корзины». Только приложение знает, каким образом устроена в нем корзина — может, это отдельный модуль, а может быть нативная реализация. В любом случае, приложение должно каким-то образом «заинжектить» эту корзину в заказ, нужно связать интерфейс Cart с реализацией.

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

• Магазин;
• Заказ;
• Корзина.

yii::$container->set(‘pistol88orderinterfacesCart’, ‘appobjectsCart’);

yii::$container — тот самый контейнер, который существует в любом приложении Yii2 из коробки. Все очень просто, первым параметров передается интерфейс, вторым — реализация. Осталось только разобраться, в каком месте вставлять эту строку. Вариантов несколько:

• В index.php (точка входа) приложения
• В config.php перед return. Я рекомендую именно этот вариант.

Это пустой класс (так повезло), который просто указывает, что в качестве Cart в данной системе выступает pistol88cartCart, который четко имплементирует нужный «заказу» интерфейс. Изначальный Cart даже не знает, что он имплементирует что-то там в системе. Если бы нам не повезло и у Cart не было бы getElements, пришлось бы его реализовать в appobjectsCart. После того, как мы заинжектим зависимость, данный Cart магическим образом передается на конструтор Filling.

Еще раз обратим внимание на факт: модули yii2-cart и yii2-order никак не связаны друг с другом, никак не зависят друг от друга. Это значит, что модуль следует расшифровке одной из букв аббревиатуры SOLID (D, Принцип инверсии зависимостей), и это здорово. Значит, модуль достаточно универсален и может быть использован в любом инстансе Yii2. Было бы совсем круто, если бы модуль не зависел даже от фреймворка, но тогда придется отказаться от готовой админки в его составе, поставлять эту админку и все виджеты отдельным модулем, что красиво, но неудобною.

Очень важное замечание: такой способ внедрения зависимости подойдет только для очень крупных E-comerce проектов. Есть более простой и менее магический способ внедрения зависимости. При подключении модулякомпонента можно просто передать ему нужный класс в качестве свойства. Сложности с yii::$container нужны, по сути, только для того, чтобы сделать как можно более тонкими и простыми все слои (сервисный, моделей) за счет выделения еще одного слоя с зависимостями.

PS: как правильно заметили в комментариях, yii2-cart тоже должен следовать нужному интерфейсу, чтобы разработчик не вздумал его переписать и все сломать. Способ такой связи продумаю позже (если такое вообще возможно в Yii).

5. Управление изменчивостью

Под влиянием WordPress, я очень полюбил делать хуки вообще везде. Я считаю, именно благодаря хукам WordPress завоевал мир, хуки закрыли большинство возражений «а что если. », «а можно ли. ». Да, можно всё, если в месте, о котором идет речь, есть хук. Это просто идеальный способ быстро изменить поведение стороннего модуля или отдельного участка системы, не трогая код ядра.

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

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

• Десять разных ИМ, продающих автомобильные шины
• Все 10 ИМ используют один скелетон и одни модули

• У 5 из 10 ИМ используется нетипичное округление суммы заказа: где-то до 5 рублей в большую, где-то до 10 в меньшую

//.. use pistol88carteventsCart as CartEvent; //.. public function getCost($withTriggers = true) < //. $cartEvent = new CartEvent([‘cart’ =>$this->cart, ‘cost’ => $cost]); if($withTriggers) < $this->trigger(self::EVENT_CART_COST, $cartEvent); $this->trigger(self::EVENT_CART_ROUNDING, $cartEvent); > //..

А в конфиге приложения события триггера self::EVENT_CART_ROUNDING («cart_rounding») прослушиваются, происходит прием DataProvider и внесение изменчивости в эти данные:

‘cart’ => [ ‘class’ => ‘pistol88cartCart’, //.. ‘on cart_models_rounding’ => function($event) < $event->cost = ceil($event->cost/10)*10; > //’as RoundBehavior’ => . //Как альтернатива «on» с переносимым поведением ],

В getCost принимается уже измененный $cost из датапровайдера, обработанного коллбек функцией конфига:

$cartEvent = new CartEvent([‘cart’ => $this->cart, ‘cost’ => $cost]); if($withTriggers) < $this->trigger(self::EVENT_CART_COST, $cartEvent); $this->trigger(self::EVENT_CART_ROUNDING, $cartEvent); > $cost = $cartEvent->cost; $this->cost = $cost; return $this->cost;

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

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

6. СОЛИД

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

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

• Отсутствие дублирования кода. Важно писать код так, чтобы его куски не приходилось каждый раз переносить вручную и адаптировать под «здесь и сейчас», все должно быть по щелчку пальцев, одной настройкой и в одном месте.
• Легкая переносимость кода. Любой единожды написанный функционал должен быть инкапсулирован от системы. Тогда этот функционал можно взять и просто перенести куда угодно, не нужно тратить кучу времени на интеграцию и обрубание лишнего.
• Слабая связанность кода. Функциональные части системы должны быть слабо связаны между собой. «Мохнатые уши» не должны зависеть от конкретной кошки и ее головы. Если мы однажды описали уши, то они должны быть полиморфны, то есть применимы к любому животному, которое соответствует типу Animal.

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

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