Чи слід вводити логіку обчислення в об'єкті чи в бізнес-шарі?

Нещодавно у мене виникло питання про те, чи слід простий обчислення вводити в рівень Entity, чи Entity повинен бути чистим для простого зберігання необроблених даних і залишити логіку обчислень на рівні бізнесу.

Отже, моє питання полягає в тому, чи розумним є інкапсуляція простих обчислень у властивостях у сутність класу?

design-patterns

— Ката
джерело

Відповіді:

Це залежить від типу архітектури, який ви хочете.

У дизайні, керованому доменом, ви створили модель домену, яка б мала дані і функціональні можливості.

Це буде означати, що ан Orderмає властивість (або метод), яка б повернула загальну ціну замовлення на основі OrderLines. Також Orderбуде метод AddOrderItem(Product product, int amount)і Orderперевірить, чи існує вже OrderLineдля цього конкретного продукту.

У такій моделі у вас також будуть об'єкти, які не є реальними сутностями, наприклад, Repositoryдля доступу до даних або Factoryдля створення об'єктів. Вони називаються доменними службами. Рівень додатків відповідає за виклик служб домену (наприклад, для отримання об'єкта з бази даних), а потім він виконує функціональність сутності. Application LayerПовинна бути як можна тонше.

Це приємна стаття про DDD, яка детальніше пояснює ці поняття.

Ви також можете використовувати анемічну модель домену . Це означає, що ваші сутності складаються з властивостей get / set та не містять поведінки. У такому дизайні ваш бізнес-шар буде містити таку поведінку, як розрахунок Orderціни та перевірка наявності дубліката OrderLines.

Існують різні думки, чи анемічна модель домену - це погана річ. Особисто я віддаю перевагу реальній Доменній моделі.

У цій статті описані відмінності між анемічною та неанемічною моделлю доменів.

— Wouter de Kort
джерело

Привіт Wouter, дякую за відповідь та посилання. Я, мабуть, зіткнувся з помилковою думкою, що при використанні анемічної моделі домену всі бізнес-логіки (навіть самі прості) повинні бути розміщені в бізнес-шарі. Це здається безглуздим у деяких випадках, коли логіка бізнесу насправді залежить лише від самої моделі. Наприклад, властивість обчислюється з існуючих властивостей у моделі. Я не міг знайти розумної причини для розміщення бізнес-логіки, що все залежить від самої моделі в бізнес-рівень.

Як в анемічній моделі домену, як у нас є бізнес-класи, так і сутні класи, як правильно називати класи, щоб не плутати їх між собою? Чи пропонуєте ви використовувати суфікси? Якщо так, чи можете ви навести приклад?

— Квадз

Що стосується DDD, що робити, якщо логіка розрахунку ціни є складною? Наприклад, ціна залежить від місця розташування (податку), інформації про користувача (знижка при народженні, знижка на членство), купона, кредитної картки (спеціальна знижка на кредитну карту) тощо. Як ми можемо вкласти таку логіку всередині Orderкласу?

— Sher10ck

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

— бурзум

Анемічний ... поганий домен звучить так, ніби страждає від якоїсь хвороби. Ви б не хотіли, щоб вас водили ?! Ага!

— Метт Дженкінс

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

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

Одне важливе, що слід пам’ятати, це те, що суб’єкт господарювання завжди матиме особу, але суб’єкт господарювання є суб'єктом господарювання, який не має ідентифікації. Наприклад, продукт є організацією, але гроші не мали б посвідчення особи. 1000 різних примірників грошей були б однаковими.

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