O documento discute a importância de aplicar Domain-Driven Design (DDD) na construção de APIs, especificamente: (1) Modelar o domínio do negócio com entidades e contextos claros; (2) Usar uma linguagem universal consistente nos contratos da API; (3) Construir a API como uma camada separada da implementação, focada no negócio.

1. A importância de DDD
e o Domain Model
na construção de APIs!
Isaac Felisberto de Souza
Engenheiro de Software

2. JOGO RÁPIDO!
RESPONDA APENAS
SE FOR
SIM
➔ Quem trabalha no dia a dia com APIs?
➔ Quem conhece DDD?
➔ Quem aplica DDD na construção de APIs?

3. ROTEIRO
DE HOJE!
1 PRÁTICAS COMUNS EM APIs.
2 VISÃO RÁPIDA SOBRE DDD.
3
APLICANDO DDD
NA CONSTRUÇÃO DE APIs!

4. PRÁTICAS COMUNS EM APIs.
1

5. O que é uma
API (Application Programming Interface) ?
É uma interface de acesso às funções que
um software disponibiliza.

6. Uma API não é apenas HTTP/REST/JSON!
➔ WebService SOAP/XML, é API.
➔ Uma biblioteca JavaScript, é API.
➔ Classes abstratas ou interfaces no Java, são APIs.
➔ ...

7. O que uma API não
deve ser!?!?
Ela não deve ser
a implementação que contém
regras de negócio.
Uma API deve prover o
acesso às regras de
negócio!
E... para a sequência
deste papo, usaremos
API Rest como base

8. APIs que
apenas expõe
a modelagem do
banco de dados.
APIs modeladas
de acordo com a
UI da solução.
Retornando
às práticas comuns, temos:

9. APIs que
apenas expõe
a modelagem do
banco de dados.
É comum… :
➔ Paths que representam diretamente o modelo do
banco de dados, sejam tabelas, coleções, etc.
➔ Classes de ORM usadas também como
mapeamento para composição das APIs.
➔ Colunas “internas” do banco expostas nas APIs.
O que fazer quando?...
➔ Há uma mudança no banco de dados.
➔ Algumas colunas não devem ser expostas.
➔ Decide-se mudar a forma de persistência.

10. APIs modeladas
de acordo com a
UI da solução
É comum… :
➔ Paths que representam a navegação de
menus/telas.
➔ Composição de atributos fortemente amarrados aos
campos e usabilidade das telas.
O que fazer quando?...
➔ A usabilidade das telas mudar.
➔ Haver versões com usabilidade diferente.
➔ Haver dispositivos com UI diferente.
➔ Um sistema terceiro precisar se integrar a API.

11. VISÃO RÁPIDA SOBRE DDD
2

12. ➔ Eric Evans
➔ Publicado em 2004.
➔ Possui 450+ páginas.
Design
Tático
Design
Estratégico
Modelagem
de domínio
do negócio
Padrões
de arquitetura
e de projeto

13. Tático:
Organização 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

14. Designed by pch.vector / Freepik
Domain Model
Ubiquitous
Language
Bounded
Context
Polissemia
… no Estratégico:

15. ➔ 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)
Domain Model
Ubiquitous
Language
Bounded
Context
Polissemia

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

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

18. 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
Domain Model
Ubiquitous
Language
Bounded
Context
Polissemia

19. Domain Model
Ubiquitous Language
+
Bounded Context
+
Polissemia

20. APLICANDO DDD
NA CONSTRUÇÃO DE APIs!
3

21. Domain Model
Ubiquitous
Language
Bounded
Context
Polissemia
“O coração do software…”
A solução deve possuir um modelo de domínio!!!
Uma boa API,
passa por um entendimento claro
do domínio, seus contextos, entidades, etc!

22. Domain Model
Ubiquitous
Language
Bounded
Context
Polissemia
Um modelo fictício de domínio de E-commerce!

23. Domain Model
Ubiquitous
Language
Bounded
Context
Polissemia
Contextos!
Em uma API Rest, os
contextos se tornam os paths
de primeiro nível:
○ <host>/contas/...
○ <host>/estoque/...
○ <host>/vendas/...
○ <host>/entregas/...
○ <host>/cobranca/...

24. Domain Model
Ubiquitous
Language
Bounded
Context
Polissemia
Características!
Entidades!
É a base para a composição dos contratos.
○ Entidades fortes, terão endpoints próprios.
○ Entidades fracas, podem ter endpoints ou estarem
encapsuladas junto a outras entidades.

25. Domain Model
Ubiquitous
Language
Bounded
Context
Polissemia
Nomenclaturas!
A linguagem universal deve ser aplicada a tudo:
○ Paths/Endpoints.
○ Atributos.
○ Parâmetros na url.
○ etc...

26. Domain Model
Ubiquitous
Language
Bounded
Context
Polissemia
Contratos respeitam os limites dos contextos!
○ Cada endpoints, possui Informação adequada
ao o contexto.
○ Chaves de associação entre entidades de
contextos diferentes são UUID, string
humanizadas, etc..

27. Domain Model
Ubiquitous
Language
Bounded
Context
Polissemia
Nomenclaturas não geram dúvidas!
○ Se um pedido tem endereço de entrega e de
cobrança, não pode haver apenas um atributo de
nome “endereço”.
○ Se o produto no contexto de vendas, é o que foi
vendido, pode-se chamá-lo de “produto vendido”.

28. DDD contribui
para uso da abordagem
de API First

29. Pense
no fluxo
Modelo do banco
de dados
API API First
UI Solução API API First
Domain
Model
API
UI Solução
Regras de
negócio
Modelo do
banco de
dados
Outros....
API First

30. DDD contribui
para construção de contratos
mais claro a todos
O que facilita inclusive o
processo de documentação

31. Uma API
representa a camada
Application
Na visão de camadas
propostas por DDD

32. Em um monólito, ou um
serviço específico,
Controllers, Serializers,
dentre outros, fazem
parte dessa camada.
Na visão de camadas
propostas por DDD
Deve-se evitar expor
diretamente o modelo de
dados concreto.

33. Na visão de camadas
propostas por DDD
Já as regras de negócio
fazem parte de Domain.
Uma API determina como
será o acesso ao Domain!
Aplicando DDD, é possível
que APIs de características
diferentes usem o mesmo
Domain

34. Na visão de camadas
propostas por DDD Em um arquitetura de
microservices.
Um API Gateway,
pode fazer o papel da
camada Application
para endpoints/serviços.

35. DDD na construção de APIs, também ajuda em:
➔ Contratos que foquem no negócio.
➔ Isolar os detalhes de implementação.
➔ Refatorações com menor impacto para
quem utiliza a API.
➔ Documentações mais simples, com a
mesma linguagem a todos.

36. Use o Domain Model
para modelar suas APIs!
Construa sua API como uma
camada Application.

37. DDD contribui para APIs
mais maduras e sustentáveis!
Obrigado!

38. Isaac Felisberto de Souza
Engenheiro de Software
isaacsouza@gmail.com
linkedin.com/in/isaacfsouza
Um guia para auxiliar o
Desenvolvimento de Software.
Através de conteúdo para desenvolvedores(as).
www.guia.dev
Guia Dev (linkedin.com/company/guiadev)
@guia_dev
Siga! e compartilhe ;-)