DEV Community: diegopaniago

Contextos Delimitados, Domínios e Agregados

diegopaniago — Sat, 08 Jul 2023 04:08:17 +0000

O Domain Driven Design (DDD) é uma abordagem de design de software que coloca o foco no domínio do negócio, em vez de apenas na tecnologia. Uma das principais técnicas utilizadas no DDD é o conceito de contextos delimitados e mapeamento de domínios.

Contextos delimitados referem-se a áreas específicas do negócio que têm um significado bem definido e uma fronteira clara. Cada contexto delimitado deve ser tratado como uma unidade autônoma e deve ter sua própria linguagem ubíqua, que é uma linguagem comum compartilhada por todas as partes interessadas em um contexto.

O mapeamento de domínios, por sua vez, é o processo de mapear as entidades, agregados, eventos e outras construções do domínio para o código que implementa o sistema. Isso ajuda a garantir que o design do software reflita com precisão o domínio do negócio e que o código seja fácil de manter e modificar.

Ao usar contextos delimitados e mapeamento de domínios, os desenvolvedores podem criar sistemas de software que sejam mais fáceis de manter e modificar. Isso ocorre porque cada contexto delimitado é tratado como uma unidade autônoma e independente, o que significa que as mudanças em um contexto não afetarão os outros contextos. Além disso, o mapeamento de domínios ajuda a garantir que o código reflita com precisão o domínio do negócio, o que significa que as mudanças no domínio podem ser facilmente refletidas no código.

Outra vantagem do uso de contextos delimitados e mapeamento de domínios é que isso pode levar a um baixo acoplamento entre os diferentes componentes do sistema. Isso significa que as mudanças em um componente não afetarão os outros componentes, o que torna o sistema mais flexível e escalável.

Em resumo, o uso de contextos delimitados e mapeamento de domínios no Domain Driven Design pode levar a sistemas de software mais fáceis de manter e modificar, com um baixo acoplamento entre os diferentes componentes do sistema. Isso ajuda a garantir que o software reflita com precisão o domínio do negócio e que possa ser facilmente alterado conforme as necessidades do negócio mudam ao longo do tempo.

Contextos, domínios e agregados

Contextos, domínios e agregados são conceitos fundamentais no Domain Driven Design (DDD), uma abordagem de design de software que tem como objetivo principal criar um software que reflita com precisão o domínio de negócio.

Contextos delimitados: São áreas específicas do domínio de negócio que são tratadas como unidades autônomas e independentes dentro do sistema de software. Cada contexto delimitado possui suas próprias regras de negócio, entidades, agregados, eventos e linguagem específica. Essa divisão em contextos delimitados ajuda a garantir que diferentes partes do sistema sejam tratadas de forma separada e que mudanças em um contexto não afetem outros.
Domínio: É o conjunto de conhecimentos, regras e termos específicos que definem o negócio. No DDD, o foco é entender profundamente o domínio e refleti-lo no código e na estrutura do software. O mapeamento de domínios é o processo de traduzir as construções do domínio, como conceitos, entidades, regras e relacionamentos, para o design e implementação do software.
Agregados: São conjuntos de objetos relacionados que são tratados como unidades coesas dentro do domínio. Cada agregado possui uma raiz de agregado, que é uma entidade que atua como a única entrada para o agregado e encapsula a consistência e a integridade interna do mesmo. Os agregados ajudam a organizar as entidades relacionadas em unidades lógicas e garantem a consistência das operações dentro dessas unidades.

Esses conceitos do Domain Driven Design ajudam a criar um software que reflita com precisão o domínio de negócio e seja mais fácil de entender, modificar e manter.

"A modelagem de software é uma atividade de design, não uma tradução direta das regras de negócio em código." - Eric Evans

Desenvolvedores, Carga Cognitiva e Demissões

diegopaniago — Thu, 07 Apr 2022 12:54:47 +0000

Comumente, vemos empresas de tecnologia que dão total liberdade para os desenvolvedores escolherem a melhor tecnologia, plataforma e frameworks para um projeto. Isso, na realidade, é muito positivo e sempre encorajo as empresas a oferecerem essa liberdade ao time de desenvolvedores.

No entanto, não podemos negar que isso gera um problema sério quando os desenvolvedores não consideram a magnitude do desafio que podem estar enfrentando.

Esse desafio é conhecido como carga cognitiva alta, ou seja, um único desenvolvedor precisa dominar várias tecnologias, frameworks e plataformas para trabalhar em um projeto, além de ter que dominar a regra de negócio.

Essa situação, além de ser comum, acarreta sérios problemas para o negócio da empresa, pois tende a aumentar consideravelmente a curva de aprendizado dos novos desenvolvedores, o tempo necessário para encontrar pessoas com habilidades tecnológicas adequadas e, pior ainda, aumenta o estresse das pessoas envolvidas nos projetos, devido à carga cognitiva excessiva, resultando, muitas vezes, em demissões (voluntárias ou não).

É necessário que, de alguma forma, as pessoas se organizem e tenham consciência de que uma variedade excessiva pode causar os problemas mencionados anteriormente.

Além disso, há um cenário bastante comum em que um único time precisa dominar uma quantidade muito grande de regras de negócio, o que novamente gera uma carga cognitiva elevada e torna o projeto desinteressante, desafiador e estressante.

A cereja do bolo é a criação de microserviços sem uma reflexão aprofundada sobre os contextos de negócio, necessidades reais baseadas em dados e arquitetura, o que posteriormente resulta em uma enorme demanda de trabalho e complexidade para realizar tarefas que poderiam ser simples, como CI/CD, documentação e integração de serviços.

Portanto, é fundamental ter cuidado com a quantidade de carga cognitiva adicionada a um projeto. Gestores, arquitetos, Scrum Masters e Tech Leads devem ser responsáveis por essa preocupação, mas é importante que toda a equipe seja ensinada a pensar com cautela nas soluções propostas para os problemas enfrentados.

Software Legado, Refatoração e Catástrofes

diegopaniago — Mon, 19 Apr 2021 10:38:23 +0000

Desde o meu primeiro dia na carreira de desenvolvedor, sempre ouvi falar com desdém a palavra "legado".

Na minha vida, nunca passei por um lugar onde não houvesse o tal "legado". Isso me levou a um questionamento inevitável: será que em nenhum lugar deste planeta existe um software legado bom?

Era realmente inquietante para mim ouvir a palavra "legado" e perceber os arrepios das pessoas ao redor.

A resposta para isso veio com o tempo.

Primeiramente, devemos entender que um software é composto por código e que o código, assim que vai para produção, se torna "legado". Não existem meias-palavras para isso, o código de hoje pode se tornar uma porcaria amanhã.

Devemos entender também que não necessariamente o código que pode se tornar uma porcaria amanhã significa apenas um software com bugs. Existem outras possibilidades, como performance ruim, manutenção difícil, requisitos que mudaram com o tempo ou até mesmo envelhecimento causado pelo uso de tecnologias e bibliotecas descontinuadas.

Existem sim softwares legados de alta qualidade que enfrentam minimamente os problemas que mencionei.

Esses sistemas bem-sucedidos têm um segredo muito simples: a refatoração!

Softwares que atingem sua completude e entram na fase de manutenção devem ser constantemente melhorados. E manter um software não significa apenas realizar monitoramentos e medir a satisfação dos usuários (recomendo fortemente que façam).

De tempos em tempos, um software legado precisa ser analisado pelos programadores, devido a insatisfações, apontamentos feitos pelo monitoramento, requisitos que mudaram ou até mesmo novas funcionalidades que devem ser adicionadas.

E é nesse momento que o segredo para possuir um legado de alta qualidade entra em jogo: a regra do escoteiro.

Sempre deixe o código melhor do que quando você o encontrou.

Não acumule dívidas técnicas, resolva-as na próxima sprint ou no menor tempo possível, ou melhor ainda, não as crie. Acumular muitas dívidas pode inviabilizar a manutenção e resultar na catástrofe de refazer um sistema.

Reflicta sempre sobre o quanto é fácil trabalhar naquele projeto. As complexidades devem ser, em sua maioria, apenas do negócio e não da tecnologia. A tecnologia deve ser a solução, não o problema.

Não exponha a seu time de negócio ou ao Product Owner as refatorações que você precisa fazer. O programador deve sempre ter a autoridade técnica. Portanto, apenas estime aquilo que deve ser estimado e negocie prazos com a área de negócios, incluindo sempre aquilo que deve ser feito, inclusive as refatorações desejadas.

Isso permitirá que você tenha a possibilidade de resolver as dificuldades daquele código problemático de determinada feature.

É claro que, se o programador deixar as dívidas técnicas se acumularem, será preciso em algum momento negociar atividades de refatoração extensas com a equipe de negócios. É por esse motivo que se deve evitar o acúmulo de dívidas no código.

É necessário entender que refatoração não significa refazer o software, mas sim melhorar parcialmente o que já existe sem quebrar o sistema.

Podemos concluir que se o legado é ruim, é porque o programador o construiu assim. Não surgiram milhares de linhas de código mal escritas da noite para o dia no projeto.

Programadores que herdam legados problemáticos devem ter o profissionalismo de expor a situação juntamente com um plano de ação para o time de negócios e gestão, para que juntos definam cronogramas e atividades para resolver os problemas. Pode ser que nesse momento seja necessária a decisão de refazer um sistema, dependendo da quantidade de dívidas e do investimento necessário para resolvê-las.

Podemos perceber que não existe um bom software legado que não tenha uma atenção técnica mínima de tempos em tempos, ou seja, mantê-lo corretamente.

Aqui vai um recado para os programadores presenteados com softwares legados problemáticos: não existe um caminho saudável para resolver os problemas sem uma boa cobertura de testes automatizados, sejam eles de unidade ou integração (tenha ambos, preferencialmente).

Ter certeza de que suas mudanças não quebram o sistema é vital para qualquer software em qualquer momento do seu ciclo de vida, não apenas para legados.

Por fim, não caia na falácia de que um software concluído só precisa de manutenção quando algo dá errado ou que, se está funcionando, não precisa mexer. Mantenha seu software corretamente, com monitoramentos, testes automatizados e não deixe o código envelhecer. Sempre pratique a refatoração quando necessário.

The Art of DRY

diegopaniago — Wed, 11 Mar 2020 21:36:41 +0000

This is my first article written in English, so please bear with me and provide your feedback.

When I mention "The Art of DRY," I am referring to the concept of Don't Repeat Yourself, which I first encountered in Robert C. Martin's book, Clean Code.

At first glance, this concept seems obvious and easy to implement. However, I have come to realize that it is not only challenging to achieve but also difficult to identify when duplication occurs beyond just code repetition.

Many times, you may find blocks of code repeated throughout your software. Identifying what can be made reusable and applying techniques such as object-oriented programming and design patterns can help eliminate these duplications.

Duplication doesn't only exist in explicit code but can also be found in terminal commands, deployment processes, or routine test runs.

Once you grasp that DRY encompasses more than just eliminating code duplication, you enter a different realm.

To fully benefit from the art of DRY, you need to explore other techniques and technologies that can eliminate all the redundant actions you repeatedly perform.

Here are some practices that have delivered significant automation results for me:

Continuous Integration (CI):
- Whenever I commit and push my code, the CI tool (such as Azure DevOps and GitLab) automatically runs my test suite and provides feedback on whether my changes work well with the existing codebase.
Continuous Deployment (CD):
- After the CI pipelines complete, we automatically deploy new artifacts to staging environments and, in some cases, even to production. This is incredibly useful as it ensures that I don't forget to update staging areas for product owners and stakeholders to validate changes or refresh production environments and create git tags.
Bash:
- The power to automate tasks that you no longer wish to perform manually. This speaks for itself.
Docker:
- Apart from other benefits, Docker allows me to skip the installation process from scratch. Being able to spin up my development environment with a single command or even when I boot my PC feels like a dream come true.
Aliases:
- Creating aliases for frequently used git commands, test runs, or any other repetitive terminal tasks is a fantastic way to save time and boost productivity.

I hope you now understand that DRY extends beyond removing code duplication.

Eliminating everything that can be automated using appropriate tools is also a part of DRY.

Please share your comments, and thank you for reading.

Eventos de Domínio e Como Tornar o Desacoplamento Algo Real

diegopaniago — Sat, 01 Feb 2020 00:09:09 +0000

Evento de domínio é uma tática abordada pelo Domain Driven Design(DDD) desde sempre, mas percebo que muitos desenvolvedores subestimam a capacidade que o evento de domínio tem de tornar o seu software menos acoplado, simples e de responsabilidades bem definidas.

Alguns desenvolvedores chegam a dizer que é uma forma de trabalhar altamente complexa de ser implementada e que torna o software moroso para se trabalhar.

Hoje eu venho mostrar como tudo isso pode ser implementado de maneira simples e cumprir as promessas acima.

Um evento de domínio é a abstração de um acontecimento que tenha ocorrido. Ele sempre vai ser gerado e notificado através de um notificador de eventos que por sua vez vai "entregar" esse evento a os interessados em ouvi-lo, ou seja os manipuladores de eventos(listeners).

Antes de continuar vou demonstrar cada um desses padrões mencionados para que você comece a ver como tudo isso é implementado e como pode ser usado na sua aplicação. Utilizaremos Java 8 e Spring Boot 2.2.2, o código completo esta no meu GitHub.

Vou usar como exemplo fictício um contexto responsável por gerir e persistir cadastros de pessoas.

Esta é abstração de um evento de domínio onde irá carregar os dados que fizerem sentido para você. Recomendo que o momento da ocorrência sempre esteja presente nesta abstração para que consiga organizar cronologicamente os acontecimentos principalmente se eles forem parar em uma mensageiria.

public abstract class EventoDeDominio extends ApplicationEvent {

    private LocalDateTime data;

    public EventoDeDominio(Object source, LocalDateTime data) {
        super(source);
        this.data = data;
    }

    public LocalDateTime getData() {
        return data;
    }
}

Então o evento em si fica assim.

public class NomeDaPessoaAlterado extends EventoDeDominio {

    private String nomeAntigo;
    private String nomeAtual;

    public NomeDaPessoaAlterado(Object source, LocalDateTime data, String nomeAntigo, String nomeAtual) {
        super(source, data);
        this.nomeAntigo = nomeAntigo;
        this.nomeAtual = nomeAtual;
    }

    public String getNomeAntigo() {
        return nomeAntigo;
    }

    public String getNomeAtual() {
        return nomeAtual;
    }
}

Como estou usando o Spring Boot ele já me entrega pronta uma implementação de um notificador de eventos que é a classe ApplicationEventPublisher. É principalmente quando falamos deste notificador onde começam as implementações complexas e muitas vezes com um pattern mais complexo que o outro sem necessidade. Usando este notificador na minha camada de aplicação, eu executo a ação de alterar uma pessoa, e se bem sucedida notifico o evento NomeDaPessoaAlterado.

@Service
public class AtualizaPessoa {

    private PessoaRepositorio pessoaRepositorio;
    private ApplicationEventPublisher applicationEventPublisher;

    @Autowired
    public AtualizaPessoa(PessoaRepositorio pessoaRepositorio, ApplicationEventPublisher applicationEventPublisher) {
        this.pessoaRepositorio = pessoaRepositorio;
        this.applicationEventPublisher = applicationEventPublisher;
    }

    public void atualizarNome(PessoaDto pessoaDto) throws Exception {
        Pessoa pessoa = pessoaRepositorio.findById(pessoaDto.id).get();
        NomeDaPessoaAlterado nomeDaPessoaAlterado = new NomeDaPessoaAlterado(this, LocalDateTime.now(),
            pessoa.getNome(),
            pessoaDto.nome);
        pessoa.alterarNome(pessoaDto.nome);
        pessoaRepositorio.save(pessoa);
        applicationEventPublisher.publishEvent(nomeDaPessoaAlterado);
    }
}

A partir do momento que temos um evento notificado precisamos apenas criar o(s) manipulador(es) interessados neste evento na nossa camada de infra para que seja possível extrair as regras de negócio que não fazem parte da responsabilidade do serviço de alterar.

@Component
public class ManipuladorDeNomeDaPessoaAlterado implements ApplicationListener<NomeDaPessoaAlterado> {
    @Override
    public void onApplicationEvent(NomeDaPessoaAlterado nomeDaPessoaAlterado) {
        System.out.println("Evento Pessoa alterada");
        System.out.println(nomeDaPessoaAlterado.getData().toString());
        System.out.println(nomeDaPessoaAlterado.getNomeAntigo());
        System.out.println(nomeDaPessoaAlterado.getNomeAtual());
    }
}

A partir desse ponto eu desacoplo outras regras de negócio que cercam a ação de alterar uma Pessoa da responsabilidade única e exclusiva do serviço AtualizaPessoa de realizar o update da entidade Pessoa no banco.

Eventos de domínio servem para tornar o seu código, infra e contexto simples e desacoplados. Eles permitem que complexidades referentes a outras regras de negócio sejam implementadas em um outro momento, tornando o código da ação que esta sendo executada de responsabilidade única e bem delimitada.

Como no exemplo acima, o comando do momento é apenas alterar os dados da Entidade Pessoa, se minha regra de negócio diz que devo por exemplo salvar o log do acontecimento ou atualizar outros dados de outras Entidades no momento que a alteração ocorrer, essas complexidades podem ser implementadas separadamente e consequentemente você vai ganhar desacoplamento, facilidade de testar, e melhor controle transacional(limite transacional).

Essa tática permite que sua regra de negócio possa evoluir indefinidamente sem que a mera ação de alterar os dados de um cadastro, como no exemplo, exploda o tamanho do seu serviço de alteração, se ele é de alteração ele deve estritamente, unicamente, haja o que houver alterar o cadastro e nada mais.

Para finalizar, outro benefício dessa abordagem é que ela permite começar a extrair um contexto de um sistema monolítico de forma gradual, de tal forma que aos poucos as regras de negócio referentes ao contexto que deseja extrair possam começar a serem executados em outro local.