Gostei muito dos conceitos do vídeo Os Princípios da Arquitetura Limpa, do tio Bob Martin. Mas sinto que esse padrão é como uma combinação dos padrões Abstract Factory e Builder em sua essência.
Nem mesmo perto.
Quando você olha para isso:
Você está olhando para o design de um gráfico de objetos. Isso determina o que sabe sobre o quê. O que falta nessa história é como esse gráfico de objetos foi construído. Desculpe, mas você não encontrará isso aqui. Não há nenhuma menção à construção.
Você pode construir tudo isso sem fábricas e construtores abstratos. Eu sei porque eu fiz isso . Eu nem pretendi evitá-los. Adoro eles. Eu simplesmente não precisava deles. Eu apenas usei passagem de referência. Injeção de Dependência é o termo chique para isso.
Na verdade, eu poderia construir tudo o que você vê nesse diagrama em geral. Em seguida, basta chamar um método em um objeto para iniciar o processo.
Agora as coisas precisam existir antes que você possa colocá-las em outras coisas. Eu explorei isso aqui e dei a esse pequeno diagrama bonitinho:
E você pode construir tudo isso sem precisar sair main().
Eu recomendaria o uso de construtores e fábricas quando você quiser dividir uma pilha de código de construção processual em pedaços conceituais de bom tamanho. Mas não há nada na arquitetura limpa ou em qualquer outra arquitetura de palavra-chave que exija que você faça isso. Então, se você quiser continuar main(), tudo bem. Apenas por favor, tenha piedade .
A “Arquitetura Limpa” de Bob Martin é uma regra de ouro para todas as arquiteturas ou é apenas uma das opções?
Considero Arquitetura Limpa como um chavão usado para levar as pessoas a um blog e um livro. Esse blog e livro têm explicações muito boas de arquiteturas antigas muito semelhantes, com nomes mais antigos usados para levar as pessoas a blogs e livros mais antigos. Especificamente cebola, bem como portas e adaptadores. Nenhuma das quais são as únicas opções de arquitetura que você possui.
Eu gosto do tio Bob porque ele é um incrível palestrante e autor público. Ele me faz pensar em coisas que eu não teria de outra maneira. Mas se você deixar isso transformá-lo em um fanático religioso que insiste que tudo deve ser feito da maneira dele, você descobrirá rapidamente que a atualização da documentação é a mais próxima que eu deixarei que você chegue ao meu código.
As arquiteturas de chavão são úteis quando você tem um código de longa duração que precisa persistir enquanto o mundo muda em torno dele. É quando brilha. Se o mundo estiver estável em comparação com o código, você estará fazendo coisas sofisticadas sem uma boa razão.
Não importa o quão impressionante algo pareça, existe um contexto em que você pode colocá-lo, que o tornará absurdo. Desculpe, isso também não é uma bala de prata.
Mas, no vídeo, sinto que ele sugere que a arquitetura limpa deve ter uma fronteira clara entre a lógica de negócios e as estruturas. Estruturas (web, android, etc.) devem ser plugins que se conectam à lógica de negócios. Ele até zomba sutilmente dos trilhos no vídeo.
Você está certo. Ele faz. Tio Bob acha que os frameworks podem ser tratados como bibliotecas. E eles podem. Mas mesmo essa decisão lhe custa algo.
O que o Sr. Martin está tentando preservar é um espaço em que sua linguagem de propósito geral ainda é geral. Você desiste disso quando espalha uma estrutura por toda parte. Quando você faz isso, está seguindo o caminho de transformar seu idioma em algo chamado idioma específico do domínio. HTML é uma linguagem específica do domínio. Faz seu trabalho muito bem, mas há outros trabalhos que ele não pode fazer.
Desde que suas necessidades sejam antecipadas pela estrutura, as coisas correrão muito bem. É bom ter suas necessidades antecipadas. Coloca você em uma caixa que mantém as coisas simples. Basta entender o que você está desistindo para conseguir isso. Se você espalhar o Spring em todos os lugares, não poderá mais publicá-lo como um trabalho em Java. É um trabalho Java / Spring. Eu poderia dizer o mesmo sobre Ruby e Rails, mas Rails almoçou com Ruby há muito tempo.