Юрий Солдаткин "Контроль зависимостей между элементами структуры приложения"

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

Transcript

1. Контроль зависимостей между элементами структуры приложения Юрий Солдаткин Архитектор
3. 3 / 27
4. Циклические зависимости 4 / 27
5. Последствия попустительства 1 2 3 Небольшие по смыслу правки приводят к необходимости перелопачивания всего проекта Код плохо тестируется Изменение даже в одном проекте влечет перекомпиляцию большой части решения
6. Что контролировать Связи между проектами Связи между пространствами имен *Степень связности компонентов Внешние зависимости *
7. Бизнес-задача
8. Domain-driven design 8 / 27
9. Многоуровневая архитектура Domain DAL Application
10. Обновленная схема проектов 10 / 27
11. Структура – не только проекты 11 / 27
12. Альтернатива? 12 / 27
13. Пространства имен 13 / 27
14. 14 / 27
15. Контракты 15 / 27
16. Как контролировать NDepend Visual Studio Enterprise Велосипед (Roslyn)
17. NDepend • Визуализация • CQLinq • *Степень связности внутри и между сборками/пространствами имен • *Внешние зависимости
18. 18 / 27
19. CQLinq 19 / 27
20. Visual Studio Enterprise • Низкий порог освоения • Лучшая интеграция в процесс • Ограниченные возможности • *Степень связности внутри и между сборками/пространствами имен
21. 21 / 27
22. Под капотом 22 / 27
23. 23 / 27
24. Сравнение NDepend VSE Roslyn Проверка при компиляции +/– + + Визуализация + + – Оценка степени связности + +/– + Контроль внешних зависимостей + +/– + Гибкость задания правил + – +
25. Когда контролировать При компиляции В тестах Локально По Merge Request в Git На CI
26. Наш опыт • Последовательное разделение большого legacy-приложения • Поддержка двумя независимыми командами • Контроль только новых проблем • Выделение контрактных сборок
27. Спасибо за внимание! Вопросы? Юрий Солдаткин Архитектор