Руслан Гатиятов Казань, 2014 г. 

План работы 1. Архитектура приложений 2. Границы применимости паттерна ActiveRecord 3. Предметно-ориентированное проектирование (Domain Driven Design) ! Перерыв ! 1. Монолитная и модульная архитектура приложений 2. Переход от DB-Driven проектирования к Domain Driven проектированию 

Архитектура приложений Чем помогает архитектура? ! Николай Рыжиков - “уменьшить боль разработки” (HappyDev’13 http://2013.happydev.ru/report/22) ! 1) понятность кода и предметной области 2) Модульность приложения: чем больше система, тем легче добавить новый компонент системы 3) масштабируемость приложения ! Архитектура приложений - это 1) принятые ключевые решения 2) компромисс 

Rails плюсы 1) быстрый старт 2) DRY 3) Conventions over configuration 4) Многие проблемы уже решены -> gems 5) Красивый DSL (роутер, active record, …) 6) Набор инструкций как решать проблемы 

Rails минусы 1) НеПонятность кода/сложность рефакторинга 2) высокая связанность компонентов приложения (насколько сильно один модуль приложения зависит от других) 3) низкая связность отдельных моделей 4) отсутствие общих стандартов программирования 5) DB-driven разработка (центр вселенной - это база данных) 

Реальность 1) Сложная предметная область 2) Постоянно изменяющиеся требования 3) Изменение состава команды/разный уровень подготовки членов команды/несколько команд 4) необходимость масштабируемости 

ActiveRecord 1) Persistance/Querying 2) Attributes Casting -> Sanitization 3) Validations 4) Callbacks 5) Associations 6) Object building + nested attributes 7) Serialization (to_xml, to_json) 

Нужно ли задуматься? 1) Модель участвует в нескольких бизнес-процессах (ключевые “модели” приложения) -> низкая связность модели 2) Наличие условных валидаций или колбэков 3) Логика модели зависит от роли пользователя 4) Оптимизация производительности приложения 5) Сильная связанность слоев приложения: Application, Domain, Infrastructure 

Что делать? - А кто последний? Молчание... - Тогда буду первым! ! 1) Сообщество 2) Перенимать практики из Java, .Net и пр 

Слои приложения 1) Application Layer 2) Business Layer 3) Infrastructure Layer 

Подходы проектирования TDD BDD FDD DDD Почему так много DD? 

Подходы проектирования TDD test driven development BDD FDD DDD 

Подходы проектирования TDD BDD behaviour driven developme nt FDD DDD 

Подходы проектирования TDD BDD behaviour driven developme nt FDD facepalm driven developme nt DDD 

Подходы проектирования TDD BDD behaviour driven developme nt FDD DDD domain driven design 

Общие понятия Домен - это совокупность знаний о предметной области ! 1) Доменная модель 2) Единый язык (ubiquitous language) 3) Bounded context 

Доменные сущности 1) Entity - an object that is not defined by its attributes, but rather by a thread of continuity and its identity 2) Value Object - An object that contains attributes but has no conceptual identity. Should be treated as Immutable. 3) Aggregate - A collection of objects that are bound together by a root entity, otherwise known as an aggregate root. 4) Service - implements domain logic when it can’t be done in object. 5) Repository - is an abstraction over persistence store, returning entities or aggregate roots, meeting some criteria 6) Factory - methods for creating domain objects. 7) Domain events 

Вопросы к экспертам • Why does it change? • When does it change? • How often? • Who causes it? • By which rules? • What consequences? 

Пример диалога 

Когда применять 1) Сложная предметная область 2) Команда разбирается в ООП 3) Постоянное общение с доменными экспертами 4) Итеративный процесс разработки ПО 

Заключение Постоянное развитие Rails, хранилище данных и пр. как - это деталь