Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

История создания продукта http://workmateapp.com http://planiro.com Workmate Planiro

Slide 3

Slide 3 text

Аудитория продукта

Slide 4

Slide 4 text

Связанность данных

Slide 5

Slide 5 text

Требования к системе 1) Task-based UI! 2) Отзывчивость! 3) Простота! 4) Масштабируемость! 5) Расширяемость! 6) Real-time updates

Slide 6

Slide 6 text

Технологии 1. Ruby 2.1.x, Rails 4.1.x 2. Postgres 3. Coffescript, AngularJS 4. Slim, SASS(SCSS) 5. RabbitMQ 6. Тестирование Rspec

Slide 7

Slide 7 text

Архитектура приложений Чем помогает архитектура?> ! 1) понятность кода и предметной области 2) модульность приложения: чем больше система, тем легче добавить новый компонент системы 3) масштабируемость приложения ! Архитектура приложений - это> 1) принятые ключевые решения 2) компромисс ! !

Slide 8

Slide 8 text

Выбор архитектуры для Planiro ! ! Workmate - monolithic data centric architecture ! Плюсы: 1) низкий порог вхождения 2) отлично подходит для CRUD приложений ! ! ! Проблемы: 1) высокая связанность компонентов приложения 2) низкая связность отдельных моделей 3) DB-driven разработка -> сложно увидеть предметную область 4) сложность масштабирования ! ! !

Slide 9

Slide 9 text

Выбор архитектуры для Planiro ! ! Planiro - Multilayered event driven architecture with SOA ! Плюсы: 1) все сервисы автономны и имеют выраженные границы -> высокая связность моделей и низкая связанность модулей 2) масштабируемость и распределенность 3) единый протокол взаимодействия ! Проблемы: 1) выше порог вхождения 2) большое количетво модулей и классов 3) разработка немного медленнее на начальном этапе ! ! ! !

Slide 10

Slide 10 text

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 ! !

Slide 11

Slide 11 text

DDD подход We should always start from questions: ! 1. Why does it change? 2. When does it change? 3. How often? 4. Who causes it? 5. By which rules? 6. What consequences? !

Slide 12

Slide 12 text

DDD: Слои приложения 1. Application Layer 2. Domain Layer 3. Infrastructure Layer

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

CQRS CQRS - Command Query Responsibility Segregation История появления: ! CRUD - манипуляции c данными ! ! ! ! TASK UI - выполнение бизнес задач !

Slide 15

Slide 15 text

CQRS: commands Команда – представляет собой отражение бизнес действия, в котором заинтересован пользователь приложения. ! Преимущества: 1. Ориентация на бизнес проблемы пользователя. 2. Удобный механизм мониторинга и масштабирования ! !

Slide 16

Slide 16 text

CQRS: queries

Slide 17

Slide 17 text

CQRS: границы применимости 1. Сложная предметная область 2. Domain Driven Design 3. Task UI 4. Нужна масштабируемость

Slide 18

Slide 18 text

Application Layer Request form description Command definition

Slide 19

Slide 19 text

Application Layer

Slide 20

Slide 20 text

Domain Layer 1. Account management system 2. Commenting system 3. PM system -> Core app module 4. Entities 5. Notification system 6. Subscription system 7. Security system

Slide 21

Slide 21 text

Infrastructure layer 1. RDMS: Repositories, Read Model, Seeds etc! 2. Mailing System! 3. Background commands system! 4. Reminders system! 5. Websockets system! 6. History system! 7. Configs! 8. File Storage!

Slide 22

Slide 22 text

Что получили? 1. Развитый домен 2. Низкая связанность модулей 3. Легкость масштабирования 4. Простота тестирования

Slide 23

Slide 23 text

Технологии 1. Bower package manager 2. Grunt 3. Coffescript 4. AngularJS 1.2.x 5. Тестирование - karma (selenium)

Slide 24

Slide 24 text

Выбор фреймворка Плюсы:> 1) мало кода! 2) двухсторонняя связывание данных! 3) директивы (расширение функционала DOM элементов)! 4) встроенный механизм dependency injection! 5) большое community и быстрое развитие! ! Минусы:> 1) порог вхождения в разработку с использованием angular высокий! 2) на каждое изменение происходит проверка всех binding текущего scope -> потенциальные проблемы с производительностью! 3) MVW -> W == whatever - самому нужно решить, что это будет -> отсутствие общих практик разработки на angular.js! 4) поверхностная документация

Slide 25

Slide 25 text

Архитектура 1) Domain driven design -> multilayered architecture (data mappers, repositories, factories etc)! ! 2) Отказ от event driven разработки! ! 3) Директивы! ! Дополнительные соглашения: всегда работаем с promise! ! !

Slide 26

Slide 26 text

Примеры директив

Slide 27

Slide 27 text

Сложности Существенные проблемы производительности при работе с директивой ng-repeat, вложенной в другую ng-repeat! ! Angular не может кешировать DOM для таких ситуаций.! ! Решение: разработана альтернатива ng-repeat, которая умеет кешировать DOM -> производительность возрасла в 30-50 раз!

Slide 28

Slide 28 text

Angular learning curve

Slide 29

Slide 29 text

Ссылки 1. Блог компании - http://droidlabs.pro/blog (видео лекции по DDD и CQRS) 2. Ioc Container - https://github.com/ AlbertGazizov/ioc_rb 3. Form Caster - https://github.com/ AlbertGazizov/hcast 4. Datamapper Adapter for Sequel - https:// github.com/AlbertGazizov/sequel_dm