Чиста перевірка архітектури в шарі збереження даних домену?

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

У мене все, що я все ще веду боротьбу, - це такі правила бізнесу, як "збереження оновлень для певного предмета, спочатку завантажуйте весь список елементів, на які я маю дозвіл на перегляд / редагування тощо." і що категорія предмета наразі не заблокована від використання, (та інших правил тощо тощо) ".. тому, що це (складне, але не атипове) правило бізнесу, і тому його слід обробляти в області додатків, а не нагнітати ділову логіку в шар db / стійкість.

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

Без передчасної оптимізації, який рекомендований підхід чи деякі статті дядька Боба, які займаються цим питанням? Або він би сказав "підтвердити домен, поки це не стане проблемою" ??

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

Оновлення:

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

Зокрема, я розглядаю архітектуру чистого стилю в контексті створення REST apis для клієнтів, а також функціонал внутрішнього використання, де багато правил бізнесу можуть бути набагато складнішими, ніж в основному кожен приклад, який ви бачите в мережі (навіть самі хлопці з архітектури Clean / Hex).

Тож я думаю, я насправді запитував (і не зміг чітко заявити) про те, як Clean і REST api будуть сидіти разом, де більшість MVC-матеріалів, які ви бачите в ці дні, мають валідатори вхідних запитів (наприклад, бібліотека FluentValidation в .NET), але де багато хто з мої правила "валідації" не так сильно "це рядка менше 50 символів", але більше ", чи може цей користувач, що викликає цей користувальницький шафа / інтерактор, виконувати цю операцію над цим зібранням даних, враховуючи, що якийсь пов'язаний об'єкт зараз заблокований Team X до пізніше місяця і т. д. "... такі типи глибоко задіяних перевірок, де застосовуються ЛОТИ об'єктів бізнес-домену та правил домену.

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

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

Але я здогадуюсь, що коротка відповідь на моє запитання схожа на відповідь, яку я прийняв: "Це ніколи нелегко, і це залежить".

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

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

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

• Деякі форми перевірки є неявними через обмеження введення; наприклад, текстове поле може дозволяти лише числовий запис. Це означає, що у вас може бути "чисельне число"? валідатор на сторінці, але вам все одно знадобиться його на зворотному кінці десь, оскільки обмеження інтерфейсу можуть бути обійдені (наприклад, відключення Javascript).

• Шар інтерфейсу повинен виконувати деякі форми перевірки по периметру послуги (наприклад, код на стороні сервера у веб-додатку), щоб захистити систему від атак ін'єкцій чи інших зловмисних форм введення даних. Іноді ця перевірка відсутня навіть у вашій кодовій базі, наприклад, перевірка запиту ASP.NET .

• Шар інтерфейсу повинен виконувати деякі форми перевірки лише для перетворення введених користувачем даних у формат, який бізнес-рівень може зрозуміти; наприклад, він повинен перетворити рядок "6/26/2017" в об'єкт DateTime у відповідному часовому поясі.

• Бізнес-шар повинен здійснювати більшість форм перевірки, тому що, теоретично, вони належать до бізнес-шару.

• Деякі форми перевірки є більш ефективними на рівні бази даних, особливо коли потрібні референтні перевірки цілісності (наприклад, щоб переконатися, що код стану знаходиться у списку 50 дійсних станів).

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

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

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

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

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

Перевірка є частиною бізнес-шару.

Справа в тому: бізнес-логіка в DAO призведе до недійсності концепції DAO. Перевірка будь-якого вищого шару призведе до надмірної перевірки, якщо ви викликаєте бізнес-операції з іншого використання.

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

Ви можете перевірити свою точку зору щодо того, хто робить, що стосується валідації. Це БД, де ви знаєте, що працюєте з БД? Або це послуга (яка, можливо, підтримується та контролюється операціями БД). У моєму проекті кожен агрегатний корінь має список груп, які можуть його читати, та список модифікаторів. Коли код шукає конкретний корінь або список коренів, який може бачити користувач, усі деталі приховані за службою, яка бере ідентифікатор користувача та додаткові частини контексту пошуку, наприклад, де плитка починається з "blah". Коду не важливо, чи БД виконує перевірку існування, щоб перевірити, чи існують групи користувачів у групах читачів. Він просто очікує, що список із вмістом або без нього базується на тому, що коли-небудь надає послуга, визначена лише договором.

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

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