Gabriela Mattos, Consultora desenvolvedora, ThoughtWorks Brasil Carlos Maniero, Consultor de desenvolvimento, ThoughtWorks Brasil #XConfBR2019

1. Enriquecendo um
Modelo de Domínio
Anêmico
Gabriela Mattos & Maniero

2. Integrando
negócio com
desenvolvimento

3. Legado

4. Legado
● Projeto em micro serviços com equipe multidisciplinar;
● Regras de negócio espalhadas pelo sistema;
● Código duplicado e sem padronização;
● Documentação de funcionamento do software
descontinuada ou inexistente.
Contexto

5. Application Service
Legado Controller
Spring Data Repository “Domain” (JPA Entity)

6. "Quanto mais comportamento você
encontrar nos serviços, maior a
probabilidade de você estar roubando
os benefícios de um modelo de domínio
[...]"
Martin Fowler
Modelo Anêmico

7. "O principal problema desse anti
padrão é que ele é contraditório a ideia
básica de Orientação a Objetos, que é a
combinação de dados e processos. [...]"
Martin Fowler
Modelo Anêmico

8. Evolução da
Arquitetura

9. - Centralizar as regras de
negócio na camada de
domínio;
- Definição de uma
arquitetura comum para o
time com introdução de
uma nova funcionalidade;
Evolução da Arquitetura
Definição dos
Padrões
Aproximação
com especialistas
de domínio
- Pessoas desenvolvedoras
participando das reuniões
de definição de negócio;
- Linguagem ubíqua;
Regras de
negócio no
modelo

10. Application Service
Legado Controller
Spring Data Repository “Domain” (JPA Entity)

11. Application Service
Evolução da arquitetura Controller
Spring Data Repository Domain / (JPA Entity)

12. Modelo anêmico
public class UserService {
...
public void changeEmail(UserId userId, String newEmail) {
if (!isValidEmail(newEmail)) {
throw new IllegalArgumentException("Invalid Email");
}
User user = userRepository.findById(userId);
user.setEmail(newEmail);
userRepository.save(user);
}
}

13. Enriquecendo o Modelo
public class UserService {
...
public void changeEmail(UserId userId, String newEmail) {
User user = userRepository.findById(userId);
user.changeEmail(newEmail);
userRepository.save(user);
}
}

14. Enriquecendo o Modelo
public class User {
private String email;
...
public void changeEmail(String newEmail) {
if (!isValidEmail(newEmail)) {
throw new IllegalArgumentException("Invalid Email");
}
this.email = newEmail;
}
}

15. Primitive Obsession
public class Email {
private final String email;
private Email(String email) {
this.email = email;
}
public static Email of(String email) {
if (!isValidEmail(email)) {
throw new IllegalArgumentException("Invalid Email");
}
return new Email(email);
}
}

16. Primitive Obsession
public class User {
private Email email;
...
public void changeEmail(Email newEmail) {
this.email = newEmail;
}
}

17. Pronto, agora só
refatorar né?

18. Não!

19. Fase de Refatoração
● Definição da pirâmide de testes
para garantir a refatoração segura:
○ Importância de Testes de
Componente;
Application Service
Controller
Spring Data Repository
Domain / JPA Entity
Banco de dados em
memória
Teste de Componente
Testing Strategies in a Microservice Architecture - Toby Clemson
https://martinfowler.com/articles/microservice-testing/

20. Application Service
Evolução da arquitetura Controller
Spring Data Repository Domain / (JPA Entity)

21. Application Service
Refatoração Controller
Spring Data Repository Domain / (JPA Entity)

22. Fase de Refatoração
● Criação de uma documentação
comum para o time, possibilitando
que a arquitetura continue
evoluindo;

23. Archunit
@ArchTest
public static ArchRule
classes_named_controller_should_be_in_a_controller_package =
classes()
.that().haveSimpleNameContaining("Controller")
.should().resideInAPackage("..controller..");
Exemplo

24. Resumindo...
Arquitetura
documentado via
código com
ArchUnit
Cliente passou a
fazer questão de
ter pessoas
desenvolvedoras
durante a análise
de features
Onboarding
simplificado
Regras de negócio
centralizadas em
um único lugar
Codebase
padronizado
Produtividade

25. Gabriela Mattos - @gabrielavmattos
Carlos Maniero - @carlosmaniero
Obrigada!