Чистая архитектура

1. Чистая
архитектура

2. Артур Бадретдинов
Старший разработчик мобильных приложений, АБЦТ
Google Developers Group Kazan lead
Люблю развиваться и помогать другим
Telegram: @gaketo
2
Привет!

3. Почему я?
◉ Увлечён вопросами качества кода, проблемами дизайна
и архитектуры
◉ Обладаю теоретической подготовкой
(курс Архитектуры, магистратура Иннополиса)
◉ Один из администраторов Telegram-канала
“Android Architecture” (>1200 участников)
◉ Использовал подход ранее и применяю в текущем
проекте, BankOk
3

4. О чём речь?
4
◉ Clean Architecture набирает популярность
◉ Чистая архитектура
◉ Ответственности слоёв
◉ В двух словах - о слое презентации

5. Подготовка
5
“Для подготовки доклада,
хочу узнать известность
подхода.
Пожалуйста, ответьте, кто
вы, и знакомы ли с Чистой
архитектурой от Дядюшки
Боба.”
Telegram-чаты
Java и Android, 208 человек
Android dev, использовал/использую – 61
29%
Backend dev, даже не слышал – 58
28%
Android dev, слышал – 41
20%
Backend-dev, использовал/использую (в т.ч. в
pet-проектах) – 21
10%
Backend dev, слышал что-то... – 16
8%
Android dev, не слышал – 11
5%

6. Архитектура
Немного теории
1
6

7. Чистая
архитектура
7

8. Типичный
вызов
8

9. Как понять, какой должна быть
архитектура?
◉ Требования бизнеса
◉ Проблемы команды
9

10. Проблемы
За что бьёмся-то?
2
10

11. God object
line 20: public class TransferActivity extends Activity {
line 22: // Много всего интересного:
line 30: // создание вьюх
line 146: // отображение диалогов
line 290: // где-то тут лезем в базу
line 666: // асинхронно получаем ответ от сервера
line 1331: // сложный код, который не позволяет крутилке
// крутиться когда она не должна
line 1444: // конец класса
line 1445: }
11

12. Конфликты
12

13. Everything is connected to
everything
Говорят, так работает женский мозг*
*https://www.youtube.com/watch?v=0BxckAMaTDc 13

14. Решение - Разделение ответственности
14

15. Решение - Layered pattern
* Та же схема, что на предыдущем слайде, но абстрактнее
** Обратите внимание, что данные - не снизу
15

16. Тестирование
27 000 jUnit тестов за 10 секунд
2 часа260 инструментальных тестов за...
то есть, на компьютере
то есть, на устройстве
Компания Juno (“Добрый Uber”).
Crash-free rate: 99,99%
16

17. Возможность изменить реализацию
17
Чаты
Друзья и чаты

18. Решение -
Независимость
от фреймворков
18

19. Что происходит в этом проекте?
19
По слоям По функционалу

20. Решение:
пакеты по функоналу, а не слоям
◉ “Кричащая архитектура”
◉ Проще навигация
◉ Минимизация области видимости
◉ БанкОк: команды по специализации =>
команды по фичам
20

21. Итог:
характеристики системы
◉ Тестируема
◉ Независима от базы данных
◉ Независима от фреймворков
◉ Независима от пользовательского
интерфейса
Подробнее в книге: Architecting software intensive systems: a practitioner's guide, Lattanze, 2009
21

22. Ответственность
Кто виноват и что делать?
3
22

23. Оригинальная диаграмма
◉ Ближе к центру -
правила
◉ Ближе к краю -
механизмы
23

24. Слой фреймворков
◉ Сильная зависимость от платформы
◉ Содержат минимум логики
○ Работа с фреймворком (Android, etc)
○ Строки, разрешения, тосты...
○ Ввод/вывод данных (экран, тач скрин)
○ Базы данных, работа с сетью
24

25. Фреймворки
25
public class AlertActivity extends Activity implements AlertView {
private TextView messageView;
private AlertPresenter presenter;
…
@Override
public void onRefresh() {
presenter.onRefreshAction();
}
@Override
public void showThereAreNoAlerts() {
messageView.setText(R.string.alert_msg_everything_is_ok);
}
...
}

26. Фреймворки
26
public class LocalStorage {
// Здесь может быть и Context, если это необходимо
private SharedPreferences prefs;
public String getToken(){
return prefs.getString(KEY_TOKEN, "");
}
public void setToken(String token){
prefs.edit().putString(KEY_TOKEN, token).apply();
}
…
}

27. Слой адаптеров
◉ Controllers, Presenters, Repositories
◉ Взаимодействуют с бизнес логикой
◉ Чистая архитектура не регламентирует
реализацию
27

28. Слой адаптеров
28
public class AlertPresenter {
@Inject EarthquakesInteractor earthquakesInteractor;
@Inject LocationInteractor locationInteractor;
private AlertView alertView;
locationInteractor.getCurrentCoordinates()
.subscribe(earthquakeWithDists -> {
if (earthquakeWithDists.isEmpty()) {
alertView.showThereAreNoAlerts();
} else {
alertViewshowEartquakeAlert(earthquakeWithDists.get(0));
});
…

29. Слой адаптеров
29
public interface EarthquakesRepository {
Observable<List<Earthquake>> getTodaysEarthquakes();
Observable<EarthquakeInfo> getEartquakeInfo(long id);
}

30. Слой бизнес логики
◉ Независим от источников данных
◉ Независим от приёмников данных
◉ Независим от фреймворков
30

31. ◉ Бизнес логика уровня приложения
(application-level)
◉ Оперируют сущностями, предоставляя им
данные и получая ответы
◉ Получают и отправляют “чистые” данные
◉ Общаются с окружающим миром через
интерфейсы
Use cases (Interactors)
31

32. UseCase (1992 год)
Действующее лицо: неавторизованный пользователь
Позитивный сценарий:
1. Пользователь открывает приложение
2. Система отображает пользователю процесс загрузки
3. Система скрывает отображение загрузки и отображает
пользователю информацию о ближайшем землетрясении
Альтернативные случаи:
3а1. Система отображает пользователю информацию об
отсутствии землетресений.
3а2. Система отображает пользователю возможность
перехода к списку всех зарегистрированных землетрясений.
32

33. Use cases (Interactors)
public interface UseCase {
// This is the main method that starts an interactor.
void execute();
}
public interface GetEarthquakesUseCase extends UseCase {
void setLocation(Location location);
interface Callback {
void onBalanceUpdated();
}
}
33

34. Interactors
public class EarthquakesInteractor {
private EarthquakesRepository repository;
public Observable<List<EarthquakeWithDist>> getEartquakesSorted(Loc loc) {
//...
}
public Observable<List<EarthquakeWithDist>> getEartquakes() {
//...
}
public Observable<ServerResponse> publishEarthquake(Earthquake quake) {
//...
}
…
}
34

35. Interactors
public class EarthquakesInteractor {
private EarthquakesRepository repository;
public Observable<List<EarthquakeWithDist>> getEartquakesSorted(Loc loc) {
return repository.getTodaysEarthquakes()
.flatMapIterable(earthquakes -> earthquakes)
.map(earthquake -> new EarthquakeWithDist(earthquake, coords))
.sorted((a, b) -> Double.compare(a.getDistance(), b.getDistance()))
.toList()
.toObservable();
}
…
}
35

36. Entities (Сущности)
◉ Бизнес логика уровня всей системы
(enterprise-level)
◉ Бизнес модели
36

37. Entities (Сущности)
public class Earthquake {
private String title;
private Double magnitude;
private Date time;
private AlertLevel alertLevel;
private Location location;
private String url;
...
}
37

38. Поток управления
38

39. Поток управления
39

40. Типичный
Вызов.
MVP + Clean
40
Компоненты
бизнес логики

41. Типичный вызов
41
swipeRefreshLayout.onRefresh() ➞
earthquakesActivity.onRefresh() ➞
earthquakesPresenter.onRefreshAction() ➞
earthquakesInteractor.getEarthquakes()➞
earthquakesRepository.getTodaysEarthquakes()➞
earthquakesApiService.getTodaysEarthquakes()⇒
eartquakesMapper.map()⇒
earthquakesInteractor.onResponse()⇒
earthquakesPresenter.onResponse()➞
earthquakesView.showEarthquakes()
➞ - прямой вызов (первый элемент вызывает второй)
⇒ - callback
Уровень
презентации
Уровень
презентации

42. Передача данных между слоями
◉ Простые модели (DTO, параметры функции,
hashmap...)
◉ Крайний вариант - различные модели на
различных уровнях
◉ Внешние слои выполняют преобразования
для внутренних
◉ Альтернатива - использование бизнес
моделей (Entity) там, где их полей достаточно
42

43. Слой
презентации
А с ним-то что?
4
43

44. Как структурировать UI?
Слой
данных
Слой
Представления
44

45. MV…Whatever
Используйте любой паттерн, который вам
ближе
45

46. MVP
Interactor и всё, что за ним.
Логика и данные
46

47. Минусы подхода
А как без них?
5
47

48. Проблемы
◉ “Противостояние” с фреймворками
◉ Множество интерфейсов
◉ ~50 классов на 2 экрана =)
◉ Каждому слою - по модели?
◉ Мапперы, мапперы, мапперы*
*mapstruct.org - для Java
48

49. Итого
◉ Тестируемость бизнес логики и логики отображения
◉ Возможность написания логики по TDD/BDD
◉ Возможность параллелизации разработки -
мобильный “бэк” и “фронт” - логика и UI
◉ UI и DB / network - заменяемые плагины
49
◉ Больше кода
◉ Кривая обучения
◉ Трудности, связанные с фреймворком

50. Когда не стоит использовать?
◉ Ваше первое приложение под андроид
◉ “Одноразовое” приложение (будет использоваться
только на одном событии)
◉ Маленькое приложение:
○ 1-2 разработчика
○ 6-12 месяцев - срок жизни
50

51. Ссылки
◉ Исходный подход:
https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-arc
hitecture.html ,
https://www.youtube.com/watch?v=Nltqi7ODZTM&t=458s
◉ Адаптация под Андроид:
https://fernandocejas.com/2014/09/03/architecting-android-th
e-clean-way/
◉ Дополнительно про MVP и паттерны презентации:
https://youtu.be/6Aj_uUZUo44?t=2037
◉ Репозиторий с примером:
https://github.com/Gaket/Earthquakes/
51

52. Спасибо за помощь
◉ Евгению Мацюку - ведущему разработчику Лаборатории
Касперского, идеологу чата “Android Architecture”
◉ Василию Артемьеву - учителю, консультанту по архитектуре
и Software Engineering практикам в целом
◉ Булату Габбасову - архитектору, за помощь в подготовке
◉ Администраторам и сообществу чата “Android Architecture”
https://t.me/Android_Architecture
◉ SlidesCarnival за шаблон презентации
52

53. Есть вопросы ?
Для связи:
◉ @gaketo - Telegram
◉ artursletter@gmail.com
Спасибо за
внимание!
53

54. Дополнительно
А вдруг останется время? :)
∞
54

55. Что такое архитектура?
◉ Мы пишем на Java
◉ Мы юзаем RxJava, реактивщина рулит
◉ Spring - всему голова
◉ MVC
◉ MVP
◉ Архитектура - это сборник правил
(Ответ - не совсем, или даже совсем не)
55

56. “
Программная архитектура системы
- это множество структур,
необходимых для обоснования
решений в проектировании системы,
которое содержит программные
элементы, отношения между ними и
свойства обоих.
(Лен Басс и др., 2002)
Книга: Architecting software intensive systems: a practitioner's guide, Lattanze, 2009
Статья: https://www.ibm.com/developerworks/ru/library/eeles/
56

57. “
The software architecture of a
system is the set of structures
needed to reason about the
system, which comprise software
elements, relations among them,
and properties of both.
(Len Bass et al., 2002)
57

58. Какой должна быть архитектура?
◉ Масштабируемой
◉ Тестируемой
◉ Изменяемой
◉ Производительной
◉ Устойчивой
◉ Чистой
Верно, но не всё и сразу
58

59. Как объять необъятное?
Архитектурные драйверы:
◉ Функциональные требования
◉ Нефункциональные требования
◉ Ограничения бизнеса
◉ Технические ограничения
Книга: Architecting software intensive systems: a practitioner's guide, Lattanze, 2009
59

60. ◉ Схемы
○ Динамическая
○ Статическая
○ Физическая
◉ Текстовые описания
Документирование архитектуры
Книга: Documenting Software Architectures: Views and Beyond, Clements, 2010
60

61. VIPER
VIPER = Clean Architecture
+ MVP
+ Navigator (Router)
61

62. MVC
62

63. MVVM
63