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

Question

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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

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

Answer 4

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

Answer 5

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

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

Answer 6

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

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

Answer 7

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

Answer 8

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

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

<Ч>

@Lars, " услуги " подразумевает определенную архитектуру.