Hanami em production: 2 anos — Parte 1
Por Hélio Costa. 2017
Começamos os protótipos quando o projeto se chamava Lotus-rb. Lá em Outubro de 2015, a ideia era validar se quem-sabe-talvez, Lotus-rb pudesse ser uma alternativa real ao então nosso principal projeto em Ruby on Rails.
Le Prototype
Como todo mundo, fizemos um ToDo app para validar. Experimentamos o model
e o validation
, pois já tinhamos em mente separar o Input e sua validação do domain-model. Queríamos isolar ao máximo nosso modelo, muito nos moldes do Clean Architecture do Uncle Bob / Ports & Adapters do Alistair Cockburn. A ideia era muito experimental e confiávamos na robustez por baixo do Lotus-rb: Sequel. O Sequel, diferente do Lotus-rb, era estável e bem conhecido no ecosistema Ruby. Pensavamos: se o Lotus cair, ficamos com uma camada de abstração do Sequel e migramos isso depois facilmente para um Sequel-model da vida.
Meses depois, nosso projeto Core foi ao ar, substituindo partes do nosso agora legado Rails app. Já com o nome de Hanami e algumas atualizações feitas, tudo ia bem, para nossas necessidades da época. O projeto é uma API com interface JSON API, com foco em separação em camadas, Domain-Driven Design e arquitetura Hexagonal.
Le Presentation Layer
Ao longo deste processo, testamos outras gems como Roar (do Apotonick), Representable, JSONApi-Serializers e Grape. Como dá para ver, nossa Presentation Layer demorou a ficar do jeito que imaginávamos. É a vida. Ela é assim e boas. Fizemos uma versão básica da Presentation Layer e depois de tudo pronto e algumas utilizações, repensamos como poderíamos deixa-la de facto isolada.
Nossa principal questão foi como lidar com a transformação do Domain-Model para entregar algo “burro” ao nosso Presentation Layer. Outro ponto era o ponto inverso: como transformar o payload do Request em um objeto de transferência para ser encaminhado a Application Layer — a.k.a Use Cases. Idas e vindas, começamos com um modesto fluxo endpoint -> form object -> application service -> domain model
até chegarmos em algo com responsabilidades melhor definidas:
# Presentation Layer
endpoint
form object
optional triggers: Validation & Relationships (JSON API specifics)# Application Layer
use case
orchestrates to:
domain model or # domain model
infrastructure service # application boundaries
Antes de ir para production
, tivemos que refazer nossa ideia de Form Object, pois o modelo inicial, não continha uma forma plugável para adicionar Input Validation (Hanami Validation implementation). Era muito manual e repetitivo. Natural neste ponto do processo, pois tivemos que distribuir nosso foco de atenção em toda a arquitetura inicial.
Com o novo modelo, o FormObject delega para a validação usando Template Method, caso o tal FormObject dê include na Validation
que deseja utilizar naquele endpoint. Isso deixou muito transparente como validamos as coisas, pois no final, tínhamos uma delegação muito boa entre as classes FormObject
e Validation
.
Como spoiler, se liga um exemplo de FormObject:
Le Aplication Layer
Nosso próximo desafio foi mudar nossos Application Services. Trocamos o nome de Application Service
para Use Case
. Isso por si, já deixou objetivo o que era esperado destas classes bem como da Application Layer inteira.
Use Case bem descrito passou a ser prioridade em meados de maio/2016, quando percebemos que a Application Layer precisava sair de um mero detalhe, para assumir a responsabilidade de orquestrar como nossos casos de uso eram controlados. Nosso objetivo era simples: conseguir com um tree boundaries/use_cases
entender o que o software é capaz de fazer. Todo aquele papo de sempre sobre nomenclatura de classes, etc., mas ir além e pensar nos contextos (modules/namespaces) que os Use Cases fazem parte.
Como todo o projeto, nossos Use Cases são stateless e recebem suas dependências através de injeção de dependência no initialize
. Podem controlar db transactions e em alguns casos, disparar Domain Events, como sugerido pelo Vaugh Verner em seu livro Implementing Domain-Driven Design.
No próximo post, vou descrever como foi lidar com a evolução de nosso domain-model e como conseguimos lidar com isso ao longo destes dois anos.
Interessado em trabalhar conosco? Estamos sempre buscando pessoas apaixonadas por tecnologia para se juntar à nossa tripulação! Você pode conferir todas nossas vagas aqui.