Чистая архитектура - слишком много вариантов использования

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

В чистой архитектуре MVP существует слой между объектами (в хранилищах данных) и презентаторами, которые должны получить к ним доступ. Этот слой является «вариантом использования» . Вариант использования - это в идеале интерфейс, который реализует ОДНУ операцию на ОДНОЙ сущности.

Я также знаю, что «Чистая архитектура» « кричит », в смысле ее проекты действительно хорошо читаются, так как в них большое количество классов.

Теперь, в моем проекте, у меня есть что-то вроде 6 разных сущностей , и, конечно, у каждого хранилища сущностей есть по крайней мере 4 метода (обычно get, add, delete, update) для доступа к ним .. так, 6 * 4 = 24 .

Если то, что я до сих пор понимал в Чистой Архитектуре, у меня будет 24 UseCase.

Это много классов по сравнению с 6 контроллерами в MVC.

Я действительно должен сделать 24 случая использования?

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

Спасибо джек

— Джеки ДегльИнноченти
источник

Можете ли вы опубликовать ссылку на страницу, которая подробно описывает эти варианты использования, с примером кода?

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

Я много гуглил, но в основном: этот пример приложения и соответствующую статью: github.com/jshvarts/OfflineSampleApp ; это статьи: proandroiddev.com/… ; proandroiddev.com/… ; Обсуждение: youtube.com/watch?v=TvsOsgd0--c&feature=youtu.be ; И эта статья тоже: adityaladwa.wordpress.com/2016/10/25/…

— Джеки

Похоже, ни одно из приведенных вами примеров приложений или статей не имеет ничего общего с чистой архитектурой. Они, однако, много говорят о реактивном программировании.

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

Образец приложения, безусловно, создан с использованием парадигмы Clean Architecture. В основном это другие статьи. Что вы хотите увидеть @RobertHarvey?

— Джеки

Прочитайте мой ответ ниже и ответьте.

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

Ответы:

Я действительно должен сделать 24 случая использования?

Только если все, что вы пишете, является CRUD .

Обратитесь к диаграмме ниже:

Вы утверждаете, что у вас будет шесть разных сущностей и 4 метода (Create, Read, Update и Delete) для каждой сущности. Но это верно только для желтого круга в середине диаграммы (слой сущностей). Нет смысла создавать 24 метода в слое Use Cases, которые просто проходят через вызовы CRUD к слою Entities.

Вариант использования не «Добавить запись клиента». Вариант использования более похож на «Продать товар покупателю» (который включает сущности « Клиент», «Продукт» и «Инвентаризация») или «Распечатать счет» (который включает в себя те же сущности, в дополнение к заголовку счета и отдельным позициям счета- фактуры). ).

При создании вариантов использования вы должны думать о бизнес-транзакциях, а не о методах CRUD.

Дальнейшее чтение
Агрегат - кластер объектов домена, которые можно рассматривать как единое целое

— Роберт Харви
источник

Вы тратите слишком много времени на размышления о шаблонах, методах и архитектуре, а не на размышления о базовом дизайне программного обеспечения. Все, что вам нужно, это методы, которые воплощают деловую практику, как я описал в своем ответе.

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

Это не вопрос выбора архитектуры. Мое личное мнение: голые операции CRUD должны напрямую взаимодействовать с Entity Layer. Конечно, это, вероятно, нарушает Чистую Архитектуру.

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

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

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

Привет, Роберт, это не так приятно, что ты предполагаешь, что я не пишу код. Тема моего ответа - об архитектуре, а мы не о SO. С уважением, я нахожу ваши последние комментарии действительно вводящими в заблуждение и глухими. Вопрос о UseCase в Clean Arch., А не о написании кода. Если вы пытаетесь что-то сообщить, пожалуйста, объясните лучше, потому что я упускаю смысл ваших комментариев. ИМХО, невозможно избежать рассмотрения архитектуры при разработке программного обеспечения, или, по крайней мере, хорошие разработчики не просто пишут кучу кода. Более того, я задал действительно конкретный вопрос в своем комментарии, вы можете ответить? Спасибо

— Джеки

Решение поставленной вами проблемы (сначала приложение отключено) не имеет ничего общего с чистой архитектурой. Вы не найдете решения этой проблемы на диаграмме чистой архитектуры.

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

Вы правы, если каждая CRUD-операция переводится в один UseCase. Но UseCase также может состоять из нескольких CRUD-операций.

UseCase - это отдельная модель, собирающая информацию из разных источников данных и подготавливающая связь с приемниками данных. Может быть задействовано несколько CRUD-операций.

Так что подумайте о UseCase, где создается счет для клиента И также создается сам клиент, потому что он / она не существует в системе. У вас есть один UseCase, который приводит как минимум к двум Create-Operations в одной транзакции.

— oopexpert
источник

Так какой шаблон вы бы порекомендовали для примера CRUD со многими сущностями?

— Джеки

Мой личный взгляд на это таков: у меня нет проблем, когда у меня много классов, если они не нарушают SRP (принцип единой ответственности). Но я большую часть времени переопределил бы прецеденты «создать сущность», «обновить сущность», «удалить сущность» и «обновить сущность» до простой «управляющей сущности типа X». Часто вы предоставляете единый интерфейс для управления одним объектом. Но это именно то, что должен определить ваш UseCase: способ справиться с выгодной нагрузкой для вашего бизнеса.

— oopexpert

Итак, использование варианта использования, который управляет различными различными операциями, похоже, не нарушает SRP, так как кажется, что он просто «объединяет» больше разных методов (и потоков) в одном UseCase без того, чтобы какой-либо один поток обрабатывал более одной ответной реакции. ... но не так ли мы просто создаем контроллер вместо UseCase? ... идея ... Может быть, Вариант использования должен просто рассматриваться как уровень, и этот уровень должен просто уважать SRP, но также может реализовывать много методов. Я хотел бы иметь источник или статью об этом

— Джеки Degl'Innocenti

Usecase - это контроллер. Единственное отличие состоит в том, что сценарий использования исходит из бизнес-перспективы, а контроллер - это технический взгляд на него. Основное назначение - это то, что создает ценность для бизнеса. Таким образом, сценарий использования - это реализация контроллера, основанная на коммерческой ценности.

— oopexpert

Согласитесь, HTTP-контроллер - это способ управления вводом-выводом, также могут быть команды консоли, реакции на события и так далее. Все эти каналы ввода / вывода вызывают один и тот же сценарий использования. Вариант использования - это контроллер для бизнес-логики, он не знает о каналах ввода-вывода, из которых он был вызван, но он знает, как организовать доменные объекты для выполнения этой работы.

— Дмитрий Лежнев

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

— Buckstabue
источник

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

— Джеки