Há um ano, Maxim Arshinov (marshinov) fez uma apresentação "Instant Design". Ótimo relatório, orador carismático, materiais úteis no final. Este relatório mudou minha compreensão do que eu estava fazendo - qual de nós não tentou aplicar intuitivamente a arquitetura de pipeline? E há soluções elegantes multiplicadas pelo DDD! Isso começou minha jornada como evangelista em projetos específicos de domínio.

DotNext 2019 Moscou está chegando. Como sempre, estamos aguardando uma revisão de novos recursos, troca de experiências, melhores práticas, soluções arquitetônicas - por isso todos gostamos de conferências. Na lista de relatórios está a wokshop “O Brilho e a Pobreza do Modelo de Assunto”, que chamou minha atenção. Citação da página:

Fowler e Evans consideram o modelo anêmico antipadrão. No entanto, muitas bases de código com as quais o falante trabalhou são implementadas no estilo de um modelo anêmico. O relatório dedica-se a comparar os pontos fortes e fracos de ambas as abordagens e os detalhes não óbvios da implementação do modelo de domínio no paradigma OOP e no estilo funcional.

A própria produção faz pensar que surgiu uma crise no desenvolvimento do movimento DDD. Uma pequena análise das disfunções de uso e os motivos de tais distorções sob o corte.

Disfunções do uso do design orientado ao assunto

A situação atual tem algum desenvolvimento histórico. Vamos considerar em etapas como a situação se desenvolveu.

Promoção

Maxim, na minha opinião, é o desenvolvedor mais famoso da comunidade, que por muitos anos promoveu o DDD com competência, falando sobre o conceito de uso. Honre-o e louve-o! E cito Arshinov como exemplo, apenas porque o considero o melhor orador do dotnext no momento.

Disfunção nº 1: lucratividade

marshinov escreveu vários artigos sobre o custo da implementação de práticas de DDD. A conclusão é simples - o design orientado ao assunto é caro. E os julgamentos são justos - o próprio Evans, em seu livro, observa que a equipe deve ser muito qualificada e, portanto, cara. Além disso, essas são melhorias contínuas, caras para os negócios. Well revela este artigo de Martin Fowler sobre os custos da arquitetura . Atrevo-me a supor que a questão de quanto uma empresa deseja gastar recursos é a solução de seus problemas, antes de tudo, para si mesma. E o cliente não resolve nenhum dos seus principais problemas, mesmo o SOLID não poderá vendê-lo.

É muito importante entender o antagonismo entre os requisitos de negócios e as decisões de arquitetura. As empresas precisam da solução mais barata que atenda às suas necessidades (e melhor da primeira vez e para sempre). As equipes querem criar ferramentas e soluções que resolvam os problemas de negócios da maneira mais correta, rápida e bonita, mas principalmente a tarefa de adaptabilidade às mudanças. A natureza dessas necessidades (de fato, contradições polares) é muito dialética, o que significa que é impossível realizar requisitos complexos sem elaborar a arquitetura, e os condomínios não podem ser construídos em vez de uma casinha de cachorro. Não, é claro que tudo é possível. Mas o fato é que as altas demandas, por um lado, dão origem ao correspondente, por outro. Como a fraqueza patológica de um lado, limita o outro.
E assim, na tentativa de igualar os negócios, um segundo desastre se formou ...

Disfunção # 2: Projeto Instantâneo, também conhecido como Modelo Anêmico, ou Consentimento

Obviamente, uma certa comunidade de programadores está tentando trazer para as massas de práticas um design mais orientado ao assunto, reduzindo custos e aplicando novas técnicas: Programação Ferroviária, Pipelines, Modelo Anêmico. Uma abordagem interessante, muitos aconselham, pode ser ensinada a qualquer programador: "aqui você tem o SeedWorks com interfaces, implementa-as e tudo estará". E funciona! mas isso não é DDD.

Você não entende direito Evans.

• Quem não elogia Klopstock? Mas todo mundo vai ler? Não. Queremos ser menos reverenciados, mas leia com mais diligência! (Lessing).

Eu vou explicar agora.

O modelo anêmico é um antipadrão

O fato é que, na ciência, existem dois métodos de pesquisa - descritivo e analítico (olá Adam Smith). Quando criamos o modelo anêmico, simplesmente descrevemos o que vemos e vivemos com ele como ele é. Isso reflete um negócio e é suficiente para realizar uma oportunidade de negócio. Um princípio importante descrito por Evans não é desperdiçar recursos em um sistema ideal, mas simular o processo como está, e só então começar a refatoração profunda. E em que momento com o Modelo Anêmico podemos avançar para a refatoração profunda? É suposto iniciar tudo? Parece-me que a resposta será negativa, e o modelo aqui permaneceu como atavismo.

Isso é apenas o modelo em si não é importante! Padrões táticos não são importantes! Contextos limitados, um idioma único e estrutura em larga escala são importantes. É por isso que é necessário abordar a entidade de negócios do lado analítico, descrevendo a raiz de agregação, objetos de valor, métodos de negócios e, como resultado, entender os limites de um contexto limitado.

Por um lado, é bom um modelo anêmico e uma solução barata, porque os programadores iniciantes terão um entendimento de uma nova dimensão na programação - objetos de negócios. No entanto, adotando uma posição semelhante, você está se saindo mal por si mesmo. Ao contratar um programador mais fraco sempre que pode fazer o mesmo que copiar e colar, você tem um argumento para a empresa procurar um funcionário mais forte?

Mas não poderia terminar com o fim inglório da idéia de DDD.

Disfunção nº 3 Vida após objetos de negócios, também conhecida como complicação de ferramentas.

Na primavera de 2019, Maxim e Wagib nos falaram sobre como os recursos do F # em C # não vieram, sobre como tornar o modelo corretamente no F # é mais fácil, sobre como no funcionalismo não violar o OOP. Agora, as massas podiam acreditar que o DDD não era apenas acessível para encomendar músicas, mas não para todos os mortais, mas apenas para aqueles que conheciam programação funcional.

Ouça onde todos eles dirigem - agora o design orientado ao assunto é caro, você pode escrever efetivamente apenas em F # e geralmente funciona às vezes, às vezes. Não há uma leve impressão de que, dessa maneira, os autores de livros e artigos nos distraiam dos mais importantes no DDD, atraindo o jogo com padrões táticos ideais. E eles devem ser bonitos e lambidos, caso contrário ...

Claro, não há outro caminho. Todas essas abstrações são importantes em uma conversa no BrainSrorm, quando todos precisam entender tudo com muita clareza. Ou se você encontrar gerentes e analistas que analisarão seu código - um único idioma (se o código for UL).

No entanto, como mencionado acima, o oposto buscará seu próprio caminho. A abordagem criou raízes onde a empresa está disposta a pagar pelo desenvolvimento de código funcionalmente não-óbvio - esse é apenas um nicho de mercado, não uma regra.

O que é absolutamente nojento aqui é a natureza humana simples da atitude em relação às realizações - as pessoas apreciam essas realizações em si mesmas, sem fornecer a elas uma forma e um aplicativo aplicado. E aqui a lista pode ser longa. Einstein nos deu STO, GR, FE, ele é um excelente cientista, mas pergunte à pessoa comum sobre o movimento relativista, tempo - ele não precisa de Einstein, mas em uma conversa "inteligente", pode-se mencionar que tudo é relativo. Pergunte a alguém sobre Freud, um grande psicólogo que fez um progresso sério na ciência, se ele usa a psicologia, por exemplo, para interpretar o pesadelo de ontem - ele não o fará, mas um dia mencionará a sexualidade e a psicologia das massas. Marx é quem criou a ciência a partir da sociologia e da história, mas ninguém precisa do socialismo científico, mas todos podem falar sobre impostos progressivos e democracia honesta. O design orientado a problemas também não tem forma - Eric Evans abriu novas alturas para nós, fornecendo uma excelente ferramenta para reduzir a complexidade do software, mas ostensivamente como usar o DDD e o que fazer não está claro, e geralmente não funciona.

Não sei o resto, mas com o design orientado ao assunto você pode entender as razões dos mal-entendidos.

As razões da crise de uso

Os princípios do design orientado ao assunto são muito tentadores, lógicos e holísticos. Tudo está próximo aqui - Agile, CI, SOLID, GRASP - tudo de melhor que os desenvolvedores criaram. No entanto, não basta acreditar em DDD, nos negócios ou na experiência. Muitas pessoas da comunidade, apenas desenvolvedores de integradores e escritórios de terceirização, têm a impressão de valores de negócios em seu trabalho e com todo o desejo de não poderem experimentar os métodos e práticas de liderança, porque o preço dessas tentativas e erros não está incluído na lista de preços - é um final completamente materialista.

Não resta absolutamente nada para esses comandos, exceto como tornar a programação lucrativa, usando abordagens mais simples, contratar desenvolvedores mais baratos, mas um modelo anêmico pode ser fisgado em meia mordida. E se você é o desenvolvedor de um dos desenvolvedores que vem por uma hora - não possui perspectivas significativas - deve concluir o pedido e a criatividade é incentivada apenas no github do projeto inicial. O DDD não é um luxo para um arquiteto, nem uma demonstração do cliente - o nível da equipe em uma empresa separada. Você precisa realizar o seguinte - enquanto estiver em um relacionamento de produção com aqueles que vendem seu trabalho qualificado para aqueles que pagam melhor, você só fará o que o cliente pagou - a implementação de tarefas de negócios. Infelizmente, o teste das melhores práticas nem sempre está no plano dessas tarefas.

Sumário

O DDD sempre pode ser tentado se você estiver descrevendo objetos do mundo real. Essa abordagem pode ser aplicada em PHP, VBA e 1C (e os desenvolvedores se aplicam). O problema de aplicar a abordagem é mais provável no plano de comunicação entre as pessoas, e é mais provável que a tecnologia ajude. Comunicar, tentar, ensinar os outros! Aumente as habilidades do Softs, solidariedade, unidade de propósito. DDD é apenas uma técnica de trabalho em equipe.

E da próxima vez que você pensar sobre onde ir para uma entrevista, pense cuidadosamente sobre o que escolher - uma empresa que revende suas habilidades sem piedade, ou quem realmente precisa delas para resolver problemas específicos. Está ao seu alcance ajudar uma empresa assim a ser melhor, tentar métodos e abordagens proporcionais, formar uma equipe unida e cumprir sua missão como programador. O último é especialmente importante, porque para novas tecnologias e produtos, muitos esqueceram o objetivo original dessa profissão.

Seja como for, resta esperar que, ao tentar abordar as práticas de liderança, o DDD não seja transformado em nenhuma outra direção por conveniência dos clientes e equipes. Aguardo com expectativa o próximo relatório.

PS O objetivo do tópico é um convite para uma discussão. Não há nenhum objetivo de menosprezar o mérito de qualquer membro da Comunidade DDD. Com respeito, trato todos os representantes, o que não remove os problemas do desenvolvimento.