Quem sabe alguma coisa costuma desenvolver em camadas, separar responsabilidades, normalizar o banco de dados, usar um ORM, entre outras práticas conhecidas e defendidas por boa parte da comunidade. Mas, por algum motivo, tais práticas, que deveriam estar tornando nosso trabalho mais simples, acabaram por torná-lo mais complexo. Nessa palestra veremos como a separação dos contextos de escrita (transacional) e leitura (consultas) podem deixar a arquitetura de uma aplicação cooperativa muito mais limpa, fácil de entender, escalável e robusta. Tudo isso, sem deixar pra trás um bom modelo rico de domínio.
41. duplicação de dados: ok Rollback!
denormalização: ok
dados na última camada: ok
atomicidade: desnecessária
consistência: em algum momento (não agora)
exceções a regra: menos prioritárias
fronteira transacional: menor que uma entidade
entidades de domínio na UI: malignas
camadas: menos...
cache: banco NOSQL sem segurança
banco relacional: provavelmente desnecessário em
diversos pontos
repositórios: não paginam nem ordenam
42.
43. Obrigado!
Giovanni Bassi
giggio@giggio.net
www.lambda3.com.br
blog.lambda3.com.br
44. Giovanni Bassi
giggio@giggio.net
www.lambda3.com.br
blog.lambda3.com.br