O Domain Driven Design

Quando realizo as primeiras entrevistas com o cliente sobre um determinado sistema ou aplicativo inicialmente tento conhecer todas as nuances do modelo de negócio do cliente. O cliente, neste momento, não deve ser visto como patrocinador financeiro do projeto e sim como especialista em um determinado modelo de negócio.

Aí fica a pergunta: Como vou construir um sistema que deve gerenciar um processo ou vários processos dentro de uma empresa se eu não tenho idéia de como funciona ?

Pois é, neste momento crucial, além de aprender o modelo de negócio da visão de um único especialista também tenho que expressar este entendimento em uma linguagem comum a todos os participantes do projeto.

Atacando as complexidades do software

O Domain Driven Design (DDD), tem como principal objetivo representar e interpretar fielmente um modelo de negócio com uma organização rigorosa, profunda e seletiva. Isso não significa uma interpretação mais “realista”, mesmo porque não conseguiríamos, por conta da infinidade de minúcias de um processo, ele se assemelha mais a um processo de criação de um livro, um filme, representando livremente a realidade com uma determinada finalidade.

Conforme, (EVANS, 2010, p. 3), pode-se destacar 3 utilidades básicas de um modelo DDD.

1.O modelo e o coração do design dão a forma um ao outro. É a ligação íntima entre o modelo e a implementação que torna o modelo relevante;

2.O modelo é a espinha dorsal de uma linguagem utilizada por todos os membros da equipe com a proximidade entre o modelo e a implementação;

3.O modelo é um conhecimento destilado sendo a forma aceita pela equipe de estruturar o conhecimento de domínio.

Uma boa comunicação é extremamente importante

Imagine construir um prédio onde o engenheiro fala somente mandarin, o arquiteto fala somente russo e o pedreiro fala somente português e não existe um tradutor. Provavelmente vão surgir muitos erros básicos na construção, aumentando significativamente o nível de frustração, o custo e tempo de construção do projeto. Os especialistas deste domínio ”construção de um prédio” deveriam utilizar a mesma linguagem para poderem entender não só as diretrizes de montagem do prédio como também discutir a melhor forma de resolver possíveis problemas. É necessário a construção de uma LINGUAGEM ONIPRESENTE, que inclui nomes de classes, operações e regras que se tornem explícitas no modelo, como nomes de padrões desenvolvimento. Podemos ver um exemplo de padrões de linguagem nos modelos PSR da linguagem PHP, e na linguagem Python

Muitas vezes uma implementação bem escrita e testada é essencial para manutenção futura do sistema e um código bem escrito deve refletir o modelo que existe por trás, no entanto, um modelo não é um diagrama e o código, como documento de design tem seus limites. Por exemplo, as responsabilidades comportamentais de um objeto podem ser demonstradas, mas não afirmadas, em um diagrama de interação.

No DDD um modelo deve possuir, como objetivo principal, a implementação, o design e a comunicação da equipe, estes propósitos separados podem gerar perigos no decorrer do projeto. Não há necessidade de que os modelos sejam de objetos sendo melhor evitar a UML para não gerar uma falsa impressão de correspondência. O ideal é isolar o seu domínio dentro de uma arquitetura de camadas, conforme imagem abaixo..

Onde:

1.Camada de interface com o usuário - Responsável por interpretar os comandos e apresentar informações ao usuário. Pode ser o resultado de uma página da Web ou a resposta de uma api em um formato JSON ou XML. Camada de visualização (View).

2.Camada da aplicação - Define as funções que o software deve executar direcionando a ação para objetos específicos dos domínios. Não possui regras de negócio, tema única função de direcionar o fluxo para o objeto de direito. Camada Controladora (Controller).

3.Camada de domínio - Responsável pela camada de regras de negócio onde se localiza o modelo de domínio.

4.Infra-estrutura - Responsável pelos recursos técnicos que suportam as camadas mais altas. Aqui se encontram o acesso ao banco de dados, envio de mensagens, etc.

Montando nossa LINGUAGEM ONIPRESENTE

Princípio SOLID

Inicialmente teremos que entender os princípios SOLID que se aplicam diretamente em classes, conforme (OLORUNTOBA, 2021):

*S - Single-responsibility Principle (Princípio da responsabilidade única)

Uma classe deve ter um e apenas um motivo para mudar, o que significa que uma classe >deve ter apenas uma função.

*O - Open-closed Principle (Princípio do aberto-fechado)

Os objetos ou entidades devem estar abertos para extensão, mas fechados para >modificação.

*L - Liskov Substitution Principle (Princípio da substituição de Liskov)

Isso significa que cada subclasse ou classe derivada deve ser substituível pela classe sua >classe base ou pai.

*I - Interface Segregation Principle (Princípio da segregação de interfaces)

Um cliente nunca deve ser forçado a implementar uma interface que ele não usa, ou os >clientes não devem ser forçados a depender de métodos que não usam.

*D - Dependency Inversion Principle (Princípio da inversão de dependência)

As entidades devem depender de abstrações, não de implementações. Ele declara que o >módulo de alto nível não deve depender do módulo de baixo nível, mas devem depender >de abstrações.

Entidades

Quando um objeto é definido por sua identidade e não por seus atributos. Como por exemplo: Uma tabela Cliente, uma tabela de Pagamento é identificada como uma Entidade.

Objeto de valor

Objetos que não possuem uma identidade e sim uma característica de alguma coisa. Como por exemplo: Endereço.

Serviços

Imagine um objeto que envia emails, ou um objeto que realiza o cálculo da média aritmética, ou um objeto que conecta com um determinado banco de dados. Um serviço, pode e deve atender todas as camadas.

Módulos

Um módulo pode ser definido como um conjunto de objetos relacionados a um assunto específico. Como por exemplo o módulo de autenticação, o módulo de gerenciamento de clientes, etc.

Fábricas

Um serviço muitas vezes pode depender da execução de objetos para que ele possa efetivamente funcionar. Daí é necessário o uso do conceito de fábrica. Uma fábrica tem como objetivo carregar todos os serviços necessários para a execução de um determinado serviço.

Repositórios

Uma entidade tem como principal objetivo instanciar uma tabela. Um repositório tem como objetivo armazenar os objetos de consulta para cada entidade. Por exemplo, a entidade cliente, possui os atributos como nome, idade, etc. O repositório de cliente possui as consultas deste objeto.

Padrões de projeto

Padrão Singleton - Permite carregar somente uma instância na memória

Padrão Factory - Cria uma instância para carregamento de classes derivadas

Padrão Strategy - Permite o carregamento de classes diferentes conforme sua necessidade.

Conclusão

Este artigo não tem a finalidade de explicar a fundo todos os padrões e sim nortear o desenvolvedor sobre quais padrões podem ser adotados.

Para que uma equipe desenvolva um sistema é necessário “falar o mesmo idioma” felizmente existem vários padrões que foram construídos ao longo dos anos bastando somente que a equipe defina quais serão os padrões adotados.

Bibliografia

EVANS, Erick. Domain Driven Design - Atacando as complexidades no coração do software - 2o Edição Revisada. Rio de Janeiro, Alta Books, 2010. ISBN 978-85-7608-504-1.

PHP-FIG — PHP Framework Interop Group - PHP-FIG. Disponível em: https://www.php-fig.org. Acesso em: 02 de abril de 2021.

PEP 0 -- Index of Python Enhancement Proposals (PEPs) | Python.org. Disponível em: https://www.python.org/dev/peps/. Acesso em: 02 de abril de 2021.

PAIXÃO, João Roberto. O que é SOLID: O guia completo para você entender os 5 princípios da POO | by João Roberto da Paixão | Desenvolvendo com Paixão | Medium, 2019. Disponível em: https://medium.com/desenvolvendo-com-paixao/o-que-%C3%A9-solid-o-guia-completo-para-voc%C3%AA-entender-os-5-princ%C3%ADpios-da-poo-2b937b3fc530 . Acesso em: 03 de abril de 2021.

OLORUNTOBA, Samuel. SOLID: os primeiros 5 princípios do design orientado a objeto | DigitalOcean, 2021. Disponível em: https://www.digitalocean.com/community/conceptual_articles/s-o-l-i-d-the-first-five-principles-of-object-oriented-design-pt . Acesso em: 03 de abril de 2021.

Design Patterns & Refactoring. Disponível em: https://sourcemaking.com . Acesso em: 02 de abril de 2021.