Что именно состоит из «бизнес-логики» в приложении?

Question

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

Может кто-нибудь сказать мне, что именно состоит из бизнес-логики? Как это можно отличить от другого кода? Есть ли какой-нибудь простой тест для определения, что такое бизнес-логика, а что нет?

Answer 1

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

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

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

Answer 2

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

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

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

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

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

Answer 3

Я думаю, вы путаете бизнес-логику с требованиями вашего приложения. Это не одно и то же. Когда кто-то объясняет логику своего бизнеса, это что-то вроде:

«Когда пользователь покупает товар, он должен предоставить информацию о доставке. Информация подтверждается правилами xyz. После этого он получит счет и заработает баллы, что дает x% скидок для предложений y» плохой пример)

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

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

Answer 4

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

Answer 5

Мне не нравятся названия слоев BLL + DAL, они более запутанные, чем уточняющие.
Назовите это DataServices и DataPersistence. Это облегчит.

Службы манипулирования CRUD-файлами уровня сохраняемости (создание, чтение, обновление, удаление)

Answer 6

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

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

---

@ Ларс, «сервисы» подразумевают определенную архитектуру.

Answer 7

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

Answer 8

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

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