Galera aproveitando o tópico, vocês atualmente usam mais o que MVC, MVVM, DDD ou SOLID?
Se você entendeu que eu escrevi que todas as aplicações do universo tem que operar sob as mesmas regras, então eu me expressei mal. Me desculpe!
A partir de uma decisão conjunta inicial para a plataforma e desenvolvimento, uso o que for mais simples pra manter as necessidades do cliente. A “ferramenta” que me ajuda há mais de 5 anos num mesmo projeto segue o padrão de arquitetura MVC, sem precisar ter o trabalho de arquitetar esse fluxo. De resto, business e bibliotecas. Não se prenda muito a siglas, na prática use naturalmente o que possa te ajudar de fato a entregar e evoluir funcionalidades, não algo que se torne apenas uma etapa técnica no caminho.
Quem se interessa por DDD está envolvido com algum tipo de modelagem conceitual de diferentes sistemas de uma empresa, quem mais usaria essa coisa?
De qq maneira, agora que a indústria está evoluindo pra uma arquitetura de serviços seria bom uma reedição.
Sei lá, rapaz… Eu lá conheço os motivos dos outros? 
Tem um livro mais recente de 2013 sobre DDD escrito pelo Vernon Vaughn. O trabalho dele é bem interessante e cobre o uso de DDD com Scala e Akka.
Acho que o que se usa muito é o SEM. Sem requisitos, sem arquitetura, sem design, sem testes automatizados, sem sentido…
Certo.
Vejo a galera usando mais MVC mesmo porque já têm alguns frameworks nesse padrão como Ruby on Rails, Asp.net MVC, entre outros.
Era mais uma curiosidade, concordo com você o foco é o que nosso cliente necessita.
Acho que o que se usa muito é o SEM. Sem requisitos, sem arquitetura, sem design, sem testes automatizados, sem sentido…
Isso é o que têm mais no mercado kkk.
No meu caso é o ASP.NET MVC/Web Api, um dos que copiaram o Rails, divisor de águas para simplificar o desenvolvimento web, onde nos preocupamos minimamente com arquitetura e focamos no negócio. No Java também tem o Spring MVC/Spring Boot, onde pelo que acompanho é muito bom também. Depois que essas ferramentas “zero configuração” e arquitetura pronta para usar amadureceram, o uso do “SEM” diminuiu, na prática do dia a dia é como se fosse “SEM”, mas está lá. Para quem gosta de sopa de letrinhas esse padrão de arquitetura não impede de usar em conjunto por exemplo padrões de projeto abordados pelo DDD, pois atua no lado do business. Mas não sei como alguns acham simples algo como um daqueles diagramas que postei sobre a abordagem do DDD. Sou totalmente contra a excesso de engenharia. DDD foi bom pra quem vendeu livros, treinamentos e palestras como já falaram aqui sobre esse mercado.
MVC, DDD e SOLID são conceitos ortogonais. Você pode aplicar os 3 no mesmo sistema.
1 curtida
Não é possível comparar DDD com Rails. Não faz sentido a comparação. Um é uma abordagem de desenvolvimento para necessidades complexas e o outro é um framework para apps web. É como comparar um chuveiro com um hidrante.
Isso não é time de futebol onde você tem que escolher um lado. Você usa o que precisa para fazer um bom trabalho e pronto. Não acho que é uma questão de gostar ou não…
Concordo, porem o framework utiliza alguns padrões como o ActiveRecord e isso leva a ter um codigo que pode ser fluente e de acordo com um dado estilo de negocios ( como o famoso exemplo do Blog ). Assim vc pode ter um framework que foi inspirado, de certa forma, em conceitos como DDD mas por que foi desenhado para ser assim.
É como dizer que Rails é Teste Unitario só pq vc pode rodar testes. Existe uma preparação para ser mais facil testar uma app rails ( ou app Rack, etc ) mas só pq existe uma preocupação com testes automatizados ( afinal em uma linguagem tão dinamica vc precisa de muito teste para pegar algumas coisas em Runtime ).
Não comparei DDD com Rails, comparei com ASP.NET MVC com Rails, contra as aberraçőes da Sun óbvio. Sei do que estou falando, você está juntando frases diferentes ou entendendo errado. Tanto que falei que DDD pode ser adotado em conjunto, então você não leu direito e interpretou de forma equivocada.
O que sempre falo aqui é que o advento do Rails ajudou a frear o movimento de soluções complexas, principalmente alimentado pela comunidade Java, sejam elas tecnologias ou até mesmo adoção de abordagens complexas se assim quer interpretar, mas por um movimento enfraquecer outro. Não é questão de time de futebol, quem ainda insiste em adotar DDD hoje precisa tornar os sistemas mais simples e não amarrá-los cada vez mais e precisar ficar se disciplinando com DDD. Falava o mesmo sobre JSF mas essa comunidade insistiu tanto que quebrou a cara (por favor não interprete ao pé da letra que estou comparando JSF diretamente com DDD).
concordo em parte.
quando projetos que levavam anos foram reduzidos a semanas pelo advento do Rails, muita gente comprou a ideia. entretanto o preço a se pagar surgiu nos meses seguintes e isso não tem haver, necessariamente com o Rails e sim com uma mudança de filosofia onde o complexo foi substituido pelo complexo-porem-de-interface-amigavel e a falta de gente experiente deu vazão a todas as aberrações que a gente adora conversar na mesa de bar ( que acontece em qq linguagem ).
uma linguagem ou framework não gera experts da noite para o dia. java esta ai à anos, com treinamentos, com certificação, etc.
desenvolver software É complexo. agora existem maneiras de controlar essa complexidade.
Eu complementaria, portanto, o seu comentario com a seguinte declaração: houve uma introdução de coneitos ageis junto da adoção de uma linguagem dinamica como Ruby e um framework como Rails (e conceitos como BDD, projetos como Capistrano e Vagrant que deram uma cara de devops a essa galera) e essa mistura realmente balançou o terreno pq forçou a galera a sair da zona de conforto.
DDD poderia ter entrado nessa brincadeira. de certa forma entrou.
Isso esta diretamente ligado a economia: se o projeto é simples, vc pode complica-lo pq ai demora mais (e vc recebe mais). surge Ruby e mostra q isso é balela, que sempre tem trabalho.
Ruby, Agile e DDD mostraram uma face do desenvolvimento de software: quando a galera esta inserido em uma empresa cujo CORE BUSINESS não é software. Se vc esta em um banco ou um e-commerce, o backend pode ( com algumas ressalvar) ser java, rails ou php. Usar DDD ou não nesse contexto é irrelevante do ponto de vista dos objetivos gerenciais.
De repente vem Rails: seu projeto em uma semana. ops o projeto é complexo e vc leva 4, ja tem gente desesperada querendo saber o que houve, enquanto a galera java esta a meses enrolando uma servlet.
Perceba que nada disso é problema especificamente de metodologia, de tecnologia ou linguagem. Vc tem problemas gerenciais, de negocio e de comunicação.
Pq a galera fala em UML? pq pode colar num documento do word e dizer que foi ‘especificado’ e tirar o seu da reta.
A ultima decada foi meio q “jogar no ventilador” alguns problemas e varios deles são classicos ( basta ver o Mythical Man-Month).
Quando a gente se torna experience a gente descobre que se usa X pq alguem lucrou com isso. Se uma empresa usa Java, a Oracle vai ganhar, a Accenture pode ganhar, etc. Se torna uma questão de budget, de segurança, de previsibilidade. E pra quem vive desenvolvimento de software, isso pode ser frustrante. Sabe aquela API REST que iria resolver todos os problemas, feita com SOLID e DDD? Não vai rolar pq compraram 50 licensas de qq coisa.
Mas nem tudo esta perdido. Mesmo dentro de empresas nada tecnologicas podemos criar um espaço e fazer um trabalho bem feito. Em geral isso leva a gente a outro patamar profissional.
são os meus dois centavos.
Relendo o seu texto com mais atenção, fica evidente que você não fez uma comparação direta entre DDD e Rails. Não li direito mesmo.
Simplificação é sempre um objetivo a ser perseguido e o Rails é um excelente exemplo disso.
Tudo bem então, você deve ter confundido pelo comentário do outro colega iniciar listando várias siglas ao mesmo tempo.
Exatamente isso, perseguir a simplificação. Apesar de nunca ter usado Rails, sempre lembro de como foi importante para mudar o cenário.
Rails mudou o cenário na medida que qualquer programador mediocre poderia criar um web site medíocre em 72h.
Mas ai veio o trem mobile… agora programador quer criar app pra android.
piuííí…
Perfeito esse ponto. É exatamente nesse contexto que defendo ser irrelevante.
SOLID reforça principalmente principios e boas práticas que desenvolvedores experientes já seguiam, só que depois criaram essa sigla falando algo a mais pra movimentar o mercado de palestras. Mas não deixa de ser importante principalmente pra quem deixava de lado os principais princípios.