O Padrão Modelo de Domínio não é uma Opção

Pessoalmente não gosto de definir máximas em termos de desenvolvimento de software, pois nosso entendimento e visão sempre podem mudar. Há algum tempo bases relacionais eram amplamente usadas para garantir consistência em aplicações críticas, hoje existem padrões para possibilitar o desenvolvimento praticamente sem considera a tecnologia da base de base.

Modelo de Domínio?

Permita-me lhes dar o contexto dessa reflexão. Eu sempre avalio meu estilo de desenvolvimento de software, pois meu objetivo é primeiramente sempre atender as necessidades primárias da solução e as restrições impostas. E para mim, é muito claro que que o padrão modelo de domínio é mandatório no projeto de um serviço. No entanto gigantes da área como Udi dahan criador do NServiceBus escreveu um artigo há muito me faz pensar onde ele fala que seu entendimento mudou a cerca da obrigatoriedade do uso do padrão modelo de domínio. Ele argumenta que requisitos imutáveis relacionados a aplicação não deveriam estar na camada de domínio.

Sobre modelod e domínio

For a while, I thought that the whole point of having a domain model was that requirements like this would be implemented there. However, when we consider the guidance that the domain model is about capturing those business behaviors that are subject to change, we can see that this requirement doesn't fit that mold. It is likely that this requirement will never change.

Tradução

Por um tempo, eu pensei que a ideia da existência de um modelo de domínio era para que requisitos fossem implementados lá. Contudo, quando consideramos que o guia implementação do modelo de domínio é sobre capturar as regras de negócio que estão sujeitas a mudança, podemos ver que estes requisitos não se enquadram nesse modelo. É provável que o requisito nunca mude.

Me fez rever o entendimento a acerca do uso do padrão e me apoiar dos dois grandes mestres Martin Fowler e Robert C. Martin aka "Uncle Bob" o primeiro fala eu seu livro que:

I see two styles of Domain Model in the field. A simple Domain Model looks very much like the database design with mostly one domain object for each database table. A rich Domain Model can look different from the database design, with inheritance, strategies, and other Gang of Four patterns, and complex webs of small interconnected objects.

Tradução

Vejo dois estilos de Modelo de Domínio em campo. Um Modelo de Domínio simples que se parece com a modelagem do banco de dados com a um objeto de domínio sendo mapeado para uma tabela no banco de dados. Um Modelo de Domínio rico que é muito diferente da modelagem do banco de dados, com herança, estratégias, outros padrões de projeto do livro Gang of Four, e uma rede complexa de pequenos objetos interconectados.

Ou seja: existem dois conjuntos de ferramentas para de implementar um modelo de domínio, nem todos precisam se utilizar das ferramentas de projeto do modelo rico.

Ok! seguimos para o que o segundo falar a acerca do domínio de negócio criador dos princípios de Arquitetura Limpa cujo o livro de mesmo nome está aqui, segundo Unbcle Bob:

Todos os sistemas de software podem ser decompostos em dois elementos principais: política e detalhes. O elemento político engloba todas as regras e procedimentos de negócios.....

sobre o segundo ponto

Os detalhes são itens necessários para que os seres humanos, outros sistemas e programadores se comuniquem com a política.....

Ainda sobre o desacoplamento das camadas ele fala:

As próprias regras de negócio podem estar fortemente ligadas à aplicação ou ser mais gerais. Por exemplo, a validação de campos de entrada é uma regra de negócios fortemente ligada à própria aplicação. em contraste, o cálculo dos juros em uma conta e a contagem do inventário são regras de negócio mais fortemente associados ao domínio.

Uncle Bob tem por base que o negócio é cidadão de primeira classe e principal preocupação da arquitetura:

De fato, essa é a primeira preocupação do arquiteto e a primeira prioridade da arquitetura. A arquitetura deve suportar os casos de uso.

A importância

No meu entendimento é, faz todo sentido desenvolver a arquitetura em torno de uma camada de domínio, da mesma maneira, faz todo sentido estruturar essa camada com base no modelo de domínio seja simples usando apenas padrões como Entidades e Objetos de Valor é sempre bem interessante considerando a separação dos tipos de regras de negócio:

• Regras de contrato de objeto: usadas em validações como entrada de dados, ex: Um objeto Moeda espera um valor maior que zero poderá retornar uma exceção caso isso não aconteça.
• Regras de entidade: Uma entidade representa um elemento de negócio que tem uma identidade e poderão ser armazenado e recuperado. Ele possui propriedades que se forem Objetos de Valor, poderá reaproveitar as validações já realizadas por suas propriedades. No entanto ela pode conter regras que extrapolam os Objetos de Valor, estas por sua vez se tornam o contrato de negócio da própria Entidade, como exemplo: A entidade FuncionarioCLT tem um método chamado AtualizarSalario que https://roadtoagility.net/mdelo-de-dominio-nao-e-uma-opcao/recebe o novo valor do salário, a CLT tem por regra que o salário de um funcionário não pode ser reduzido, sendo assim mesmo que ele receba um valor válido para o Objeto de Valor Moeda este não será considerado válido pelas regras da entidade FuncionarioCLT se ele for menor que o salário atual.
• Regras de negócio Extra-Entidade: A regras entre entidades surgem quando existe uma condição especial na relação entre duas entidades, exemplo: O FuncionarioCLT poderá ser promovido se ele tiver participado com o papel de Arquiteto de Soluções em mais de um projeto. Ou seja, será necessário verificar se existem associações entre o funcionário e os projeto com ele tendo atuado como Arquitetura de Soluções.

Conclusão

Ao meu ver é bem difícil representar de forma consistente qualquer dos tipos de regras sem incorrer em duplicação sem a existência de uma camada de negócio bem definida e independente das demais camadas.

Na minha visão projetar um software em torno da camada de negócio facilita o entendimento e expressividade além que manter as opções abertas para definição posterior no momento em que elas se fizerem necessárias.

Espero que tenha conseguido mostrar um pouco da minha visão a cerca da importância da separação entre as camadas e principalmente em relação a organização da camada de negócio dentro de aplicação.

Imagem da capa Image by vectorjuice on Freepik