Документ рассматривает важность проектирования архитектуры программного обеспечения, включая деление на компоненты для уменьшения взаимозависимости и повышения тестируемости кода. Обсуждаются паттерны проектирования, такие как facade и strategy, а также архитектурные принципы, такие как инверсия управления. Кроме того, подчеркивается необходимость подготовки приложения к будущим изменениям и важность continuous improvement в архитектуре.

1. Nuradil Alymkulov. MadDevs. November 12, 2020
Software Architecture 101
Как строить приложения

2. О себе
Нурадил Алымкулов
nuradil@maddevs.io
• Senior Backend Developer
/ Principal Architect at
MadDevs
• 5+ лет опыта разработки

3. Зачем нам готовить
архитектуру приложения?

4. Зачем нам готовить архитектуру?
Вопросы, на которые надо ответить
• На какие основные компоненты (модули) можно поделить приложение?
• Как поделить ответственность между компонентами?
• Как подготовить приложение к будущим изменениям?
• Сколько будет стоить разработка?

5. На какие основные компоненты
(модули) можно и нужно
поделить приложение?

6. Приложение
Зачем делить?
• уменьшить взаимозависимость частей кода, чтобы в будущем можно было
гарантировать надежность кода
• обеспечить тестируемость кода (для юнит-тестов)
• четко разграничить область ответственности каждого компонента
• выявить часто используемые компоненты и сделать их общими (с помощью
полиморфизма, в частности)
• Определить какой паттерн можно применить (какую абстракцию
использовать)

7. Диаграмма
последовательностей

8. Диаграмма
последовательностей
(оптимизированная)

9. Компонентная
диаграмма

10. Как поделить ответственность
между компонентами?

11. Facade
Это структурный паттерн
проектированиям , который
предоставляет простой
интерфейс к сложной системе
компонентов (классов, библиотек
и т.д.)

12. Strategy
Это поведенческий паттерн
проектирования, который
определяет семейство схожих
алгоритмов и помещает каждый
из них в собственный класс,
после чего алгоритмы можно
взаимозаменять прямо во время
исполнения программы.

13. Inversion of Control
Это архитектурный принцип, при
котором поток управления
программы контролируется
фреймворком, а кастомный код
встраивается в определённые
точки выполнения.
Примеры
• React
• Java Spring Framework
• Microsoft ASP.Net

14. Как подготовить приложение к
будущим изменениям?

15. Сколько будет стоить
разработка?

16. Кто должен этим заниматься?

17. Оптимизация
с помощью
блок-схем

18. После рисования всё
кончается?

19. Конечно

20. Же

21. Нет.

22. Архитектура приложения - живой
организм и в наших силах
поддерживать её

23. Спасибо за внимание! 😊

24. fin.