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

Slide 1

Slide 1 text

Globalcode – Open4education Modular Monoliths Luiz Costa gutomcosta@gmail.com / @gutomcosta Como é possível organizar sua aplicação para habilitar uma arquitetura distribuída

Slide 2

Slide 2 text

No content

Slide 3

Slide 3 text

Monoliths, Modular, Microservice? Antes, as deﬁnições.

Slide 4

Slide 4 text

Monolito?

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Modular?

Slide 9

Slide 9 text

…The system is divided into a number of relatively independent modules with well deﬁned 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

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Microservices?

Slide 13

Slide 13 text

Módulos separados em unidades de deploy independentes - aka Distribuídos

Slide 14

Slide 14 text

Módulos separados em unidades de deploy independentes - aka Distribuídos

Slide 15

Slide 15 text

Distribuir é complicado

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

Segurança? Apis? Versionamento? Servidores? Transações distribuídas? Containers? Monitoramento?

Slide 18

Slide 18 text

Fowler’s First Law of Distributed Object Design

Slide 19

Slide 19 text

Don’t distribute your objects. http:/ /martinfowler.com/books/eaa.html

Slide 20

Slide 20 text

Modular Monoliths

Slide 21

Slide 21 text

No content

Slide 22

Slide 22 text

O que é?

Slide 23

Slide 23 text

Monolith Service Based architecture (SOA, microservices) Livre adaptação do diagrama de Simon Brown - https:/ /goo.gl/tCCwZx

Slide 24

Slide 24 text

Monolith Service Based architecture (SOA, microservices) Modular Monolith Livre adaptação do diagrama de Simon Brown - https:/ /goo.gl/tCCwZx

Slide 25

Slide 25 text

Como é organizado?

Slide 26

Slide 26 text

No content

Slide 27

Slide 27 text

Módulos bem definidos promovem o encapsulamento

Slide 28

Slide 28 text

Se comunicam através de interfaces bem definidas

Slide 29

Slide 29 text

Podem acessar mais de um banco de dados

Slide 30

Slide 30 text

Como implementar uma arquitetura modular assim?

Slide 31

Slide 31 text

Domain Driven Design

Slide 32

Slide 32 text

the blue and the red book

Slide 33

Slide 33 text

Total uniﬁcation 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

Slide 34

Slide 34 text

Um típico “domain model” ou tabelas de banco de dados

Slide 35

Slide 35 text

Como dividir o domínio?

Slide 36

Slide 36 text

Contexto A Contexto B Contexto C

Slide 37

Slide 37 text

Strategic Design

Slide 38

Slide 38 text

Bounded Context

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

Bounded Context Delimita o signiﬁcado e a aplicabilidade de um domain model.

Slide 41

Slide 41 text

No content

Slide 42

Slide 42 text

Mesmo objeto de domínio em diferentes contextos

Slide 43

Slide 43 text

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.

Slide 44

Slide 44 text

Um módulo é a implementação de um Bounded Context

Slide 45

Slide 45 text

Como implementar?

Slide 46

Slide 46 text

Anatomia de um Bounded Context

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

Bounded Context Domain Application use case use case use case Repository Entity Value Object Infrastructure Entity DAO Logger Service Domain driven design module

Slide 49

Slide 49 text

Application Domain Atendimento.Fila Infrastructure

Slide 50

Slide 50 text

Implementação de um Caso de Uso o ﬂuxo de execução é simples e limpo todas as dependências são declaradas no construtor

Slide 51

Slide 51 text

Foco total no Domain Model Domain Model != Model

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

Como o projeto ﬁca organizado?

Slide 54

Slide 54 text

No content

Slide 55

Slide 55 text

Código da aplicação vive aqui. Frameworks estão em Web App.

Slide 56

Slide 56 text

Cada Bounded Context é implementado como um módulo dentro da aplicação

Slide 57

Slide 57 text

Como bounded contexts se relacionam?

Slide 58

Slide 58 text

As relações entre Bounded Contexts acontecem através de um conjunto patterns conhecidos como Context Mappers

Slide 59

Slide 59 text

ANTI-CURRUPTION LAYER SHARED KERNEL OPEN HOST SERVICE PUBLISHED LANGUAGE CONFORMIST CUSTOMER / SUPPLIER … Existe vida além parte 1 do livro azul

Slide 60

Slide 60 text

Implementando uma User Story

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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.

Slide 63

Slide 63 text

Bounded Contexts

Slide 64

Slide 64 text

Como um contexto executa uma ação em outro contexto?

Slide 65

Slide 65 text

Boundaries https:/ /martinfowler.com/bliki/ApplicationBoundary.html

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

public class Deve se reduzir o número de classes públicas para promover o encapsulamento

Slide 68

Slide 68 text

Exemplo

Slide 69

Slide 69 text

Context Maps Open Host Service (OHS) Anti Corruption Layer (ACL) Event Publisher (EP)

Slide 70

Slide 70 text

Slide 71

Slide 71 text

Gestão De Agendas Pagamentos Neste caso os contextos se falam através dos objetos de fronteira: Services e Casos de Uso

Slide 72

Slide 72 text

Construa uma arquitetura que te permita atrasar as decisões https:/ /8thlight.com/blog/uncle-bob/2011/11/22/Clean-Architecture.html

Slide 73

Slide 73 text

Indireção para o contexto de pagamento Injeção de Dependências

Slide 74

Slide 74 text

Único ponto de contato com contexto de pagamento Efetuar Agendamento

Slide 75

Slide 75 text

Tradução do modelo entre os dois contextos

Slide 76

Slide 76 text

Slide 77

Slide 77 text

Gestão De Agendas Gestão de Estoque Os dois contextos se falam através de um domain event AgendamentoCriado

Slide 78

Slide 78 text

Publica o evento através da EP Contato com o contexto de gestão de estoque

Slide 79

Slide 79 text

Como tirar vantagem e extrair para um microservice?

Slide 80

Slide 80 text

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.

Slide 81

Slide 81 text

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.

Slide 82

Slide 82 text

Como extrair o contexto de Gestão de Estoque? Como lidar com o Domain Event AgendamentoCriado?

Slide 83

Slide 83 text

Publish/Subscribe ou Observers https:/ /en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern https:/ /en.wikipedia.org/wiki/Observer_pattern

Slide 84

Slide 84 text

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.

Slide 85

Slide 85 text

Slide 86

Slide 86 text

Considerações Finais

Slide 87

Slide 87 text

É possível evoluir e construir um monolito de maneira organizada. Considere MonolithFirst https:/ /martinfowler.com/bliki/MonolithFirst.html

Slide 88

Slide 88 text

Mas lembre-se: https:/ /martinfowler.com/articles/dont-start-monolith.html

Slide 89

Slide 89 text

Obrigado! Luiz Costa - gutomcosta@gmail.com - @gutomcosta