У DDD чи є логіка програми перевірки чи логіка домену?

Припустимо, ми моделюємо форму за допомогою DDD; Форма може мати певні правила ведення бізнесу, пов’язані з нею - можливо, вам потрібно буде вказати дохід, якщо ви не студент, і вам потрібно вказати своїх дітей, якщо ви вкажете, що ви одружені. І якщо ви вказали країну, то вона повинна мати дійсну країну.

Чи існує такий вид перевірки в домені чи шарі додатків? Деякі інші питання, які я розглядав:

• Окремі рамки, такі як Laravel, містять правила перевірки, які можуть перевірити вхід, перш ніж запит потрапить на контролер. Чи порушує він DDD, якщо перевірка проводиться на цьому рівні?

• У таких випадках, як визначення, чи є країна дійсною, зазвичай я просто запитую таблицю баз даних усіх країн світу. Однак у DDD це, швидше за все, (з мого розуміння) буде зроблено на доменному шарі. Чи дозволено доменний рівень доступу до БД, чи потрібно використовувати пошук, який не є SQL, щоб визначити дійсну країну?

• Чи потрібно перевірити введення як на рівні програми, так і на рівні домену?

Чи існує такий вид перевірки в домені чи шарі додатків?

Застосування. Чарівний пошуковий термін - антикорупційний шар

Зазвичай повідомлення, отримане вашою заявкою, матиме певний аромат DTO. Ваш антикорупційний рівень зазвичай створюватиме типи значень, які домен розпізнає. Фактична команда, що надсилається до доменної моделі, буде виражена через валідовані типи значень.

Приклад: команда DepositMoney, ймовірно, включає суму та тип валюти. Представлення DTO, ймовірно, виражає суму як ціле число, а код валюти - як рядок. Антикорупційний рівень перетворив би DTO у тип вартості депозиту, який би включав підтверджену суму (яка не повинна бути негативною) та перевірену валюту коду (який повинен бути одним із підтримуваних кодів у домені).

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

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

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

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

Це не означає, що, коли ваш домен взаємодіє з людьми (через екрани, форми тощо), не повинно бути перевірки чи допомоги. Просто зрозумійте, що це необов’язково.

Врахуйте, що існує два типи бізнес-правил: - правила власності, що обмежують атрибути об'єкта, і правила співпраці, які обмежують додавання та усунення співпраці між об'єктами.

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

Примітка: в DDD немає концепції "моделювання" вашої форми.

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

Але є невелика проблема: перевірка моделі часто відбувається занадто пізно. Часто ми хочемо зробити перевірку завчасно, тому користувачеві не потрібно чекати занадто довго. Ось чому перевірку часто вкладають у логіку програми.

Що стосується контексту перевірки: Існує не проблема, коли організація може запитувати додаткові дані. Але це не має значення, звідки беруться ці дані. Не байдуже, чи він походить з SQL, File або просто жорстко закодований. Саме тому сховища існують. Домен визначає, який саме запит йому потрібен, і дозволяє іншому подбати про реалізацію.

Доменний рівень повинен містити всю логіку перевірки. Презентація, антикорупційні шари або інші залежні шари повинні це відображати.