O documento discute como aplicar Domain-Driven Design (DDD) na construção de microservices, enfatizando a importância de se desenvolver um modelo de domínio para orientar a fragmentação em serviços e garantir a coerência entre os contextos.

1. Olá pessoas!

2. JOGO RÁPIDO!
➔ Quem conhece DDD?
➔ Quem utilizou DDD na prática?
➔ Quem utiliza microservices?
➔ Quem aplica DDD em microservices?

3. Como DDD e principalmente
Domain Model
contribuem na construção de
microservices.
Isaac Felisberto de Souza
Engenheiro de Software

4. ROTEIRO
DE HOJE!
1 VISÃO GERAL SOBRE DDD.
2 APLICANDO DDD EM MICROSERVICES!

5. VISÃO GERAL SOBRE DDD

6. ➔ Eric Evans
➔ Publicado em 2004.
➔ Possui 450+ páginas.

7. O que é DDD?
DDD é uma abordagem
para construção de software
com foco no domínio do negócio

8. O que isso
representa na
prática?
Que a organização de módulos,
classes, atributos e outros
artefatos do software devem
corresponder ao modelo de
domínio do negócio.
➔ Nomenclatura
➔ Composição
➔ Agrupamento
➔ Limites
Devem expressar o negócio,
e não apenas camadas ou detalhes
técnicos de implementação.

9. DDD é um tipo de arquitetura?
Não...
Embora alguns considerem um
Padrão de Arquitetura,
e isso até faz sentido.

10. Mas DDD vai além da arquitetura...
Ele estabelece uma linguagem e
entendimento sobre o negócio
Que orienta a organização dos
componentes em uma arquitetura

11. Design
Tático
Design
Estratégico
Modelagem do
domínio de
negócio
Padrões de
arquitetura
e de projeto

12. Design
Estratégico

13. Domain Model
Ubiquitous
Language
Bounded
Context
Polissemia Designed by pch.vector / Freepik

14. Domain Model
Ubiquitous
Language
Bounded
Context
Polissemia
➔ Qual o domínio do negócio?
➔ Quais contextos e entidades?
Eric Evans diz que:
“O coração do software está na sua capacidade de
resolver problemas relacionados ao domínio…”
“... É preciso afiar sua capacidade de modelagem e
dominar o design de domínios.”
(entidades não são as tabelas de um banco de dados)

15. Domain Model
Ubiquitous
Language
Bounded
Context
Polissemia
Quem?
➔ Profissionais na gestão e negócio.
➔ Designers.
➔ Desenvolvedores(as).
➔ Times de Operação.
➔ Time de Suporte.
O uso de uma linguagem universal.

16. Domain Model
Ubiquitous
Language
Bounded
Context
Polissemia
martinfowler.com

17. Domain Model
Ubiquitous
Language
Bounded
Context
Polissemia
A porta do banco travou.
Qual o significado da palavra Banco?
Chegando na praça, sente
no banco e aguarde
Estou esperando em frente ao banco da praça.
Agência ou Instituição
Bancária

18. Design
Tático

19. Arquitetura organizada
por Camadas
➔ User Interface: Apresentar e
interpretar comandos do
usuário ou outro sistema.
➔ Application: Funções que são
executadas pelo Software.
➔ Domain: Regras de negócio.
➔ Infrastructure: Recursos
técnicos genéricos

20. Uso de
padrões de arquitetura
e de projeto
➔ Services
➔ Repositories
➔ Entities
➔ Value Objects
➔ Aggregates
➔ Factories

21. Mas usar esses padrões, não
significa estar aplicando DDD.
O foco é o modelo de domínio!

22. E… não compreender e trabalhar
o modelo de domínio
Foi nosso maior erro ao tentar
aplicar DDD em monólitos.

23. Normalmente focamos
apenas nas camadas!
➔ Regra de negócio não está apenas em Domain.
➔ Domain não organizados por contextos.
➔ Pouca clareza sobre conceitos do domínio.
➔ Múltiplos termos/palavras para coisas iguais.
➔ Dentre outros…
Em monólitos…

24. APLICANDO DDD EM MICROSERVICES

25. Normalmente, um dos primeiros passos
de quem inicia em microservices é:
Fragmentar a solução em vários projetos,
e se ela era monolítica, abandonar tudo
aquilo que “traumatizou”.

26. Microservices
abandonam a
organização de
camadas.
➔ Não há visão de contextos.
➔ Cada microservice utiliza suas nomenclaturas.
➔ Não há clareza sobre dependências.
➔ Frontend acessa direto todos microservices.
➔ Inconsistências nos Contratos de API’s.
➔ Dentre outros…

27. Design
Estratégico

28. Domain Model
Ubiquitous
Language
Bounded
Context
Polissemia
“O coração do software…”
A solução deve possuir um modelo de domínio!
Uma solução fictícia, chamada Guia Hóspede,
o domínio é: RESERVA DE HOTÉIS.

29. Modelo de domínio do Guia Hóspede

30. QUAL O TAMANHO
DE UM MICROSERVICE?
➔ As entidades determinam os
contratos das API’s.
➔ O modelo indica as dependências.
➔ Contextos indicam a fragmentação
inicial de microservices.

31. Domain Model
➔ Entidades fracas não precisam ser isoladas em um microservice.
⚠ Cuidado com excesso de fragmentação. ⚠
➔ Um microservice para esse contexto é aceitável.

32. Domain Model
➔ Hotel é a entidade forte, terá um microservice.
➔ Acomodação também é uma entidade forte.
Acomodação...
➔ Inicia no microservice
de hotéis.
➔ Quando precisar de
escala, será segregada.

33. Domain Model
➔ Hóspede parece uma entidade forte, mas...
➔ O contexto foca na estadia, um microservice para o contexto é aceitável.

34. Domain Model
➔ Mais importante que o tamanho do microservice, é o contexto.
➔ As dependências entre microservices seguem o modelo de domínio.
➔ O modelo ajuda a compreender possíveis evoluções.
➔ Os microservices explicitam melhor o domínio de negócio.
hoteis-service stays-service
accounts-service
accommodations-service

35. Domain Model
Ubiquitous
Language
Bounded
Context
Polissemia
Todos utilizam uma linguagem universal!
O nome de contextos, entidades e atributos é utilizada em:
➔ Nome dos microservices e Contrato das API’s.
➔ Modelagem da persistência de dados.
➔ Artefatos distribuídos.
➔ Endereço dos Endpoints.
➔ Mapeamentos de monitoramento.
➔ No diálogo entre integrantes do projeto/empresa.

36. Domain Model
Ubiquitous
Language
Bounded
Context
Polissemia
Microservices respeitam os limites de cada contexto!
➔ Informação adequada
ao contexto.
➔ Dependência fraca
entre entidades.
➔ Conta é uma entidade genérica. (Hotéis e usuários).
➔ Dados específicos para conta de hotéis no contexto de hotéis.
➔ A chave entre entidades é um UUID, ou “strings humanizadas”.

37. Domain Model
Ubiquitous
Language
Bounded
Context
Polissemia
Nomenclaturas não geram dúvidas!
➔ Conta, é a representação genérica.
➔ Conta de Parceiros, dados adicionais de contas de hotéis.
➔ Reserva, é Reserva de Estadias.

38. Design
Tático

39. ➔ Adoção de API Gateway.
➔ Frontend ou sistemas externos acessam
o API Gateway.
➔ API’s mapeadas no gateway respeitam o
modelo de domínio.
➔ O API Gateway -> Application Layer
Representação da
Application Layer

40. ➔ Agrupados por domínio/contexto.
➔ Uso de um Core Domain.
Os microservices
representam a
Domain Layer

41. Arquitetura
Orientada a
Eventos
possibilita uso de
DOMAIN EVENTS
➔ Schemas seguem o modelo de domínio.
➔ Nomenclatura de filas seguem as entidades.
➔ Agrupamentos lógicos seguem os contextos.

43. Para construir microservices
organizados,
com menor acoplamento,
maior coesão
e focados no negócio.

44. O uso de DDD,
em especial Domain Model
se torna uma abordagem essencial!

45. Isaac Felisberto de Souza
Engenheiro de Software
isaacsouza@gmail.com
linkedin.com/in/isaacfsouza
Obrigado!
Dúvidas?
Visite:
www.guia.dev
Conheça:
PARA EMPRESAS
Siga e compartilhe:
@guia_dev
Guia Dev