Modular Monoliths - Como é possível organizar sua aplicação para habilitar uma arquitetura distribuída

O objetivo desta palestra é mostrar como é possível construir uma aplicação baseada na idéia de MonolithFirst e atrasar a decisão de separar em microserviços. A ideia de modular monoliths vem da organização e separação da sua aplicação em módulos ou componentes autônomos que se relacionam entre si, mas estão dentro de uma mesma base de código. Nesta palestra será mostrado como identificar e separar estes módulos, além de um processo que permite extrair um módulo e distribuir como um microserviço.

Transcript

1. Globalcode – Open4education Modular Monoliths Luiz Costa gutomcosta@gmail.com / @gutomcosta Como é possível organizar sua aplicação para habilitar uma arquitetura distribuída
3. Monoliths, Modular, Microservice? Antes, as definições.
4. Monolito?
5. A monolithic application is self-contained, and independent from other computing applications. The design philosophy is that the application is responsible not just for a particular task, but can perform every step needed to complete a particular function. Wikipedia -Monolithic application
6. A monolithic application is self-contained, and independent from other computing applications. The design philosophy is that the application is responsible not just for a particular task, but can perform every step needed to complete a particular function. Wikipedia -Monolithic application
7. A monolithic application is self-contained, and independent from other computing applications. The design philosophy is that the application is responsible not just for a particular task, but can perform every step needed to complete a particular function. Wikipedia -Monolithic application
8. Modular?
9. …The system is divided into a number of relatively independent modules with well defined interfaces; each one is small enough and simple enough to be thoroughly understood and well programmed… On the criteria to be used in decomposing systems into modules - David Parnas, 1971
10. …The system is divided into a number of relatively independent modules with well defined interfaces; each one is small enough and simple enough to be thoroughly understood and well programmed… On the criteria to be used in decomposing systems into modules - David Parnas, 1971
11. …The system is divided into a number of relatively independent modules with well defined interfaces; each one is small enough and simple enough to be thoroughly understood and well programmed… On the criteria to be used in decomposing systems into modules - David Parnas, 1971
12. Microservices?
13. Módulos separados em unidades de deploy independentes - aka Distribuídos
14. Módulos separados em unidades de deploy independentes - aka Distribuídos
15. Distribuir é complicado
17. Segurança? Apis? Versionamento? Servidores? Transações distribuídas? Containers? Monitoramento?
18. Fowler’s First Law of Distributed Object Design
19. Don’t distribute your objects. http:/ /martinfowler.com/books/eaa.html
20. Modular Monoliths
22. O que é?
23. Monolith Service Based architecture (SOA, microservices) Livre adaptação do diagrama de Simon Brown - https:/ /goo.gl/tCCwZx
24. Monolith Service Based architecture (SOA, microservices) Modular Monolith Livre adaptação do diagrama de Simon Brown - https:/ /goo.gl/tCCwZx
25. Como é organizado?
27. Módulos bem definidos promovem o encapsulamento
28. Se comunicam através de interfaces bem definidas
29. Podem acessar mais de um banco de dados
30. Como implementar uma arquitetura modular assim?
31. Domain Driven Design
32. the blue and the red book
33. Total unification of the domain model for a large system will not feasible or cost-effective “Domain Driven Design, Chapter 14 - Maintaining Model Integrity", pág: 332 Eric Evans - Blue Book
34. Um típico “domain model” ou tabelas de banco de dados
35. Como dividir o domínio?
36. Contexto A Contexto B Contexto C
37. Strategic Design
38. Bounded Context
39. Bounded Context …delimits the applicability of a particular model so that team members have a clear and shared understanding of what has to be consistent and how it relates to other contexts. “Domain Driven Design, Chapter 14 - Maintaining Model Integrity", pág: 336 Eric Evans - Blue Book
40. Bounded Context Delimita o significado e a aplicabilidade de um domain model.
42. Mesmo objeto de domínio em diferentes contextos
43. Paciente Atendimento + qual nome, nascimento…? + qual dia do agendamento? + qual endereço de atendimento? Paciente Vacinação + como a caderneta de vacinação está organizada? + qual a próxima vacina? + qual vacina foi aplicada? Paciente Financeiro + qual custo das vacinas aplicadas? +alguma condição de desconto? +qual meio de pagamento utilizado? É responsabilidade de cada contexto modelar os dados da melhor maneira, de acordo com a as suas responsabilidades.
44. Um módulo é a implementação de um Bounded Context
45. Como implementar?
46. Anatomia de um Bounded Context
47. Hexagonal Architecture Uncle Bob’s Clean Architecture Diagrama - https:/ /stefanoalletti.wordpress.com/2017 /10/27 /hexagonal-architecture/ https:/ /staging.cockburn.us/hexagonal-architecture/ https:/ /8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html
48. Bounded Context Domain Application use case use case use case Repository Entity Value Object Infrastructure Entity DAO Logger Service Domain driven design module
49. Application Domain Atendimento.Fila Infrastructure
50. Implementação de um Caso de Uso o fluxo de execução é simples e limpo todas as dependências são declaradas no construtor
51. Foco total no Domain Model Domain Model != Model
52. Todas as regras de negócio são programadas aqui. Normalmente são objetos puros, sem relação com persistência ou infra-estrutura Expostas através de casos de uso
53. Como o projeto fica organizado?
55. Código da aplicação vive aqui. Frameworks estão em Web App.
56. Cada Bounded Context é implementado como um módulo dentro da aplicação
57. Como bounded contexts se relacionam?
58. As relações entre Bounded Contexts acontecem através de um conjunto patterns conhecidos como Context Mappers
59. ANTI-CURRUPTION LAYER SHARED KERNEL OPEN HOST SERVICE PUBLISHED LANGUAGE CONFORMIST CUSTOMER / SUPPLIER … Existe vida além parte 1 do livro azul
60. Implementando uma User Story
61. Deve permitir o paciente agendar a aplicação de vacina. Ao fazer o agendamento deve-se efetuar o pagamento e reservar o estoque dos produtos agendados. User Story
62. User Story Deve permitir o paciente agendar a aplicação de vacina. Ao fazer o agendamento deve-se efetuar o pagamento e reservar o estoque dos produtos agendados.
63. Bounded Contexts
64. Como um contexto executa uma ação em outro contexto?
65. Boundaries https:/ /martinfowler.com/bliki/ApplicationBoundary.html
66. O ideal é que um contexto só exponha objetos de fronteira. Ex: Use Cases, Services ou Repositories Se precisar retornar um conjunto de dados mais complexo, dê preferência para Hashs ou Tuplas Mantenha o domain model protegido dentro do contexto. O ideal é não deixar “vazar" do contexto os objetos de domínio
67. public class Deve se reduzir o número de classes públicas para promover o encapsulamento
68. Exemplo
69. Context Maps Open Host Service (OHS) Anti Corruption Layer (ACL) Event Publisher (EP)
70. 1.
71. Gestão De Agendas Pagamentos Neste caso os contextos se falam através dos objetos de fronteira: Services e Casos de Uso
72. Construa uma arquitetura que te permita atrasar as decisões https:/ /8thlight.com/blog/uncle-bob/2011/11/22/Clean-Architecture.html
73. Indireção para o contexto de pagamento Injeção de Dependências
74. Único ponto de contato com contexto de pagamento Efetuar Agendamento
75. Tradução do modelo entre os dois contextos
76. 2.
77. Gestão De Agendas Gestão de Estoque Os dois contextos se falam através de um domain event AgendamentoCriado
78. Publica o evento através da EP Contato com o contexto de gestão de estoque
79. Como tirar vantagem e extrair para um microservice?
80. Contexto de pagamento como microserviço O único ponto de contato com o contexto de pagamento no agendamento, era o objeto de fronteira Pagamento. Este objeto vai precisar ser alterado, e ao invés de chamar o contexto diretamente, vamos introduzir uma service layer para implementar a chamada remota ao microserviço de pagamento O contexto de pagamento foi extraído e adicionado em uma nova aplicação rails. Foi necessário expor uma api para disponibilizar o acesso aos casos de uso. Neste caso, provavelmente os respositórios deverão ser alterados para conectar no banco de dados diferente.
81. Contexto de pagamento como microserviço O único ponto de contato com o contexto de pagamento no agendamento, era o objeto de fronteira Pagamento. Este objeto vai precisar ser alterado, e ao invés de chamar o contexto diretamente, vamos introduzir uma service layer para implementar a chamada remota ao microserviço de pagamento O contexto de pagamento foi extraído e adicionado em uma nova aplicação rails. Foi necessário expor uma api para disponibilizar o acesso aos casos de usos. Neste caso, provavelmente os respositórios deverão ser alterados para conectar no banco de dados diferente.
82. Como extrair o contexto de Gestão de Estoque? Como lidar com o Domain Event AgendamentoCriado?
83. Publish/Subscribe ou Observers https:/ /en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern https:/ /en.wikipedia.org/wiki/Observer_pattern
84. Contexto de estoque como microserviço O contexto de agendamento continua publicando o domain event AgendamentoCriado da mesma forma que antes, nada muda aqui. O Event Handler original é substituído por outro que public o evento em um Broker de mensagem. Ex: RabbitMQ, Kafka, ActveMQ No microserviço de estoque, é necessário adicionar na ACL, handlers que serão estimulados pelas mensagens entregues pelo broker. Estes handlers, delegam a execução para os caso de uso.
85. Contexto de estoque como microserviço O contexto de agendamento continua publicando o domain event AgendamentoCriado da mesma forma que antes, nada muda aqui. O Event Handler original é substituído por outro que public o evento em um Broker de mensagem. Ex: RabbitMQ, Kafka, ActveMQ No microserviço de estoque, é necessário adicionar na ACL, handlers que serão estimulados pelas mensagens entregues pelo broker. Estes handlers, delegam a execução para os casos de uso.
86. Considerações Finais
87. É possível evoluir e construir um monolito de maneira organizada. Considere MonolithFirst https:/ /martinfowler.com/bliki/MonolithFirst.html
88. Mas lembre-se: https:/ /martinfowler.com/articles/dont-start-monolith.html
89. Obrigado! Luiz Costa - gutomcosta@gmail.com - @gutomcosta