Get best of the week

O que posso aprender sobre o Domain Driven Design em 10 minutos?

Eles dizem que você pode olhar incessantemente para o fogo, observar como os outros funcionam e também estudar DDD (Domain Driven Design, design específico do domínio). Mas se você tiver apenas 10 minutos, poderá ler este artigo e ir até o topo e, com uma aparência inteligente, acenar com a cabeça durante uma pequena conversa.

Torcemos e revisamos o DDD de diferentes ângulos, juntamente com Andrei Ratushny, diretor técnico da Ugra Internet Solutions.





Sobre a empresa: A Ugra Internet Solutions é uma empresa que atua na automação de processos de negócios nos setores comercial e público. Localizado na cidade de Khanty-Mansiysk. Em desenvolvimento 12 pessoas.

1. O que é DDD, pode ser explicado até para uma criança (ou profissional de marketing)


O DDD é uma abordagem que visa estudar a área de assunto da empresa como um todo ou qualquer processo de negócios individual. Essa é uma excelente abordagem para projetos em que a complexidade (complexidade) da lógica de negócios é bastante grande. Seu uso foi projetado para reduzir ao máximo essa complexidade.

Fora da abordagem do DDD, quando um programador escreve código, ele presta mais atenção às tecnologias e infraestrutura, por exemplo, como enviar uma mensagem, como recebê-la, codificá-la, salvá-la em um banco de dados, qual banco de dados.

A abordagem DDD sugere que tudo isso, é claro, é importante, mas secundário. Os negócios são mais importantes e devem vir em primeiro lugar. E para fazer tudo isso funcionar em conjunto, o DDD nos ensina (desenvolvedores) a falar o mesmo idioma com os negócios. Não em uma linguagem de programação, mas em uma linguagem de negócios. Isso é chamado na linguagem Ubíqua DDD.

2. Chip DDD - Contexto Limitado


Contexto limitado é uma ferramenta DDD chave; é um limite explícito no qual existe um modelo de domínio. Ele mapeia um único idioma em um modelo de software. É com base nos contextos que você pode dividir o código em módulos / pacotes / componentes, para que as alterações em cada um deles tenham um efeito mínimo (ou zero) nos outros.

Para os desenvolvedores, essa abordagem permite que você faça alterações no código sem medo de que em algum lugar de outro lugar algo ocorra (por exemplo, altere algo no checkout e não se preocupe com a possibilidade de que algo caia dos correios por causa disso).

Para os líderes de equipe, essa abordagem nos permite paralelizar significativamente o trabalho de equipes, o que pode acelerar significativamente o trabalho no projeto.

Além de um contexto limitado, existem todos os tipos de mapas de contexto, um único idioma, relações entre contextos, mapas de tradução ... uhhh! Você não conta sobre isso em 10 minutos, mas pode ler o livro "verde".

3. Livros gerais sobre DDD: vermelho, azul e verde


DDD é uma abordagem bastante antiga. Seu uso parece razoável e bastante justificado, mas, por alguma razão, ainda não é generalizado, pouco se fala sobre isso nas conferências. O que há de errado com este DDD?

Supõe-se que o principal problema seja a falta de materiais de treinamento. Toda a teoria é descrita em vários livros: vermelho , azul e verde . Eles dizem que há “outro livro vermelho” , mas poucos o viram ainda :) Os

livros vermelho e azul são tão difíceis de perceber que em algum lugar no meio eu quero jogar o livro pela janela gritando: “Chega dessa merda de mim, veja esse DDD incompreensível! Vou fazer o que puder. " E isso é apenas sobre teoria, com materiais sobre a prática é ainda mais complicado.

Portanto, se você ainda decidir começar a estudar literatura sobre DDD, é melhor começar com um livro verde. Nele, Vaughn Vernon percorre o topo da abordagem e, com exemplos simples, mostra suas vantagens. Eles dizem que a tradução acabou sendo duvidosa, por isso é melhor ler no original.

4. Como entender que é hora de aplicar DDD


Conte o número de casos de uso para o seu sistema. Se eles estiverem na região de 10 a 15, a lógica de negócios não é tão complicada e você não pode usar o vapor, não use DDD.

Se você possui de 30 a 50 ou mais casos de UX e eles se sobrepõem muito, faz sentido pensar em usar o DDD pelo menos em alguma parte do sistema.

5. Como implementar DDD na empresa de baixo para cima


Imagine que você é um desenvolvedor que gosta de DDD e acha que em sua empresa essa abordagem pode ser aplicada para fazer as pessoas felizes.

É difícil iniciar uma introdução guerrilheira ao DDD. Primeiro, o conhecimento pode não ser suficiente para iniciar o processo. Em segundo lugar, os caras da sua equipe podem pensar que você está fazendo coisas estúpidas e quebrará tudo enfiando paus nas rodas.

É melhor iniciar a implementação criando um grupo de iniciativas: tente a abordagem juntos, entenda as nuances e entenda na prática.

Só então você pode ir a um arquiteto ou engenheiro técnico para explicar o valor para ele. Mas lembre-se de que o DDD não é necessário em todos os lugares. O DDD resolve problemas específicos, por isso é muito importante não exagerar.

A abordagem tem um efeito colateral: se as pessoas começarem a lutar pelo DDD, elas já começarão a agir no paradigma de “Dividir, dividir, reduzir a conectividade e seguir a lógica dos negócios”. E a partir disso, mudanças positivas começarão: em algum lugar o código será melhor escrito, em algum lugar a velocidade aumentará. Esse conhecimento não precisa se transformar em código em contextos e outros artefatos DDD. O código pode continuar sendo o código, mas ficará melhor e a velocidade e a qualidade aumentarão.

6. Como implementar DDD na empresa de cima para baixo


  1. Certifique-se de que essa abordagem ajude em um caso específico.
  2. Encontre uma pessoa na equipe com habilidades arquitetônicas (ele ajudará a determinar em que parte do sistema as costuras serão cortadas).
  3. Convide os profissionais de DDD para ensiná-lo.
  4. . ! . , .

7. DDD


Claro, através da prática. Apenas não diga à pessoa com antecedência que você está ensinando a ela DDD, não se assuste com antecedência.

Deixe a pessoa vir e pegar os quebra-cabeças. Não diga a ele que é DDD, deixe que ele faça. Ele fará com base em como ele entende o sólido e tudo isso. Então, quando ele vai entregar o trabalho, ele precisa dizer: “Cara, parece funcionar, mas precisa ser refeito” e explique a ele o porquê.

Não force a ler ou aprender tudo de propósito. Seja interativo a esse respeito. Assim, uma pessoa em 3-5 meses começará a entender os princípios básicos do DDD: do ponto de vista da implementação, do ponto de vista da teoria. Ele começará a entender padrões ainda mais cedo por artefatos de abordagem - mapas de contexto. A princípio, as pessoas não entendem nada, mas gradualmente elas são cortadas e algumas até lêem livros.

8. Eu sou capaz de DDD - uma linha sem importância para o currículo na Rússia


Se você está na Rússia e conhece DDD - isso é legal. Mas está longe do fato de que o conhecimento do DDD em si é útil no trabalho. Pelo contrário, servirá como um indicador para o empregador sobre o seu alto nível de desenvolvimento como desenvolvedor. Afinal, as habilidades que você adquire estudando a abordagem DDD desenvolvem você como programador e designer (arquiteto).

Mas se você está pensando em se mudar para o exterior, essa linha no currículo pode ter um impacto positivo. No exterior, a comunidade DDD é muito maior e a abordagem em si é muito mais popular que a nossa. Especialmente na Europa.

9. A relação do DDD com os pêlos faciais


Observação: Pessoas que entendem DDD usam barba. Isso significa que ter barba é um pré-requisito para o sucesso no DDD? O que você acha?

10. Materiais úteis sobre DDD



« ». , . , Miro, , Amazon, Microsoft, . .

:

More articles:


All Articles