Что на самом деле означает «бизнес-логика», если не «весь сторонний код»?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Бизнес-логика обрабатывает такие вещи, как:

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

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

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

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