Docker cqrs react
•
1 like•203 views
An journey in the world of Domain Driven Design using Command Query Responsibility Segregation, React and Docker as a deployment tool
Recommended
More Related Content
Similar to Docker cqrs react
Similar to Docker cqrs react (20)
Recently uploaded
Recently uploaded (20)
Docker cqrs react
- 1. CQRS, REACTJS, DOCKERIN A NUTSHELL Andrea GiulianoClaudio D'Alicandro Simone Di Maulo
- 3. WE CAN WRITE IT FROM SCRATCH
- 4. BUT
- 5. immagine manager incazzato WE NEED IT IN A VERY FEW TIME
- 6. AND
- 7. IT SHOULD BE
- 8. WTF!
- 10. COMFORT ZONE
- 11. DOMAIN ▸ data come from and go to external entities ▸ users can configure to send a subset of data ▸ users send data based on their plan send data from a source to a target GOAL
- 12. THE DOMAIN ▸ unpredictable data structures ▸ ad hoc workflow for each vendor ▸ variable number of steps ▸ handle rate limits from different vendors ▸ handle different error cases from different vendors ▸ handle business-oriented limits (based on plans...) ▸ some tasks need to be done asynchronously
- 13. IDEA
- 14. BLACK BOX REASONING ▸ identify the main entities involved ▸ define a common input and output ▸ find a way to let things talk INPUT OUTPUT
- 22. BC APPLICATION DIRECTORY TREE
- 23. BC MODEL DIRECTORY TREE
- 24. BC PRESENTATION DIRECTORY TREE
- 25. EVERYTHING'S AWESOME ▸ the framework is an implementation detail ▸ the directory structure is explicit ▸ the domain is isolated
- 26. WE DON'T WANT TO MESS THINGS UP
- 27. DON'T MESS UP THINGS
- 28. WHAT'S THE ISSUE HERE ▸ understandable? ▸ code can't be reused ▸ high coupling ▸ untestable ▸ too many responsibilities ▸ hard to find bugs ▸ not changes-prone
- 29. WHAT WE WANT
- 30. COMMAND QUERY RESPONSIBILITY SEGREGATIONAKA CQRS A SOLUTION
- 31. CQRS ▸ separe reads from writes ▸ commands perform actions ▸ queries return data ▸ heterogeneous data storages ▸ easy scaling ▸ deal with eventual consistency
- 32. WRITE STORAGE QUERY COMMAND COMMAND COMMAND BUS COMMAND HANDLER DOMAIN REPOSITORY READ STORAGE REPOSITORY EVENT BUS EVENT SUBSCRIBER
- 34. IT'S ALL ABOUT BUSES COMMUNICATION
- 36. MESSAGE BUS $ composer require simple-bus/message-bus
- 37. COMMANDS COMMAND BUS Represent the change that should be done in the domain They are named with a verb in the imperative tense and may include the aggregate type, for example ScheduleATask.
- 38. COMMANDS COMMAND BUS CONTROLLER $commandBus->handle( ScheduleATask::fromTaskId($taskId) ); HANDLER public function handle(Command $command) { //do something with the $command }
- 39. EVENTS BC 1 BC 2 EVENT BUS An event represents something that took place in the domain. They are always named with a past-participle verb, such as TaskScheduled
- 40. EVENTS BC 1 BC 2 EVENT BUS subscribes_to: 'user-created' subscribes_to: 'task-stopped' subscribes_to: 'task-suspended'
- 41. EVENTS BC 1 BC 2 EVENT BUS $messageBus->handle( UserCreatedEvent::fromUser($user) ); subscribes_to: 'user-created' subscribes_to: 'task-stopped' subscribes_to: 'task-suspended' $messageBus->handle( TaskSuspendedEvent::fromTask($task) );
- 42. COMMUNICATION AMONG BCS BC 1 BC 2 QUEUE NETWORK
- 43. QUEUE BC 1 BC 2 QUEUE $producer->publish($message); $consumer->consume($message);
- 44. NETWORK BC 1 BC 2 NETWORK $httpClient->post('/tasks/schedule'); POST /tasks/schedule
- 45. SCENARIO: TRIGGER THE TASKS SCHEDULE EVERY 10 MINUTES TIMER
- 46. SCENARIO: TRIGGER THE TASKS SCHEDULE EVERY 10 MINUTES TIMER SCHEDULER POST /tasks/schedule
- 47. SCENARIO: TRIGGER THE TASKS SCHEDULE EVERY 10 MINUTES TIMER SCHEDULER POST /tasks/schedule DATA STORAGE $taskRepository->getAll()
- 48. SCENARIO: TRIGGER THE TASKS SCHEDULE EVERY 10 MINUTES TIMER SCHEDULER POST /tasks/schedule DATA STORAGE $taskRepository->getAll() TASK QUEUE enqueue($taskId)
- 49. SCENARIO: TRIGGER THE TASKS SCHEDULE EVERY 10 MINUTES TIMER SCHEDULER POST /tasks/schedule DATA STORAGE $taskRepository->getAll() TASK QUEUE enqueue($taskId) W1 W2 W3 W..N...
- 50. LET ME SEE WHAT YOU HAVE DONE IT'S TIME TO SHOW DOWN
- 51. WHAT THE TEAM HAS DELIVERED
- 52. WHAT THE MANAGEMENT SEE
- 53. WHAT THE MANAGEMENT WANTS
- 54. LET'S START FROM THE TEMPLATE
- 55. TWIG
- 57. THE FRONTEND STUFF ORDER DEPENDENT
- 58. THE FRONTEND STUFF GLOBAL SCOPE
- 59. <script> $('.btn').click(function(e){ e.stopPropagation(); // Do something cool! }); </script> NEVER TRUST THE GLOBAL SCOPE
- 60. A STEP BACKWARD
- 61. WE ARE BACKEND DEVELOPERS
- 62. OUR COMFORT ZONE
- 63. OOP
- 64. ENCAPSULATION
- 65. MODULES
- 67. GOOD NEWS
- 69. ECMASCRIPT 6
- 70. DEFAULT VALUES
- 71. CLASSES
- 72. INHERITANCE
- 74. IMPORT A MODULE
- 75. IMPORT ONLY WHAT YOU NEED
- 76. WHAT ABOUT THE UI?
- 78. var React = require('react'); var ReactDOM = require('react-dom'); ReactDOM.render( <h1>Hello, world!</h1>, document.getElementById('app') );
- 86. A LOT OF SMALL COMPONENTS
- 87. A LOT OF SMALL APPLICATIONS
- 88. BOUNDED CONTEXT FACEBOOK BOUNDED CONTEXT MAILCHIMPBOUNDED CONTEXT MAPPING
- 89. BOUNDED CONTEXT FACEBOOK BOUNDED CONTEXT MAILCHIMPBOUNDED CONTEXT MAPPING
- 90. Gulp Bundler + BOUNDED CONTEXT FACEBOOK BOUNDED CONTEXT MAILCHIMPBOUNDED CONTEXT MAPPING
- 92. $ docker/gulp docker-compose run --rm --entrypoint bash npm -c "gulp"
- 93. // gulpfile.js var gulp = require('gulp'); var hub = require('gulp-hub'); process .env .WEBPACK_CONFIG_FILE = path.join( __dirname, 'webpack.config.js' ) ; hub(['src/**/gulpfile.js']);
- 94. BOUNDED CONTEXT FACEBOOK BOUNDED CONTEXT MAILCHIMPBOUNDED CONTEXT MAPPING gulpfile.js gulpfile.js gulpfile.js
- 95. BOUNDED CONTEXT FACEBOOK gulpfile.js "## FacebookPresentationBundle.php $## Resources "## assets "## config "## public $## views
- 96. $ app/console assets:install LET'S EXPOSE TO THE WEB
- 98. IT'S A BIG WORLD OUT THERE!
- 103. THE DEVELOPMENT ENVIRONMENT ▸ Easy to use so many technologies at no installation cost ▸ Prepare the scaffolding for a new developer is extremely simple ▸ Superior performances over previous systems
- 105. THE INFRASTRUCTURE
- 106. THE INFRASTRUCTURE
- 107. THE INFRASTRUCTURE
- 108. THE INFRASTRUCTURE
- 111. STAGE ▸ Automate image building ▸ Copy the same structure used in dev
- 112. STAGE ▸ Automate image building ▸ Copy the same structure used in dev
- 113. AUFS: VOLUMES MIGHT BE A LITTLE HARDER THAN IT SEEMS
- 114. SYMFONY PARAMETERS
- 116. DOCKER CLOUD REPOSITORY CONFIGURATION
- 119. DATA ONLY CONTAINER
- 120. DATA ONLY CONTAINER
- 121. DATA ONLY CONTAINER
- 122. DATA ONLY CONTAINER
- 123. FIRST DEPLOY
- 124. AN ELEPHANT IN THE ROOM... WE NEED ▸ Automated deploy strategy ▸ The freedom to easily scale
- 125. SCALE $ docker-compose scale web=2 worker=3
- 126. HARD TRUTH fpm: image: 'adespresso/hubespresso-staging:fpm-latest' deployment_strategy: every_node sequential_deployment: true tags: - fpm - hubespresso - production volumes: - /var/www/project volumes_from: - shared-fpm.hubespresso-production SCALE CONTAINERS IS WORTHLESS IF YOU DO NOT SCALE NODES
- 127. HARD TRUTH SCALE CONTAINERS IS WORTHLESS IF YOU DO NOT SCALE NODES fpm: image: 'adespresso/hubespresso-staging:fpm-latest' deployment_strategy: every_node sequential_deployment: true tags: - fpm - hubespresso - production volumes: - /var/www/project volumes_from: - shared-fpm.hubespresso-production
- 128. DATA ONLY CONTAINER IS A PAIN
- 130. DEPLOYMENT ▸ deploy the infrastructure is not straightforward ▸ multiple container in multiple nodes ▸ every container has its own lifecycle ▸ we are not assuring zero-downtime on deployment
- 131. THE SOLUTION: GREEN BLUE DEPLOYMENT
- 132. THE SOLUTION: GREEN BLUE DEPLOYMENT
- 133. THE SOLUTION: GREEN BLUE DEPLOYMENT
- 134. CONCLUSION
- 137. THANKS
- 138. QUESTIONS?