Що насправді означає "бізнес-логіка", якщо не "весь код третьої сторони"?

Я чув, як люди багато говорять про ділову логіку на роботі та в Інтернеті, і прочитав на цьому сайті кілька запитань, але цей термін все ще не має для мене великого сенсу. Наприклад, ось деякі (перефразовані) твердження, які я часто бачу:

• "Бізнес-логіка - це частина вашої програми, що кодує фактичні правила бізнесу." Більшість визначень, які я прочитав, є циркулярними.

• "Бізнес-логіка - це все, що є унікальним для вашої програми." Я не бачу, чим це відрізняється від "вашої конкретної програми - це не що інше, як бізнес-логіка", якщо ми випадково не винаходили купу коліс, для чого можна було б використовувати існуюче програмне забезпечення сторонніх виробників. Звідси і назва питання.

• "Шар бізнес-логіки повинен бути над рівнем доступу до даних та нижче вашого шару GUI." У коді, який я пишу, користувачі бази даних повинні знати, до яких даних вони мають отримати доступ, і код інтерфейсу повинен знати багато про те, що він відображає, щоб відобразити його правильно, і між цим насправді нічого робити ці два місця, крім передачі крапель даних між клієнтом та сервером. Отже, що насправді повинно перейти в бізнес-логічний шар?

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

Чи можливо, що я насправді перебуваю в команді, яка займається лише діловою логікою, а всю некомерційну логіку здійснюють інші команди? Або ціла концепція "бізнес-логіки" як окремої сутності є працездатною лише для певних програм або архітектури?

Щоб зробити конкретніші відповіді: Притворіться, що вам доведеться повторно застосувати додаток Піца Доміно. Що таке бізнес-логіка та яка неділова логіка цього додатка? І як можна було б цю логічну ділову логіку розмістити у власному "шарі" коду, без більшості інформації про піцу, що переливається у шари доступу до даних та презентації?

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

Я приймаю відповідь user61852, оскільки вона дала мені набагато конкретніше розуміння того, що "ділова логіка" робить і не стосується.

Я дам вам кілька порад щодо CRUD- програм, оскільки у мене немає великого досвіду в іграх або графічно інтенсивних додатках:

• Логіка бізнесу зазвичай передбачає правила, які власник бізнесу дізнався або вирішив за роки роботи, наприклад: "відхилити будь-який новий кредит, якщо клієнт ще не закінчив сплачувати останній" , або "ми не продаємо сніданок минулі 11 ранку " , або " понеділок та вівторок, клієнти можуть придбати дві піци за ціною однієї " .
• Звичайно, у шарі презентації повинно бути повідомлення про наявність знижки або про причину відхилення кредиту, але такий шар не вирішує ці речі, він лише повідомляє користувачеві щось, що сталося під кришкою.
• Логіка бізнесу зазвичай передбачає робочий процес , наприклад: "цей товар повинен бути затверджений керівником протягом 3 робочих днів або перейти до етапу" запит на інформацію ", якщо клієнт не подав необхідних документів, тоді товар відхиляється" .
• Шар презентації зазвичай не стосується такого типу робочого процесу, він лише відображає стани робочого процесу.
• Крім того, рівень доступу до даних, як правило, є простим, оскільки рішення вже приймаються за бізнес-логікою. Цей шар впливає, наприклад, коли ви вирішили перенести свої дані з MS SQL Server в Oracle
• Це правда, іноді GUI робить певну перевірку, щоб уникнути дзвінків на сервер, але це те, що слід робити розумно, або у вас може бути багато ділової логіки на цьому рівні.
• Багато вашої плутанини може виникнути з-за того, що у вашій заявці не існує роз'єднань, і фактично у вас є занадто багато ділової логіки в презентаційному шарі. Той факт, що у вас (помилково) є бізнес-логіка у вашому додатковому шарі чи шарі доступу до даних, не змінює факту, що це бізнес-логіка.
• Такі речі, як відображення відстаней у метричній системі замість миль / ярдів / футів - це не логіка презентації, це ділова логіка . Діловий рівень повинен повертати дані в необхідних одиницях і повідомити презентаційному шару, які одиниці він обробляє для того, щоб показати відповідні мітки, але це, безумовно, проблема бізнес-логіки.
• На бізнес-логіку не повинно впливати те, що ви зараз використовуєте Oracle замість Postgres, або те, що компанія змінила свій логотип або таблицю стилів.
• Правила бізнесу існують, незалежно від того, автоматизуєте ви це чи не написавши додаток. Їх можна застосувати навіть тоді, коли бізнес використовує низькотехнологічні рішення, як перо та папір.
• Якщо у вас є мобільна версія настільного додатка або веб-версія , кожна з цих версій має інший рівень презентації , але (сподіваємось) один і той же бізнес-рівень.

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

Можливість зміни формату передбачає деяку логіку бізнесу, що може спричинити збереження переваг.

Збереження формату до файлу cookie також може бути реалізовано в шарі перегляду.

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

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

Зробити здогадку про вашу заявку.

• Існує модель, що містить наявні облігації та дані про ціни на них.
• Існує вид, що дозволяє користувачеві бачити різні речі, які вони можуть зробити: пошук облігацій, показ цін, порівняння доходності, прийняття замовлень та відображає результати, повернуті бізнес-моделлю у відповідь на запит.

• Бізнес-логіка обробляє такі речі, як:

  • Здійснення пошуку та забезпечення відображення перегляду.
  • Пошук цін на облігацію та забезпечення відображення перегляду.
  • Порівнюючи дохідність та надаючи дані для перегляду для перегляду.
  • Обробка замовлень та зберігання їх у моделі.

Якщо це зроблено правильно, повинно бути можливість забезпечити кілька компонентів перегляду, не змінюючи модель або логіку бізнесу. Наприклад, якщо поточний дизайн - це веб-сайт, новий сервер перегляду для додатків iPhone або Android використовує існуючу модель та логіку бізнесу. Вони можуть запровадити нову функціональність бізнесу для надання push-сповіщень після виконання замовлення, що може зажадати змін на декількох шарах.

Ця розбивка дозволяє розділити проблеми.

• Рівень даних, представлений моделлю, як правило, є відносно стабільним.
• На бізнес-шарі застосовуються ділові рішення: чи / чи може бути виконаний запит? Чи отримано всі необхідні дані? Чи користувач авторизований? Чи є червоні прапори в угоді?
• Шар перегляду має тенденцію бути менш стійким, і їх може бути більше, ніж один. Тут знаходиться зовнішній вигляд програми. Можна повністю повторно зняти додаток, не змінюючи інших шарів.