Nesta palestra vamos explorar como design e técnicas modernas da engenharia de software, especialmente Bounded Context e CQRS, podem ser usadas com sucesso na manutenção evolutiva de sistemas legados.​ Com base em experiências reais, veremos como aplicar esses conceitos em sistemas críticos, preparando-os para uma distribuição mais segura e eficiente. Também será apresentado como elevar as técnicas para um novo patamar de qualidade, de forma alinhada ao interesses da organização.​ Apresentaremos as estratégias usadas para evolução de aplicações .NET legadas de sistemas públicos de grande porte, e veremos como um sistema, antes pouco escalável e de alto custo, vem sendo portado para um cenário passível de testes e com grande escalabilidade e capacidade de distribuição.

1. Bounded Context e CQRS
Evolução de aplicações .NET legadas

2. ARQUITETO DE SOFTWARE
BACHAREL EM ANÁLISE DE SISTEMAS
MESTRANDO NO CURSO DE ENG. DE SOFTWARE PELA UFRN
Há 15 anos se dedicando a construção de sistemas corporativos.
@yanjustino
facebook/yanjustino
youtube/academia .net para zumbis
youtube/aspnet cast

3. 2 0 A n o s d e A T I V I D A D E
e m p r e s a d e t e c n o l o g i a
f o c a d a e m p e s s o a s
d i v e r s o s s e r v i ç o s
r e a l i z a d o s
4 2 0 i v i a n o s e m a ç ã o !

5. Secretaria de estado da tributação do RN
SET
Cidadão
Auditores
Gestão
Contribuinte
A Secretaria de Estado da Tributação do Rio Grande do Norte
- SET/RN - é uma administraçãotributária cuja finalidade é a
arrecadaçãode tributos estaduais e a fiscalização das
operações que os geram.
Para que a SET/RN possa atender as necessidades
relacionadas às atividades fins, em cumprimento as suas
obrigações, sefaz necessário manter funcionando cerca
de 70 (setenta) sistemas e subsistemas que abrangem
a área tributária envolvendo os impostos de sua
competência, assim como as ofertas de serviços aos
contribuintes e cidadãosatravés da internet.

7. evolução de sistemas : Adaptação

8. evolução de sistemas: especiação

9. evolução de sistemas : extinção

10. Lugar comum do código LEGADO
Modelo implícito estabelecido
Tipicamente não possui uma API pública programável
Escrito pra funcionar, nem sempre para o reuso
Escrito anos atrás com alguma prática agora obsoleta

11. Ferramenta da evolução de sistemas LEGADOs
arquitetura de software
Conjunto de estruturas necessárias para analisar um dado
sistema, composta por elementos de software, relações entre eles,
e propriedades de ambos
ponte entre os objetivos de negocio do sistema e o sistema resultante final.
as decisões de projeto realizadas no desenvolvimento de um sistema para atender
atributos de qualidade.

12. Evoluindo sistemas LEGADOs

13. evoluindo sistemas LEGADOs

14. Evoluindo sistemas LEGADOs

15. DOMAIN-DRIVEN DESIGN
O VALOR AGREGADO PELO DDD
Domain-Driven Design é uma abordagem
particular sobre design
e desenvolvimento de software!
DDD é sobre “mastigar” conhecimento de um dado
domínio de negócio e produção de um modelo de
software que o espelhe.

16. DOMAIN-DRIVEN DESIGN
Os dois grandes erros
Adotar Domain-Driven Design só
porque isso lhe
soa legal
Ou simplesmente ignorá-lo por acreditar que seu
sistema é um pouco mais complexo que
um simples CRUD

17. DOMAIN-DRIVEN DESIGN
em duas partes distintas
Domain-Driven Design
Visão analítica
Domain-Driven Design
Visão estratégica

18. DOMAIN-DRIVEN DESIGN
visão analítica

19. DOMAIN-DRIVEN DESIGN
visão analítica
Que práticas e técnicas de processo você e sua
empresa adota para garantir uma boa
arquitetura?

20. DOMAIN-DRIVEN DESIGN
visão analítica

21. DOMAIN-DRIVEN DESIGN
ubiquitous language

22. DOMAIN-DRIVEN DESIGN
ubiquitous language

23. DOMAIN-DRIVEN DESIGN
ubiquitous language

24. DOMAIN-DRIVEN DESIGN
ubiquitous language
DDD é sobre a
Redução de complexidade
No software
Eric Evans
Arquitetura é sobre intenção
Robert C. Martin

25. DOMAIN-DRIVEN DESIGN
visão estratégica

26. DOMAIN-DRIVEN DESIGN
visão estratégica
Que práticas e técnicas de produto você e sua
empresa adota para garantir uma boa
arquitetura?

27. DOMAIN-DRIVEN DESIGN
visão estratégica

28. DOMAIN-DRIVEN DESIGN
bounded context

29. DOMAIN-DRIVEN DESIGN
bounded context: UMA VISÃO CLÁSSICA

30. DOMAIN-DRIVEN DESIGN
bounded context: UMA VISÃO CLÁSSICA

31. DOMAIN-DRIVEN DESIGN
bounded context: UMA VISÃO CLÁSSICA
uma utopia maravilhosa

32. DOMAIN-DRIVEN DESIGN
bounded context: UMA VISÃO CLÁSSICA
uma ilusão de ótica

33. DOMAIN-DRIVEN DESIGN
bounded context: UMA VISÃO CLÁSSICA

34. DOMAIN-DRIVEN DESIGN
bounded context: UMA VISÃO CLÁSSICA

35. DOMAIN-DRIVEN DESIGN
bounded context: UMA VISÃO MODERNA

36. DOMAIN-DRIVEN DESIGN
bounded context: UMA VISÃO MODERNA

37. DOMAIN-DRIVEN DESIGN
dividindo bounded context

38. DOMAIN-DRIVEN DESIGN
dividindo bounded context

39. DOMAIN-DRIVEN DESIGN
dividindo bounded context
CADASTROS FISCAIS
Contexto para cadastro dos contribuintes
do Rio Grande do Norte
parcelamentos
Contexto para parcelamento dos débitos dos
contribuintes do Rio Grande do Norte
segurança
Contexto suporte para controlar todos os
Acessos de contribuintes e cidadão do RN
* A RedeSIM (Rede Nacional para a Simplificação do
Registro e da Legalização de Empresas e Negócios) foi
criada pela lei nº 11.598 de 2007 parapermitir que o
cidadão abra ou regularize suapessoajurídica de forma
simplificada e sem burocracia

40. DOMAIN-DRIVEN DESIGN
bounded context: EXPLORANDO ARQUITETURAS

41. DOMAIN-DRIVEN DESIGN
bounded context: EXPLORANDO ARQUITETURAS
Query
Componente de pesquisa
De cadastros fiscais
command
Componente de persitência
De cadastros fiscais
Arquit. hexagonal
Componente de segurança
Da Sec. Tributação

42. DOMAIN-DRIVEN DESIGN
bounded context : extrAINdo api
CADASTROS FISCAIS
Contexto para cadastro dos contribuintes
do Rio Grande do Norte

43. DOMAIN-DRIVEN DESIGN
bounded context: EVOLUINDO LEGADO

44. DOMAIN-DRIVEN DESIGN
bounded context: COMUNICAÇÃO

45. DOMAIN-DRIVEN DESIGN
bounded context: COMUNICAÇÃO

46. DOMAIN-DRIVEN DESIGN
bounded context: COMUNICAÇÃO
Shared kernel/
Values objects Share submodel
Anti-corruption
layer

47. cqrs
command/query responsibility segregation

48. limitações DA MODELAGEM DE DOMÍNIO

49. Da MODELAGEM DE DOMÍNIO para cqrs
Query
command

50. Cqrs não é uma arquitetura top-level
CQRS é simplesmente um padrão que lhe
orienta na arquitetura de um contexto
limitado de um sistema de grande escala
Uma análise baseada em uma linguagem ubíquae que
tem como objetivo identificar contextos limitados
continuaa ser um passo preliminar recomendado
contudo

51. Alguns benefícios do cQRS
Simplificação do design
Potencial para uma performance e escalabilidade melhorada
Efeitos colaterais minimizado

52. Amadurecendo aplicação com cqrs

53. Antes de software poder ser reutilizável
ele primeiro tem de ser utilizável

54. REFERÊNCIAS : livros
Implementing
Domain-Driven Design
Vaughn Vernon
ISBN-13: 860-1404568893
ISBN-10: 0321834577
Domain-Driven Design: Tackling
Complexity in the Heart of Software
Eric Evans
ISBN-13: 978-0321125217
ISBN-10: 0321125215
Patterns, Principles, and Practices
of Domain-Driven Design
Scott Millett
ISBN-13: 978-1118714706
ISBN-10: 1118714709
Microsoft .NET - Architecting
Applications for the Enterprise
Dino Esposito
ISBN-13: 978-0735685352
ISBN-10: 0735685355

55. REFERÊNCIAS acadêmicas
KULESZA, U
Arquitetura de Software: Mestrado Profissional em Engenharia de Software; 127 slides
Bolsista de Produtividade em Pesquisa 2 - CA CC | Orientador de Mestrado | Orientador de Doutorado
Doutorado em Informática pela Pontifícia Universidade Católica do Rio de Janeiro, Brasil(2007)
Professor Adjunto I da Universidade Federal do Rio Grande do Norte , Brasil
http://buscatextual.cnpq.br/buscatextual/visualizacv.jsp?id=K4769232P2