Я занимаюсь веб-разработкой с 2009 года, когда начал работать с PHP. Когда я перешел на ASP.NET, я много слышал о DDD и OOAD, где большое внимание уделяется этой «бизнес-логике» и «бизнес-правилам». Дело в том, что все приложения, которые я разрабатывал до сих пор, были посвящены операциям CRUD, и я никогда не видел этих вещей на практике.

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

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

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

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

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

Теперь давайте поработаем с некоторыми примерами.

Перевод денег с одного текущего счета на другой

Во-первых, что нужно знать (вход)?

• Личность лица, осуществляющего перевод
• Сумма денег для перевода
• Исходный номер текущего счета
• Номер целевого текущего счета

Каковы некоторые из «бизнес-правил», которые должны применяться?

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

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

Заказывая что-то из Amazon.

Что вы должны знать?

• Личность человека, заказывающего
• Информация о доставке
• Платежная информация
• Метод оплаты
• Количество и количество каждого предмета для отправки
• Как отправить (быстро, медленно или супер спасатель)
• Ставка государственного налога

Что происходит после размещения заказа?

• Предметы вытягиваются со склада
• На руках количество списывается
• Товары упакованы для отправки
• Нет в наличии товары возвращены
• Товары, которые опускаются ниже минимального количества, заказываются
• Один груз или два?

• Счет-фактура / список доставки распечатывается и размещается вместе с заказом.

  ..и т.д.

CRUD - это просто создание, чтение, обновление, удаление приложения.

В определенной степени, трекер ошибок также является приложением CRUD. Создавайте ошибки, читайте (отображайте) ошибки, обновляйте ошибки и, возможно, удаляйте их.

Однако, трекер ошибок - это больше, чем просто CRUD.

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

Код, который реализует вышеизложенное, является бизнес-логикой приложения.

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

Конечно, можно написать «чистое» CRUD-приложение, в котором нет ролей, все можно изменить и просмотреть - но это скорее исключение, чем правило.

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

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

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

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

Это некоторые бизнес-правила. Они не разговаривают с CRUD-частью приложения.

При работе с бизнес-правилами вы можете часто находить их написанными в механизме правил (например, Windows Workflow Foundation Rules Engine ) вместо написания необработанного кода в вашей системе.

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

Другие ответы верны. Еще одна мысль ...

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

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

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

Бизнес-логика в основном состоит из 2 широких категорий: проверка и обработка. Бизнес-логика говорит, что кол-во 1 должно быть больше или равно кол-ву 2 - например, количество покупаемых товаров должно быть меньше или равно количеству товаров на складе.

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

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

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

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