Avoiding the domino effect in our [micro]services (SOLID at macro-design level)

1. Avoiding the domino effect in our [micro]services Raising the DIP & OCP to a macro-architecture level

2. @JavierCane@rafaoe Who we are Intro

3. Goals ! Illustrate how to isolate our [micro]services avoiding the domino effect " Show the similarities between the DIP & OCP applied to micro and macro design levels Intro

4. User story

5. Problem: Domino Effect

6. Stage 1: The Monolith Problem: Domino Effect

7. Stage 1: The Monolith THE MONOLITH GET /users/x PUT /videos/x DB { "id": “some-uuid", "name": "Vicenç", "total_videos_created": 1 }

8. Stage 1: The Monolith THE MONOLITH DB GET /users/x PUT /videos/xx1000# $ { "id": “some-uuid", "name": "Vicenç", "total_videos_created": 1 }

9. Recap Stage 1: The Monolith If it’s a small-medium size application: % Easy to know how the system works % Quick to develop new features  In any case: & Development scaling issues & Application scaling issues & Infrastructure scaling issues Stage 1: The Monolith

10. HATERS

11. Haters advisory " Assume we’ve actual needs to implement a [micro]services architecture: ' Multiple development teams ( Different needs that require different programming languages ) Different scaling needs for each service Introduction

12. Stage 2: The Microliths Problem: Domino Effect

13. Stage 1: The Monolith THE MONOLITH GET /users/x PUT /videos/x DB

14. USERS SERVICE GET /users/x PUT /videos/xVIDEOS SERVICE Stage 2: The Microliths DB

15. AKA Distributed Monolith * USERS SERVICE GET /users/x PUT /videos/xVIDEOS SERVICE Stage 2: The Microliths DB x1000# $

16. % Enable to develop applications in different ecosystems % Solve application scaling issues % Solve development scaling issues! (&DB schema) ☝ Not so easy to know how the system works & Infrastructure scaling issues Changelog Stage 2: The Microliths

17. Stage 2.1: Coupled Microliths Problem: Domino Effect

18. USERS SERVICE GET /users/x PUT /videos/xVIDEOS SERVICE Stage 2: The Microliths DB

19. USERS SERVICE DB GET /users/x PUT /videos/xVIDEOS SERVICE DB Stage 2.1: Coupled Microliths

20. USERS SERVICE DB GET /users/x PUT /videos/xVIDEOS SERVICE DB , Stage 2.1: Coupled Microliths x1000- $ { "id": “some-uuid", "name": "Vicenç", "total_videos_created": 1 }

21. USERS SERVICE DB GET /users/x PUT /videos/xVIDEOS SERVICE DB , Stage 2.1: Coupled Microliths x1000- $ { "id": “some-uuid", "name": "Vicenç", "total_videos_created": 1 }

22. USERS SERVICE - DB GET /users/x PUT /videos/xVIDEOS SERVICE DB , GET /videos  ?user_id=x Stage 2.1: Coupled Microliths $ x1000 AKA Distributed Monolith *

23. % Solve infrastructure scaling issues % Even more development scaling possibilities (less coupling) & Scaling issues because of coupling between services & Communications between services latency & More work to do (SQL query vs. expose & consume HTTP endpoint) Changelog Stage 2.1: Coupled Microliths

25. Do you remember… SOLID!

26. Stage 1: “The Monolith” Do you remember… SOLID!

27. import tv.codely.scala_http_api.module.video.infrastructure.MySqlVideoRepository final class VideoCreator(repository: MySqlVideoRepository) { def create(id: VideoId, title: VideoTitle): Unit = { val video = Video(id, title) repository.save(video) } } Monolithic Video Creator Use Case

29. Do you remember… SOLID! > Stage 1: “The Monolith” MySqlVideoRepository I VideoCreator

30. Highlights % Code easy to trace & Change tolerance (coupling between application services & infrastructure) Do you remember… SOLID! > Stage 1: “The Monolith”

31. Stage 2: DIP! Do you remember… SOLID!

33. import tv.codely.scala_http_api.module.video.domain.VideoRepository final class VideoCreator(repository: VideoRepository) { def create(id: VideoId, title: VideoTitle): Unit = { val video = Video(id, title) repository.save(video) } } DIP compliant Video Creator Use Case

34. trait VideoRepository { def save(video: Video): Future[Unit] } Video Repository Domain Contract

35. Do you remember… SOLID! > Stage 1: “The Monolith” MySqlVideoRepository I VideoCreator From:

36. I VideoCreator Do you remember… SOLID! > Stage 2: DIP! MySqlVideoRepository VideoRepository i To:

37. Changelog % Easy to add new implementations • Dependency Inversion Principle compliant • Open/Closed Principle compliant Do you remember… SOLID!

38. Stage 3: Hexagonal Architecture Do you remember… SOLID!

39. Infrastructure Application Domain Hexagonal architecture (DDD) Testing CQRS+DDD

40. Testing CQRS+DDDTesting CQRS+DDD > Flujo petición DDD+CQRS D A I VideoCreator MySqlVideoRepository VideoRepository i

41. Stage 4: CQRS Do you remember… SOLID!

42. Testing CQRS+DDDTesting CQRS+DDD > Flujo petición DDD+CQRS CreateVideoCommand VideoPostController D A I CommandBus i CreateVideoCommandHandler VideoCreator MySqlVideoRepository VideoRepository i

43. Testing CQRS+DDDTesting CQRS+DDD > Flujo petición DDD+CQRS Acceptance test COMMAND/QUERY CTRL REPOS MODELS SERVICES IMPLEMENTATION BUS HANDLER APP. SERVICE D A I Unit test Integration test

44. How do we apply this concept to our [micro]services? Do you remember… SOLID! From: I MySqlVideoRepositoryVideoCreator VideoCreator MySqlVideoRepository VideoRepository i To:

45. Solving the Domino effect Raising the DIP & OCP to a macro-architecture level

46. USERS SERVICE DB GET /users/x PUT /videos/xVIDEOS SERVICE DB GET /videos  ?user_id=x Stage 2.1: Coupled Microliths AKA Distributed Monolith *

47. From: I Users ServiceVideos Service ??? ? To: Videos Service Users Service Solving the Domino Effect

48. From: I Users ServiceVideos Service video_created e To: Videos Service Users Service Solving the Domino Effect

49. USERS SERVICE DB GET /users/x PUT /videos/xVIDEOS SERVICE DB Subscribed to video_created e Publishes Solving the Domino Effect

50. USERS SERVICE DB GET /users/x PUT /videos/xVIDEOS SERVICE DB x1000 $, - . video_created e Publishes Subscribed to Solving the Domino Effect

51. % Less communication (blocking latency) % More reactiveness (Reactive Manifesto) % Scaling • Development (OCP!) • Infrastructure • Application Changelog - Wins Solving the Domino Effect

52. ☝ Eventual consistency ☝ Maintain videos information in Users service ☝ Handle duplicated events (idempotency) ☝ Handle events arriving disordered Changelog - New kind of issues Solving the Domino Effect

53. 5 9 I don’t know Rick…

54. Conclusions

55. To take away / SOLID principles can be applied at micro and macro-design levels 0 Think about your Domain Events as you Domain interfaces/contracts ! Inappropriate intimacy: Services exposing information just because of other services need it. Simplify your services by limiting their APIs. 1 Domain events as ACL. Useful while refactoring legacy systems. Conclusions

56. Wait! Do we need [micro]services in order to apply these concepts at macro-design level?

57. More info CodelyTV Pro Hexagonal Architecture course (Spanish) CodelyTV Pro CQRS course (Spanish) CodelyTV Pro Scala HTTP API course (Spanish) Testing CQRS talk (Spanish) We broke up with the monolith, and started dating #eventSourcing Versioning in an Event Sourced System RabbitMQ Simulator A Series of Fortunate Events The anatomy of Domain Event Conclusions

58. 2Vídeo resúmenes de los cursos3

59. Mini-demo time! https://github.com/CodelyTV/scala-http-api/ https://github.com/CodelyTV/cqrs-ddd-php-example

60. ¡Thanks! Tweet #BilboStack2018 = Raffle CodelyTV Pro subscription

Avoiding the domino effect in our [micro]services (SOLID at macro-design level)

Esté a ler uma amostra.

Confira estes a seguir

Avoiding the domino effect in our [micro]services (SOLID at macro-design level)

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Semelhante a Avoiding the domino effect in our [micro]services (SOLID at macro-design level) (20)

Mais recentes (20)