TDC2016SP - Trilha Microservices
•
4 gostaram•664 visualizações
1) O documento descreve como o Domain Driven Design (DDD) e o Strategic Design estão ajudando a modernizar um legado de sistema para uma empresa de medicina do trabalho. 2) O sistema começou simples mas cresceu de forma desorganizada ao longo de 5 anos, levando a muitos bugs. O DDD está sendo usado para dividir o domínio em Bounded Contexts e melhorar a arquitetura. 3) A estratégia envolve isolar funcionalidades em módulos/libs, definir interfaces para comunicação com o legado, e
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (19)
Destaque
Destaque (18)
Semelhante a TDC2016SP - Trilha Microservices
Semelhante a TDC2016SP - Trilha Microservices (20)
Mais de tdc-globalcode
Mais de tdc-globalcode (20)
Último
Último (20)
TDC2016SP - Trilha Microservices
- 1. Globalcode – Open4education Como Domain Driven Design e Strategic Design estão nos ajudando a modernizar um legado Luiz Costa gutomcosta@gmail.com / @gutomcosta
- 3. Contexto
- 4. Sistema para um empresa de medicina do trabalho realizar atendimentos de medicina ocupacional por todo o Brasil e fornecer uma análise inteligente sobre o perfil dos colaboradores de uma empresa.
- 5. Mas como todo projeto, no início, tudo é muito simples…
- 6. Era só uma "Fila"…
- 7. E hoje em dia até envia email
- 8. + de 5 anos de projeto + 10 desenvolvedores passaram no time Python e Django 1.4 < 50% test coverage 14 servidores = 1 para cada clínica aberta
- 9. Depois de algum tempo em produção….
- 10. •bugs e mais bugs •altera uma parte, quebra outra •bug em uma parte, sistema fora do ar •demora nas entregas •pressão do cliente para entregar mais os problemas começaram…
- 11. Aplicação Web tradicional algo assim
- 13. Isso não é uma service layer, é algo parecido com um TransactionScript models sendo um espelho do banco de dados
- 15. WTF?
- 16. • lógica de domínio espalhada em Controllers, Models e Services • models espelhando exatamente o modelo de dados • foco no framework e não no domínio do problema
- 17. Como melhorar este projeto?
- 20. the blue and the red book
- 22. Strategic Design …modeling and design decisions that apply to large parts of the system. Such decisions affect the entire project and have to be decided at team level.
- 23. Strategic Design …modeling and design decisions that apply to large parts of the system. Such decisions affect the entire project and have to be decided at team level.
- 24. BOUNDED CONTEXT CONTEXT MAP ANTI-CURRUPTION LAYER SHARED KERNEL OPEN HOST SERVICE PUBLISHED LANGUAGE Existe vida além parte 1 do livro azul
- 26. Not all of a large system will be well designed. Eric Evans on Strategic Design presentations https://www.infoq.com/presentations/strategic-design-evans
- 27. Total unification of the domain model for a large system will not feasible or cost-effective DDD Book on 332
- 28. Como dividir o domínio?
- 29. Bounded Context
- 30. 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 book - p. 336
- 31. 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 book - p. 336
- 32. 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 book - p. 336
- 35. Contexto A Contexto B Contexto C
- 37. Mesma entidade modelada em vários contextos
- 38. Paciente Atendimento + qual nome, nascimento…? + qual dia do agendamento? + qual empresa pertence? + qual é a função que exerce? Paciente Gestor de Periódicos + qual é o proximo exame? + quantos dias faltam para vencer? Paciente Financeiro + qual custo dos exames feitos? + alguma condição de desconto? É responsabilidade de cada contexto modelar os dados da melhor maneira, de acordo com a as suas responsabilidades.
- 39. Como implementamos? E o que micro-serviços tem com isso?
- 40. Anatomia de um Bounded Context
- 41. Bounded Context Domain LayerApplication Layer use case use case use case Repository Entity Value Object Infrastructure Layer Entity DAO Logger Service Module
- 43. Implementação de um Caso de Uso o fluxo de execução é simples e limpo todas as dependências são declaradas o construtor
- 44. Foco total no Domain Model Domain Model != Model
- 45. Todas as regras de negócio são programadas aqui. Normalmente são objetos python puros, sem relação com persistência ou infra-estrutura Expostas através de casos de uso
- 46. Nossa estratégia para dominar o legado
- 48. …An alternative route is to gradually create a new system around the edges of the old, letting it grow slowly over several years until the old system is strangled. www.martinfowler.com/bliki/StranglerApplication.html
- 50. Identificar e evidenciar as fronteiras através de Libs
- 51. Don’t distribute your objects. http://martinfowler.com/books/eaa.html
- 52. O isolamento do legado se dá através de indireções nos objetos da fronteira. Nesta visão de alto nível, é possível ver como uma funcionalidade é anexada ao código do Legado. A ideia básica é o novo módulo definir um conjunto de interfaces/conectores para troca de informações. Em uma abordagem de lib, estes conectores se materializam em um conjunto de interfaces que devem ser implementadas pela Lib. fronteira do sistema Inicialmente, os novos contextos são projetos novos, que devem funcionar como Libs. Deve ser possível extrair a lib para rodar em um runtime diferente sem muitas dificuldades.
- 53. O que fazer quando é preciso usar dados do legado no módulo novo?
- 55. Um módulo ou contexto novo define um conjunto de interfaces que serão implementadas diretamente no legado. interfaces definidas pelo módulo o contexto “Atendimento” depende de dados que estão definidos no legado. Neste caso, o módulo que necessita dos dados, define o contrato de comunicação e o legado implementa este contrato, reutilizando objetos existentes ou escrevendo código novo. O importante é que a definição das interfaces é feita de acordo com as intenções do módulo novo e não com os detalhes do código legado
- 56. O que fazer se o legado precisar de dados do módulo novo?
- 58. A solução mais comum para este caso é o uso de eventos. O módulo publica um conjunto de eventos e o legado assina estes eventos. no lado do Legado, dentro da ACL, são definido casos de uso que serão estimulados pelos handlers de tratamento dos eventos. o caso de uso PatientCheckin, durante sua execução, publica o eventos “PatientCheckedIn”. Este evento contem os dados necessários para comunicação com o legado, normalmente serializado em um JSON ou usando um Hash.
- 59. Como juntar isso tudo e extrair um micro-serviço?
- 60. Este exemplo, mostra com a arquitetura permite separar os componentes em runtimes diferentes, inclusive com banco de dados próprio. aqui, a lib foi incluída em uma aplicação web e isolada através de uma Anti-Corruption Layer (ACL). A vantagem de se usar uma ACL é o isolamento do código já criado. As alterações necessárias na lib são muito pequenas e a própria ACL pode tratar os problemas de comunicação com o legado, logar, lançar exceções, etc. do lado do legado, a própria api já funciona como uma ACL. Normalmente esta api vai ser implementada com Http puro, usando formatos simples como JSON para troca de dados
- 61. Chamadas diretas na api do legado ou através de uma arquitetura event-driven. Broker de mensagens, por exemplo: JMS, ActiveMQ, RabbitMQ, etc conjunto de EventHandlers interessados nas mensagens
- 63. 1 - Reúna o time com algum especialista do domínio e faça um desenho inicial dos Bounded Contexts
- 64. 2 - Evidencie as fronteiras inicialmente através módulos no código fonte
- 65. 3 - Extraia os módulos que compõem um Bounded Context para uma lib
- 66. 4 - Se necessário, exponha a mesma lib como micro- serviço
- 67. Obrigado!