2. - Явность
- Поддерживаемость
- Расширяемость
- Безопасность
- Стабильность
- Предсказуемость
- Масштабируемость
- Тестируемость
Требования к коду
3. от к
Основные проблемы
- сильная связанность кода
- неявность кода
- сложно тестировать медленные тесты
-
- хуки в коде
- кто должен быть тоньше
Первый опыт
- проект
4.
5.
6. - Entity
- Value Object
- Aggregate
- Service
- Repository
- Factory
- Domain events
7. Проблемы
как формировать слои
- так ли вы поняли что такое
а вы случаем не перепутали и
как часто вы общаетесь с экспертами
- можете ли вы абстрагироваться от предыдущего опыта и
забыть все его практики
- все больше недоступны
- о базе данных нужно думать в последнюю очередь
- сообщество против вас
8. Первые попытки:
- неправильное разделение приложения на модули (по
таблицам БД)
- слой сериализации данных
- отказ от использования callbacks в моделях
- отказ от использования валидаций
- добавление репозитариев-оберток над ActiveRecord
Этапы эволюции
9. - стало больше неправильных классов, связанность кода меньше
- отсутствует application layer
- неправильные bounded contexts
- отсутствие
- сложно читаемый код! не ruby-way!
obj = A::B::C::D.new
obj.perform_operation
- тестировать все также сложно (попытка инъекций через конструктор)
def users_repository
Repositories::Users.new
end
- models и repositories не разделены
Первые результаты
10. - полный отказ от ActiveRecord, переход на datamapper (Sequel)
- четкое выделение application, domain, infrastructure слоев
- ubiquitous language
- отказ от любых общих названий Services, Base*, *Manager
- правильное выделение bounded contexts
- внедрение dependency injection
- быстрые, понятные, поддерживамые тесты (TDD стандарт)
- база - данных деталь реализации
- строгий режим работы с АПИ (application layer стал понятным)
- осознание, что write model != read model. Смотрим в сторону CQRS.
- отказ от devise и прочих стандартных гемов
- и наконец-то! rails - деталь реализации
Переосмысление
17. - строгий код (код подскажет, когда вы ошибаетесь)
- не тестируйте стек фреймворка (он уже протестирован)
- активно используйте DI в тестах
- применяйте SOLID принципы
- выделяйте из приложения микросервисы (SOA)
- оборачивайте все внешние гемы в DI классы
- DI классы stateless
- читайте форумы java и .Net
Еще практики
18. - умение общаться с доменным экспертом
- понимание и применение ООП
- активное применение TDD
- практика применения принципов SOLID
Порог вхождения, чтобы начать нормально работать:
Для junior-разработчика 2-3 месяца
Для middle-разработчика 2-3 недели
Требования к команде