Чиста архітектура - Занадто багато класів використання

Я заходжу в чисту архітектуру і піднімаю рівень Android з MVC на MVP , представляю DI з Dagger 2, Reactivity з RxJava 2 і звичайно Java 8.

У чистій архітектурі MVP існує шар між сутностями (у сховищах даних) та презентаторами, які мають отримати доступ до них. Цей шар є "Справою використання" . Випадок використання - це в ідеалі інтерфейс, який реалізує ОДНУ операцію над ОДНОЮ сутністю.

Я також знаю, що Clear Architecture " кричить ", в сенсі її проекти справді легко читаються, оскільки велика кількість класів в них.

Тепер у своєму проекті я маю щось на зразок 6 різних сутностей , і звичайно, кожне сховище сутності має принаймні 4 способи (зазвичай отримують, додають, видаляють, оновлюють) для доступу до них .. так, 6 * 4 = 24 .

Якщо я зрозумів чисту архітектуру, я отримаю 24 UseCase.

Це багато класів, якщо порівняти лише 6 контролерів у MVC.

Чи справді я повинен зробити 24 випадки використання?

Я дуже буду вдячний за уточнення того, хто вже використовував його з успіхом.

Дякую, Джеку

— Джекі Дегл'Інокенті
джерело

Чи можете ви розмістити посилання на сторінку, яка детально описує ці випадки використання, з прикладом коду?

— Роберт Харві

Я дуже багато в Google, але в основному: цей зразок програми та відповідна стаття: github.com/jshvarts/OfflineSampleApp ; це статті: proandroiddev.com/… ; proandroiddev.com/… ; Ця розмова: youtube.com/watch?v=TvsOsgd0--c&feature=youtu.be ; І ця стаття теж: adityaladwa.wordpress.com/2016/10/25/…

— Jackie Degl'Innocenti

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

— Роберт Харві

Зразок програми, безумовно, зроблений з парадигмою Clean Architecture .. Інші статті в основному .. Що ви хочете бачити @RobertHarvey?

— Jackie Degl'Innocenti

Прочитайте мою відповідь нижче та відповідь.

— Роберт Харві

Відповіді:

Чи справді я повинен зробити 24 випадки використання?

Тільки якщо все, що ви пишете, це CRUD .

Дивіться схему нижче:

Ваше твердження полягає в тому, що у вас буде шість різних об'єктів і 4 способи (Створення, читання, оновлення та видалення) для кожної сутності. Але це справедливо лише в жовтому колі посередині діаграми (шар Entities). Створювати 24 способи в шарі Use Cases, які просто проходять через виклики CRUD до рівня Entities, безглуздо.

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

Створюючи випадки використання, ви повинні думати про бізнес-операції, а не про методи CRUD.

Подальше читання
Агрегат - це кластер об’єктів домену, який можна розглядати як єдине ціле

— Роберт Харві
джерело

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

— Роберт Харві

Це не питання вибору архітектури. Моя особиста думка: голі операції CRUD повинні безпосередньо спілкуватися з рівнем сутності. Звичайно, це, ймовірно, порушує чисту архітектуру.

— Роберт Харві

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

— Роберт Харві

Гей, Робер, не так приємно, що ти вважаєш, що я не пишу код. Тема моєї відповіді - це архітектура, а ми не на SO. Щиро вважаю ваші останні коментарі дійсно оманливими та глухими. Питання стосується UseCase в Clean Arch., А не написання коду. Якщо ви намагаєтесь щось повідомити, поясніть краще, тому що я пропускаю точку ваших коментарів. IMHO неможливо уникнути розгляду архітектури під час розробки програмного забезпечення, або, принаймні, хороші розробники не просто записують купу коду. Більше того, я поставив у коментарі дійсно конкретне запитання, чи можете ви відповісти? Спасибі

— Джекі Дегл'Інокенті

Рішення проблеми, яку ви поставили (додаток спочатку офлайн) насправді не має великого стосунку до чистої архітектури. Ви не знайдете рішення цієї проблеми на діаграмі «Чиста архітектура».

— Роберт Харві

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

UseCase - це відокремлена модель, яка збирає інформацію з різних джерел даних і готує зв'язок з потоками даних. Може бути задіяно кілька операцій з CRUD.

Тому подумайте про UseCase, де створюється рахунок для клієнта І створюється також сам клієнт, оскільки він / вона не існує в системі. У вас є один UseCase, який призводить до щонайменше двох створених операцій за одну транзакцію.

— oopexpert
джерело

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

— Джекі Дегл'Інокенті

Моя особиста думка з цього приводу така: у мене немає проблеми проводити багато занять, якщо вони не порушують СРП (єдиний принцип відповідальності). Але я б більшу частину часу переосмислював Usecases "створити сутність", "оновити об'єкт", "видалити об'єкт" та "оновити сутність" до простого "керувати об'єктом типу X". Часто ви надаєте єдиний інтерфейс користувача для управління одним об'єктом. Але саме це має визначати ваш UseCase: спосіб вирішення корисного навантаження для вашого бізнесу.

— oopexpert

Гаразд, так, наявність Case Case, що управляє різними різними операціями, схоже, не порушує SRP, оскільки, здається, просто "агрегує" більше різних методів (і потоків) в одному UseCase, без цього жоден потік обробляє більше, ніж одну відповідальність. .. але таким чином, чи не просто ми створимо контролер замість UseCase? .. ідея .. Можливо, Служба використання повинна просто розглядатися як шар, і цей шар просто повинен поважати SRP, але також може реалізувати багато методів. Я хотів би мати джерело чи статтю про це

— Джекі Дегл'Інокенті

Usecase IS Контролер. Єдина відмінність полягає в тому, що на користь справи йде бізнес-позиція, а контролер - це технічний погляд на неї. Основна увага в користуванні - те, що генерує ділову цінність. Таким чином, випадок використання - це реалізація контролера, орієнтована на цінність бізнесу.

— oopexpert

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

— Дмитро Лежнєв

Ваше визначення Use Case неправильне, Use Case - клас, що реалізує правило бізнесу, це не потрібно, щоб це було операцією CRUD, це може бути складна багатоступенева операція

— Бакстабу
джерело

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

— Jackie Degl'Innocenti