Clean architecture? Onion architecture? DDD? CQS? “Outras Cenas… :) “

Aviso: Este post está escrito em português para apelar à existência de mais artigos na nossa língua. Outra nota que quero desde já ressaltar é que a escrita deste artigo é bastante informal e em forma de desabafo.

Imagino a vossa expressão quando olham para o título e pensam:

O que vai sair daqui? Vais falar sobre tudo isto num único post? Vais-me partilhar conceitos sobre cada uma destas “coisas”? Não consegues!

Não! Não vou falar sobre todos os conceitos de todas estas “coisas” como lhe chamas, um post não chegava, provavelmente nem 5 nem 6 :D

Neste post vou partilhar momentos de conversas que tive, opiniões minhas sobre alguns destes assuntos, o que tenho visto nos últimos anos. Ressalvo que são opiniões minhas e que respeito todas as outras opiniões e tenho todo o gosto em que me as partilhem, provavelmente até vão parar a um post como este, ou não.

Uma das coisas que me dá mais prazer na nossa área é analisar código bem feitinho. Mas quem é que não gosta? Ás vezes perco horas a olhar para ele. Sim! São mais as horas que perdes a analisar código do que aquele que perdes a escrever, podes colocar aí 70% do tempo e se calhar estou a ser boazinha. Sou tipo águia, passo a vida a passear de projecto em projecto para cuscar! Desculpa, mas não resisto em cuscar o que andas a fazer e como. Isso pode ser útil no sentido em que se alguém já passou por um problema parecido ao teu e já bateu com a cabeça não precisas de bater também, trocam impressões, conversam e porque não um pair programming? É assim que saem grandes ideias!

Domain

Perante o que já vi e algumas discussões que já tive, existem programadores que consideram que quando desenvolvemos um software devemos pensar o mais próximo da realidade, dando extrema importância aos nossos domain models. Devem ser enriquecidos com lógica de negócio. Por exemplo, agora pergunto-te, faz sentido uma Order não ter produtos associados? Se consideras que não faz, então porque não recebes essa lista de produtos no constructor da Order? Podes obrigar a que seja criada essa Order com esses produtos. Outra coisa que muitos defendem é que devemos proteger muito bem estas nossas entidades. Se uma entidade tem um Id único, devemos garantir que uma vez atribuido não será mais alterado.

Deixo-te aqui o exemplo de uma entidade:

public abstract class Entity<TKey>
{
     public Entity(TKey id)
     {
        this.Id = id;
     } 
     public TKey Id { get; private set; } 
}
public class Product : Entity<Guid>
{
      public Product(string name, double unitPrice) 
                : base(Guid.NewGuid())
      {
         this.Name = name;
         this.UnitPrice = unitPrice;
         this.Quantity = 1;
      }
        
      public string Name { get; private set; }
      public decimal UnitPrice { get; private set; }
      public int Quantity { get; set; }
      public decimal TotalPrice 
      {
         get { return UnitPrice * Quantity; } 
      }
      
      public void UpdateName(string name){
         this.Name = name;        
      }
      // more code here
}

Isto é um exemplo muito simples. Sabes quantas vezes vi isto num projecto profissional? Poucas, talvez 1 ou 2 vezes em 8 anos. Por norma o que se vê, é um conjunto de classes apenas com propriedades com os seus respectivos gettters e setters e pronto, é isto! Sim, eu também fiz muitas dessas classes e pouco me importava com o domínio embora sabendo a sua importância. Não é fácil pensar no domínio, mas podiamos tentar e podemos sempre falar com domain experts.

Outra coisa que se vê, e eu também o faço muitas vezes, é aproveitarem essas classes (que só têm propriedades e que supostamente são domain models) para mapear com as tabelas da base de dados. Espectáculo, que mistura! Agora passaram a ser data models e não domain models. Agora pensas: tantos conceitos, data models? domain models? sim! É verdade! Eles existem. Nós podemos ter três conceitos: Data Models, Domain Models e Presentation Models. Os Data Models podem estar junto à tua camada de repositórios e representam as tuas tabelas na base de dados. Podes mesmo considerar uma cópia. Os teus Domain Models são as entidades que contêm a tua lógica de domínio e depois ainda tens os Presentation Models que são classes que têm unicamente a informação necessária para apresentar ao utilizador nas camadas de apresentação. Não falei dos DTO’s que são os conhecidos Data Transfer Objects que servem para transportares informação entre camadas da tua aplicação. Tantos nomes não é? Pois é, vais ver esses nomes em muitos livros, artigos, vídeos, etc … uma festa! Foram poucas as vezes que implementei este esquema assim tão linear, com os três tipos de models. Note-se que gosto destes conceitos.

Por vezes, por muito que queiras fazer uma coisa e te esforças, há sempre desvios, já ouvi isso de algumas pessoas e confesso que é verdade e já o senti! É doloroso! Mas se fosse fácil, perdia toda a piada.

Comandos, Queries, e outras coisas

Um outro assunto que muito se discute é o nosso conhecido conceito de comandos e queries. O CQS diz que uma query nunca deve alterar estado na tua aplicação e deve retornar dados, enquanto que um comando é responsável por alterar o estado da aplicação e nunca deve retornar dados, portanto void. Considero bastante interessante estes conceitos e não resisti em explorar e experimentar aplicá-los, mas pergunto, são sempre necessários? Um dia perguntaram-me: Achas necessário usarmos o CQS, não podemos simplesmente usar uma camada de serviços simples, interface e a sua implementação? Claro que não, se achas que no teu contexto não necessitas de o usar e sentes ser mais natural criar uma interface que representa o teu serviço, força nisso, não vejo qualquer problema. Na minha humilde opinião, se o software for facilmente testável, modular, flexível, extensível, força nisso e dá-lhe com alma. Para mim o que reina é a simplicidade! Por vezes, temos ideias excelentes e construimos grandes coisas e depois, mais tarde, descobrimos que secalhar estamos a complicar o que poderia ser simples. Isso é perfeitamente normal acontecer, faz parte da evolução do teu software. Nunca se desenha um software perfeito à primeira, ele vai crescendo, evoluindo, sofrendo refactorização etc. Nota: Perfeito é uma palavra muito forte! :D

O CQS diz que um comando não deve retornar dados. E se me der jeito retornar? porque não o fazer? só porque os puristas dizem que não se o deve fazer? Mais uma vez, na minha opinião fazemos aquilo que nos parecer mais natural. Agora deve estar a vir à tua cabeça, uma quantidade de princípios, boas práticas, SOLID , entre outras coisas. Sim, é duro fazer bom software mas é tão giro e fixe!!! Às vezes pecamos, meu deus quantas vezes eu já pequei :O mas faz parte. O mais importante é aprenderes com isso e saberes o que estás a fazer e apresentares bons argumentos.

Toda a vida vais presenciar code smells nos projectos que analisares, não há hipótese! Faz parte! Já viste a lista de categorias e tipos de code smells que existem? Provavelmente nem sabes que são categorizáveis. Sim! São muitos, desde os bloaters, dispensáveis entre outros. Existe um ou outro que tolero, mas há outros que minha nossa, fico passada heheheh e lá vou eu refactorizar :D Rezo para haver testes implementados para poder refactorizar, mas muitas das vezes não há :-(

Clean architecture / Onion architecture / entre outras

Ouve-se, observa-se e lê-se sobre diferentes tipos de estruturas de projectos. Provavelmente já viste os desenhos abaixo.

Se fores pesquisar vais notar que quando te referes a clean architecture mostram-te o primeiro desenho, e quando procuras por onion architecture vais visualizar o segundo. E agora dizes: Mais conceitos? Não é tudo a mesma coisa? Vejo sempre Arquitectura X, Arquitectura Y, Arquitectura Z. A única coisa comum é o nome arquitectura.

Mais uma vez comprendo a tua dor, tenta pensar de outra maneira. Tenta ler sobre estes conceitos, tenta ver as diferenças, tenta tirar partido do melhor dos dois mundos e quem sabe criares a tua própria arquitectura. E já agora, dizes arquitectura isto, arquitectura aquilo? Já tentaste definir o que é uma arquitectura? Já sei o que vais dizer: isso é trabalho para os arquitectos! Os arquitectos não são deuses, não fazem tudo sozinhos, precisam de ti. Eles podem te aconcelhar, mostrar o melhor caminho com base na sua experiência, partilharem aquilo que sabem contigo, ajudarem-te a pensar, a darem-te a conhecer a empresa onde trabalhas e para onde caminha mas não conseguem mais do que isso. Precisa de haver um esforço da tua parte, de querer aprender, ser entusiasta, fazer as perguntas certas no momento certo (que não é nada fácil), explorar alternativas! Porque não desenhas algo tu e propões? Não te queixes (sim eu também o faço às vezes :( ) faz as coisas acontecerem, propõe ideias, constroi umas POCs e apresenta quando vês que há coisas que poderiam ser melhoradas, faz contribuições, sê chata ou chato!! heheh

Comecei a explorar um bocadinho melhor estes conceitos, ando a tentar desenvolver umas POCs com diferentes desenhos de arquitectura que me parecem naturais e talvez um dia saia um post dedicado só para isto. Lá está, é a colocares a mão na massa que vais aprender, ver videos e ler artigos sem experimentar não dá. Como sabes que a teoria se traduz na prática? Só sabes quando vires a funcionar à tua frente, ou então confias na palavra de pessoas muito experientes, embora às vezes possamos ter surpresas. Felizmente, ultimamente, não tenho tido surpresas mas já tive no passado. Não perdes nada em experimentar, só tens a ganhar!

Resumo

Provavelmente pelo título do post esperarias muito mais, mas eu avisei logo de ínicio que não iria falar de todos os conceitos e mais alguns sobre estes assuntos, um post nunca chegaria! Apenas desabafei, partilhei conversas que tive, mostrei-te algumas opiniões minhas que podem vir a mudar amanhã. Por vezes partilham-me opiniões que me deixam a pensar e digo para mim: Faz-me muito sentido o que dizes, secalhar gosto mais dessa ideia… tantas vezes que isso me acontece! hehe

Deixo uma frase chave:

Simplicity is everything!

Escolhe a tua implementação, vê o que te parece natural e força nisso :)