O problema não é e nunca foi do DDD

Fala galera!

Quando Evans cunhou o termo Domain Driven Design, escreveu aquele livro super dificil de se ler, tenho total certeza de que ele não imaginava a revolução, e a confusão, que ele estava criando.

Nossa área é muito movida pelo hype e os desenvolvedores tendem a achar que uma nova tecnologia, metodologia, técnica ou framework vem para substituir o que existia e não paa complementá-las.

Hoje é dificil pedir em uma entrevista para o candidato fazer uma simples tela de soma de dois valores simplesmente porque em um projeto, que não dev3ria ter mais do que 00 linhas vamos encontrar misturados DDD, CQRS, Event Sourcing e por muito pouco isto não estará sendo construído em cima de um cluster kubernets na nuvem.

Isto porque é legal. Isto é porque a internet está cheia de palestras e artigos dizendo como os sistemas deveriam se modelados e entregues. Isto porque os casos de sucesso de Amazon, Facebook, NetFlix e Uber tem de ser replicados por todos os cantos.

Pera lá!

Comecei minha carreira desenvolvendo em Clipper. Atendi desde de lojas de bairo até as finadas locadoras. Máquinas físicas, o hardware mais modesto que conseguia montar com o orçamento que tinha, backups em disquete, os quais provavelmente não iriam funcionar.

Sabe por que? Era o que atendia ó negócio.

Um dos maiores defeitos de nossa área é nosso ego. Sim TI deixou de ser uma área utilitária para ser estratégico, em muitos casos o core do negócio. Mas vejam só, se somo o core do negóio, o que é mais importante? Isto aí o negócio.

Fazemos muito over engineering. Achamos que o sistem que estamos iniciiando hoje já tem de sair de fábrica atendendo um bilhão de requisições. Apesar de estarmos fazendo o CRUD das primeiras tabelas j’temos de pensar em como distribuir isto em micro serviços, e daqui a 3 meses quando o dinheiro que o tio do CEO da startup que nos contratou falar que não vai conseguir mais dar dinheiro porque até o momento não viu uma tela vamos achar que ele éstá errado em não acreditar, o pir não nos negócios, mas em nosso sistema.

Cansei de ver em foruns a pergunta: mas em DDD onde eu coloco tal dependencia. Em micro serviços como faço sei lá o que. Amigos, se vocênão conseguem sozinhos responder estas perguntas, você conseguem me jurar queo  problema é o DDD ou o micro serviço?

Vamos começar menos e entregar mais ao invés de comecár mais e entregar menos.

Aprenda a fazer um código limpo, aprenda a fazer uma arquitetura desacoplada, aprenda a tirar o mair proveito do framework que está a sua disposi’~ao, automatize a entrega, tenha bos práticas de code review, versionamento. Saiba como realmente funciona o banco de dados que vvocê.

Isto sem duvidas vai te guiar aquilo que DDD micro serviços, 12 factors app e tudo mais te diz pra fazer.

Até amanhã!

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s