Я працюю з веб-розробкою з 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 Engine ), а не писати необроблений код у вашій системі.

Зрозумійте, що логіка / правила розмежування є однією з термінологій і про це можна сперечатися всю ніч (найкраще знову за пивом). Хоча це не рідкість розрізнення, хоча вони можуть поєднуватися один з одним.

Інші відповіді правильні. Ще одна думка ...

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

Якщо ви повторно реалізовували проект програмного забезпечення іншою мовою програмування, скажімо, перехід від Turbo Pascal до Java , бізнес-логіка та бізнес-правила - це те, що матиме спільний старий та новий проекти .

Мова програмування була б іншою. Вихідний код буде зовсім іншим. Інструменти ( IDE , компілятори тощо ) можуть бути абсолютно різними. Інтерфейс користувача може бути повністю реорганізовано або мати інший вигляд і відчуття . Документація , ймовірно , буде відрізнятися. Але мета двох проектів, кінцеві результати виконаної роботи / досягнуті цілі, були б однаковими.

Логіка бізнесу в основному складається з 2-х широких категорій: перевірка та потік. Бізнес-логіка говорить, що кількість 1 повинна бути більшою або дорівнює кількості 2 - наприклад, кількість предметів для придбання повинна бути меншою або рівній кількості товарів на складі.

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

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

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

"Бізнес-логіка" програми чи програми - це частина коду, яка насправді робить вхід (від користувача, операційної системи тощо). "Правила бізнесу" програми - це зазвичай визначені параметри самої програми (наприклад, як обробляти введення даних). Принаймні, саме так я чув про це, про який згадували багато людей. Вони є досить схожими термінами для опису частин коду.