Palavras de Luiz Costa, nosso CTO!


Luiz Costa, nosso CTO, conta em primeira mão o tema da sua palestra no TDC São Paulo.

“No mês que vem vou estar no TDC São Paulo, na trilha de Ruby, contando um pouco como organizamos nossas aplicações Ruby on Rails, aqui na Beep Saúde. Rails tem um papel muito importante na nossa plataforma atualmente. Todas as aplicações internas, alguns microsserviços e a nossa principal API são escritos com o framework.

Somos uma Startup, portanto, é comum que façamos muitos experimentos e alterações em funcionalidades que já estão disponíveis para os usuários, ou até mesmo nos sistemas internos. Neste caso, é importante poder adiar a escolha de um componente que será usado em nossas aplicações até o último momento.

Para suportar esse tipo de ambiente, a nossa equipe de tecnologia segue um princípio fundamental: “Nossa arquitetura deve permitir que se atrase decisões”. Atrasar decisões, neste caso, é poder adiar a escolha de um componente que será usado em nossas aplicações até o último momento responsável, como sugerem Mary e Tom Poppendieck, no livro “Lean Software Development: An Agile Toolkit”. Por que eu preciso decidir no início da implementação de uma funcionalidade se vamos usar um broker de mensagens ou conectar direto com uma API para integrar dois sistemas?

Para que isso seja possível, nossas aplicações são totalmente focadas em modelar o domínio de maneira explícita. Ou seja, damos uma atenção bem grande em entender como o domínio do problema pode ser representado em código. Para isso, tiramos proveito de técnicas como Domain Driven Design.

Como disse antes, usamos Rails na maioria dos nossos projetos. Como podemos isolar o nosso domain model do Rails e, por que isso pode ser uma vantagem é o que vamos apresentar na palestra Hexagonal Rails no TDC.

Hexagonal Architecture ou Port and Adapters é um padrão arquitetural que sugere que é boa ideia manter um nível de isolamento do seu domínio (core) de outras camadas mais externas da sua aplicação (UI, banco de dados, frameworks, etc). A principal razão deste isolamento é ajudar a separar elementos que mudam por diferentes razões. O seu domain model muda quando o seu negócio muda. Um desconto específico para um tipo de cliente não deveria ser influenciado por uma mudança no seu framework. Por que deveríamos adaptar o módulo de agendamento quando alguma parte do framework muda? Ou por que uma atualização do framework deveria introduzir um bug no módulo de pagamento? Com o domínio isolado, esse tipo de problema tende a acontecer muito menos.

Outra vantagem de ter o domínio isolado é a possibilidade de conectar diferentes adaptadores para a mesma lógica de domínio. Por exemplo, é possível ter a mesma funcionalidade exposta de diferentes maneiras: uma API para Web, um handler para um evento ou uma aplicação console que faz atualizações em batch.

Nesta apresentação, vamos destacar como é possível implementar e mostrar código real do uso deste padrão. Ficou curioso? Se estiver pelo TDC, dá uma uma passada na trilha de Ruby. Te esperamos lá!”

Referências:

Atrasar decisões

Último momento responsável

Domain Driven Design

Hexagonal Architecture ou Port and Adapters

Previous Precisamos falar sobre o Sarampo
Next Sarampo: Vacina de Reforço e Bloqueio Vacinal