1. Introdução
Gostaria de falar sobre a experiência de aplicar práticas DDD a um projeto existente do Ruby on Rails. Inicialmente, tivemos um monólito que foi escrito por 10 anos. A principal dificuldade do projeto estava em processos bastante complexos e com alta conectividade. Conseguimos não apenas decompor o aplicativo em serviços separados, mas também aumentar significativamente a legibilidade do código, tornar transparentes os processos descritos.
A solução de problemas dentro do sistema tornou-se previsível, paramos de trabalhar com a caixa preta e, no final, o próprio sistema começou a nos fornecer soluções.
Para facilitar a percepção e a escrita, uma história sobre as abordagens utilizadas será apresentada na forma de uma série de artigos. Essa abordagem não é uma "bala de prata", portanto, gostaria de destacar antes de tudo o segmento de projetos em que essa solução pode se encaixar. Além disso, falarei com mais detalhes sobre a metodologia DDD e a implementação de microsserviços desse padrão, descreverei as combinações possíveis dos padrões aplicados, levando em consideração sua implementação e, por fim, darei um exemplo de uma implementação específica de um pequeno serviço.
Thesaurus
Thesaurus é um glossário de termos usados para descrever uma área de assunto específica.
Todas as definições que serão introduzidas abaixo estão corretas na estrutura deste artigo. Você pode aplicá-las à sua área de assunto se a descreverem bem o suficiente.
O problema resolvido no âmbito desta abordagem
A abordagem descrita abaixo possui uma especialização bastante estreita e, acima de tudo, visa solucionar um problema específico. No entanto, isso não exclui o possível interesse de especialistas em áreas afins. Então, temos a tarefa:
Você precisa reescrever e manter um projeto com lógica de negócios complexa escrita em Ruby on Rails, com recursos suficientes.
Vamos escrever esta tarefa com mais detalhes.
Por que é necessário reescrever o projeto?
Eu acho que todo desenvolvedor pode responder a essa pergunta. É mais difícil responder, para que essa resposta satisfaça as necessidades da sua empresa.
Usamos a definição de Negócio , como geralmente é aceita, embora invistamos neste termo um conceito mais amplo - uma empresa (algo empreendido por um grupo de pessoas), ocupação (ocupada).
Os negócios são o esforço de uma empresa de pessoas, expressa por meio de ações que visam obter benefícios para uma ampla gama de indivíduos.
Por exemplo:
- A empresa fabrica um produto para os consumidores ou presta um serviço.
- O laboratório está desenvolvendo um novo medicamento.
- A escola está envolvida em treinamento.
- O arquivo da cidade fornece informações aos cidadãos.
- Lera agrada seus fãs com uma excelente figura na rede social.
No caso em massa, um negócio é construído em torno da idéia de obter lucro satisfazendo as necessidades de seus clientes. Para que o lucro seja aumentado, é necessário satisfazer as necessidades reais do cliente com um grande número de soluções de alta qualidade. Essa ideia é descrita como o primeiro princípio do manifesto Agile, embora não seja nova. O fato de que as necessidades subjacentes à nossa sociedade tem sido discutido por muitos filósofos. Por exemplo, Platão tentou simplificar as necessidades, criar sua classificação. É ele quem nomeia as principais formas de necessidades econômicas: comida, roupas, moradia. "O desafio dos negócios" é satisfazer as necessidades. E as soluções aplicadas devem aumentar a competitividade dos negócios.
Competitividade - A vantagem de um negócio em detrimento de outro.
O manifesto Agile também nos dá uma dica de que a flexibilidade do projeto é aprimorada por meio de sua excelência técnica e qualidade do design.
Considere a cadeia de valores dos fornecedores no exemplo de um "projeto web típico"
- t 0 - tivemos uma ideia.
- t 1 nós implementamos o MVP . Aqui discutimos um pouco:
Produto mínimo viável do MVP - um produto que possui as funções mínimas, mas suficientes para satisfazer os primeiros consumidores. A principal tarefa é obter feedback para a formação de hipóteses para o desenvolvimento posterior do produto.
O termo foi popularizado por Steve Blank e Eric Rees. O MVP é uma ferramenta eficaz para testar sua ideia de negócio e responder à pergunta principal "Decole - não decole?"
- t 2 - Voltar para a programação. A ideia foi bem-sucedida, recebemos feedback positivo e fomos capazes de satisfazer um grande número de necessidades dos clientes no horário indicado.
- t 3 - Desta vez, a satisfação chegou em menor grau. Aumentamos a equipe.
- t 4 - Entregamos ainda menos valores.
- t 5 - Se não iniciamos a refatoração, nesse momento o negócio deixa de ser competitivo.
Por que isso está acontecendo? Com o tempo, nosso projeto acumula um alto nível de entropia devido à sua alta conectividade. Suponha que tenhamos uma "Empresa Típica" que consiste em um departamento de marketing, análise, logística, vendas e gerenciamento. No momento, o projeto é o seguinte:
Gostaria de fazer uma reserva imediata de que a conectividade nem sempre é a causa da entropia, mas surge se um sistema com um grande número de processos de negócios complexos for implementado.
A entropia no código sempre ocorrerá se os processos de negócios na empresa não forem formados corretamente. O que pode ser característico das duas empresas jovens, que estão no início de seu caminho, também é característico das grandes empresas, onde é impossível sistematizar tudo de uma só vez. Este é um processo natural e não devemos ficar no caminho dele, mas aceitá-lo e usá-lo. Vamos voltar ao primeiro gráfico e olhar para ele do outro lado:
A integral (a área abaixo da linha) será o dinheiro ganho. O aplicativo real (aplicativo Real) ganhará mais do que o "ideal" (aplicativo Academin), pelo menos até o início da entropia - t 4 . Parece bom, e é isso que você precisa fazer.
Mas o que fazer no futuro? Repetir a refatoração para o infinito é impossível. Em algum momento, o volume da base de código atingirá um nível tal que será difícil reescrever “tudo de uma vez”. E mais cedo ou mais tarde será necessário dividir o projeto em componentes separados:
Uma abordagem para implementar sistemas complexos é o DDD:
O DDD (Domain-driven Design) é uma abordagem para o desenvolvimento de software para a satisfação complexa de necessidades, vinculando fortemente a implementação aos principais modelos de negócios que estão em processo de desenvolvimento constante.
DDD é uma série de práticas e definições que serão descritas em mais detalhes no próximo artigo. O padrão central dessa abordagem é o contexto limitado , cuja essência é que cada área de assunto consiste em vários conjuntos de modelos que não devem se comunicar com o mundo exterior, bem como modelos usados no mundo exterior em conjunto com outros contextos limitados. Cada contexto limitado possui uma interface claramente definida, onde decide quais modelos usar em conjunto com outros contextos.
Esse padrão pode ser implementado por meio de um espaço para nome (espaço para nome) e por microsserviços. Usaremos essas duas implementações, dependendo do nível de conectividade do contexto. O que acaba levando à criação de um aplicativo segmentado e decomposto.
É improvável que os gráficos acima reflitam a imagem real, mas permitem comparar diferentes abordagens entre si.
Apoio ao projeto
Como parte do suporte ao projeto, várias coisas precisam ser fornecidas.
- Entrega de valor : Scrum, Agile, atendimento ao cliente, Entrega contínua.
- Redução de entropia : DDD, Micro-serviço como uma das maneiras de separar contextos, documentação.
- Qualidade do código : Design no nível do domínio, TDD, BDD.
- Qualidade do produto : Teste manual e automatizado, rastreamento de bugs, registro em log.
- Disponibilidade do produto : Sistemas de duplicação.
- Velocidade do produto : escala horizontal.
- Retenção da equipe de desenvolvimento : sistema de motivação, abertura, honestidade.
Como você pode ver, a manutenção de um sistema complexo requer uma grande quantidade de recursos. Primeiro de tudo, pessoal altamente qualificado. Antes de usar essa ou aquela tecnologia, pense se você tem a oportunidade de fornecer seu suporte no nível certo.
Deve-se lembrar que o limite para a entrada em um sistema complexo é bastante alto, por isso é importante fornecer treinamento para o pessoal. Além disso, se queremos trabalhar sem falhas, não devemos ter especialistas "insubstituíveis" e, portanto, é necessário garantir a total permutabilidade de todas as funções. Se você tiver um 'especialista em entrega contínua' voando para fora da equipe, precisará substituí-lo. Se a substituição não puder ser fornecida, não vale a pena introduzir a pilha de tecnologia na "produção" sem fornecer suporte suficiente.
Não se trata de especialistas no mesmo nível. Você deve ter um DevOps líder e um certo desenvolvedor para quem este tópico é interessante (o chamado "multiclasse"). Para ele, como para o "segundo violino", é importante fornecer um entendimento de onde e como encontrar ferramentas para resolver o problema. Para isso, pelo menos um quarto do volume total de tarefas recebidas relacionadas à nova especialidade deve ser distribuído a ela. Essas tarefas serão realizadas lentamente, os custos aumentarão, mas no futuro isso evitará o risco de interrupção no fornecimento de valores devido à falta de pessoal.
Tais coisas estão descritas nos requisitos do Scrum, eu não gostaria de me debruçar sobre elas. A única coisa que gostaria de chamar sua atenção, para o que você precisa estar preparado, são os grandes custos que serão gastos no suporte ao seu projeto. Se sua empresa não está pronta para isso e você começou a usar muitas ferramentas caras, você estragará a empresa.
Brevemente
- Se você precisar implementar o MVP , comece com Ruby On Rails.
- Se o MVP decolou e a idéia se tornou realidade, faça a primeira refatoração, “alivie” seus modelos com a ajuda de serviços, decoradores, remova a camada de validação e banco de dados dos modelos em preocupações separadas. Escreva testes, documentação.
- Se você não possui um projeto tão complexo e pode remover a entropia otimizando modelos - faça-o.
- Se você tem um projeto lógico e legível e precisa aumentar sua produtividade, enquanto ele pode ser dividido, digamos, pelos usuários, use o dimensionamento. Mas não tente dividir o projeto em serviços por domínio.
- Se você tem um negócio "complexo" e está procurando uma ferramenta para entrar on-line (por que ainda não o fez ?!) - considere também "Soluções empresariais" prontas, por exemplo, em java ou .NET. As práticas descritas se originaram em tais soluções e eles têm um rico conjunto de ferramentas prontas para uso, que economizarão seu dinheiro.
- Se o seu projeto estiver em ruby, você tem uma equipe de programadores em ruby, o projeto contém lógica de negócios complexa, está se preparando para o carregamento ou já está carregado e a entropia cresceu tanto que é muito, muito difícil reescrever, então você deve considerar usar a abordagem DDD e Microservices.
Na próxima vez, gostaria de considerar com mais detalhes a essência da abordagem DDD e sua implementação em microsserviços.
Fontes de inspiração: