Практика применения подходов ив проектах

Руслан Гатиятов Дроид Лабс

- Явность- Поддерживаемость- Расширяемость- Безопасность- Стабильность- Предсказуемость- Масштабируемость- Тестируемость

Требования к коду

от кОсновные проблемы- сильная связанность кода- неявность кода- сложно тестировать медленные тесты-- хуки в коде- кто должен быть тоньшеПервый опыт- проект

- Entity- Value Object- Aggregate- Service- Repository- Factory- Domain events

Проблемыкак формировать слои

- так ли вы поняли что такоеа вы случаем не перепутали икак часто вы общаетесь с экспертами

- можете ли вы абстрагироваться от предыдущего опыта изабыть все его практики

- все больше недоступны- о базе данных нужно думать в последнюю очередь- сообщество против вас

Первые попытки:- неправильное разделение приложения на модули (по

таблицам БД)- слой сериализации данных- отказ от использования callbacks в моделях- отказ от использования валидаций- добавление репозитариев-оберток над ActiveRecord

Этапы эволюции

- стало больше неправильных классов, связанность кода меньше- отсутствует application layer- неправильные bounded contexts- отсутствие - сложно читаемый код! не ruby-way!

obj = A::B::C::D.newobj.perform_operation

- тестировать все также сложно (попытка инъекций через конструктор) def users_repository Repositories::Users.new end

- models и repositories не разделены

Первые результаты

- полный отказ от 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 - деталь реализации

Переосмысление

Внедрение

Формы запросов

ActiveRecord:Model

DDD:CommandHandlerEntityFactoryValidatorsRepositoryDAODataMapperEntity

- каждый модуль помещается - это отдельный gem- легко переиспользовать- просто тестировать- несколько комманд работают одновременно

для тестов

- строгий код (код подскажет, когда вы ошибаетесь)- не тестируйте стек фреймворка (он уже протестирован)- активно используйте DI в тестах- применяйте SOLID принципы- выделяйте из приложения микросервисы (SOA)- оборачивайте все внешние гемы в DI классы- DI классы stateless- читайте форумы java и .Net

Еще практики

- умение общаться с доменным экспертом- понимание и применение ООП- активное применение TDD- практика применения принципов SOLID

Порог вхождения, чтобы начать нормально работать:Для junior-разработчика 2-3 месяцаДля middle-разработчика 2-3 недели

Требования к команде

Спасибо за внимание