DEV Community: Rogério Marinho

3 dicas para melhorar seu código orientado a objetos

Rogério Marinho — Mon, 12 May 2025 09:45:03 +0000

Introdução

Um dos maiores desejos dos desenvolvedores é escrever um código correto e manutenível. Ao longo dos anos, a comunidade juntou um conjunto de ideias, heurísticas e padrões de solução a problemas recorrentes. Este texto tem como objetivo mostrar algumas dicas para tornar seu código mais testável, claro e coeso.

Lógica sobre o estado de objetos

Digamos que você está escrevendo um sistema de biblioteca e que em determinados momentos é necessário saber o estado de um empréstimo para a execução de determinada lógica. Poderíamos fazer algo do tipo:

if(emprestimo.DataDeDevolução > DateTime.Now)
{
    EnviarEmailDeAtraso();
}

Será que teria algum problema nisso? Podemos pensar em alguns:

E se essa lógica for necessária em outras partes do sistema? Pensando nas bases da orientação a objetos, comportamentos devem estar pertos dos dados que utilizam. Logo, a coesão das partes do sistema está prejudicada. Além da repetição de código desnecessária, risco de cometer algum erro como usar um maior ou igual (≥) ao invés de um maior (>).
Como seriam os testes? Por enquanto, não é possível testar esse estado isoladamente, o que pode causar redundância de testes em outras classes. Caso seja uma necessidade, também não é possível testar com outras datas, apenas DateTime.Now.

A partir dessas informações, como poderíamos melhorar esse código? Uma sugestão:

if(emprestimo.ExpiradoEm(DateTime.Now))
{
    EnviarEmailDeAtraso();
}

public bool ExpiradoEm(DateTime dateTime)
{
    return emprestimo.DataDeDevolução > dateTime;
}

ou até:

public bool Expirou()
{
    return emprestimo.DataDeDevolução > DateTime.Now;
}

Lógica sobre o estado de uma lista

Continuando no contexto de empréstimo de livros, digamos que precisamos saber algumas informações sobre os empréstimos de determinado usuário:

Quantos empréstimos estão abertos?
Quais empréstimos expiram nessa semana?
O usuário pegou algum livro com um título específico?

Poderíamos fazer algo semelhante a:

public class Usuario
{
  //Essa lista é inicializada no construtor
    public List<Emprestimo> Emprestimos;

    public Usuario()
    {
        Emprestimos = new List<Emprestimo>();
    }
}

Usuario user = new Usuario();
//Neste momento a lista de empréstimos possui n elementos.

//Quantos empréstimos estão abertos?
int quantidadeDeEmprestimosAbertos = 
user
  .Emprestimos
  .Count(x => !x.Expirou());

//Quais empréstimos expiram nessa semana?
DateTime daquia6dias = DateTime.Now.AddDays(6);
DateTime daquia7dias = DateTime.Now.AddDays(7);
List<Emprestimo> = emprestimosQueExpiramEssaSemana =
user
    .Emprestimos
    .Where(x => !x.ExpiradoEm(daquia6dias) && x.ExpiradoEm(daquia7dias))
    .ToList();

//O usuário pegou algum livro com um título específico?
bool jaPegouEsseLivro =
user
  .Emprestimos
    .Any(x => string.Equals(x.Titulo, "Refatoração"));

Quais problemas identificamos no código acima? Os mesmos problemas que vimos anteriormente, mas focados em uma coleção. No final das contas, a lista de empréstimos também é tem um sentido coeso pro domínio. Seguindo as ideias já comentadas, uma sugestão de solução seria:

public class TodosEmprestimos
{
    private List<Emprestimo> _emprestimos;

    public int NumeroDeAbertos()
    {
        return _emprestimos.Count(x => !x.Expirou());
    }

    public List<Emprestimo> EmprestimosQueExpiramEm(DateTime expiracao)
    {
      DateTime umDiaAntesDaExpiracao = expiracao.AddDays(-1);
    return _emprestimos
                            .Where(x => !x.ExpiradoEm(umDiaAntesDaExpiracao) && x.ExpiradoEm(expiracao))
                            .ToList();
    }

    public bool PegouLivro(string titulo)
    {
        bool PegouEsseLivro = _emprestimos.Any(x => string.Equals(x.Titulo, titulo));
    }
}
public class Usuario
{
  public TodosEmprestimos Emprestimos;

    public int NumeroDeEmprestimosAbertos()
    {
        return Emprestimos.NumeroDeAbertos();
    }

    public List<Emprestimo> EmprestimosQueExpiramEmUmaSemana()
    {
        DateTime daquia7dias = DateTime.Now.AddDays(7);
      return EmprestimosQueExpiramEm(daquia7dias);
    }

    public bool PodePegarEsseLivro(string titulo)
    {
        return !Emprestimos.PegouEsseLivro(titulo);
    } 
}

Ganhamos coesão, reusabilidade e testabilidade. Outro ponto: se quiséssemos impor uma estrutura de dados específica pra coleção por uma demanda de negócio, o código estaria alinhado as necessidades do mundo real. Por exemplo, se precisássemos que os empréstimos estivessem ordenados pelo tempo, o encapsulamento como uma classe permitiria mais facilmente.

Tipo primitivo com significado para o domínio

A última dica vai mostrar como trazer o domínio para mais perto do código. Muito provavelmente, nosso sistema de biblioteca precisa guardar o CPF do usuário. Como o documento transita pelo sistema? Um campo string na classe usuário? A partir do que já comentamos, quais os prováveis problemas dessa abordagem?

public Usuario
{
    public string CPF {get; private set;}
}

Possível resposta: Dificuldade de validação, menos focalização pros testes, menos coesão, etc.

Como podemos melhorar isso? Se criarmos uma classe para representar esse conceito, podemos ter certas vantagens.

public CPF
{
    private string cpf;

    private CPF(string cpfValido)
    {
        cpf = cpfValido;
    }

    public static CPF Create(string cpf)
    {
        //aqui estaria o algoritmo de validação
        if(isValid(cpf))
        {
            return CPF(cpf);    
        }

        throw new ArgumentException("CPF informado inválido");
    }

    public string EmTextoLimpo()
    {
        return cpf;
    }
}

public User
{
    public CPF cpf {get; set;}
}

Agora com uma classe, podemos fazer diversos testes para o algoritmo aqui nessa classe, a validação está isolada e, por fim, aumentamos a coesão do conceito de CPF. O ponto de atenção a se levar em conta é a facilidade de verificar tal comportamento em tempo de execução com o que a linguagem/framework já disponibiliza, ou seja, se é muito fácil fazer essa verificação usando algum recurso nativo talvez não valha a pena criar um nova classe, cabe a análise.

Conclusão

A programação orientada a objetos nos traz a possibilidade de criar códigos coesos, modulares e encapsulados. Contudo, isso não vem de graça, é necessária a utilização das boas práticas e de uma reflexão se estamos fazendo nosso código OO da melhor forma. Este texto foi inspirado e baseado no módulo de heurísticas para orientação objetos da Jornada Dev+Eficiente. Por fim, avalie se as dicas que passei fazem sentido para seu código. Obrigado!

Estruturas de Dados Básicas com exemplos em C#

Rogério Marinho — Sun, 20 Apr 2025 13:31:58 +0000

Introdução

Uma das principais necessidades de sistemas computacionais é guardar dados e operar sobre eles. Além disso, a quantidade a se guardar e número de operações feitas é bastante considerável. Imagine quantos dados são gerados durante o seu uso nas redes sociais, portanto, é vital entender como fazê-lo eficientemente. Nesse sentido, temos diferentes maneiras de organizar os dados para determinado fim, o que chamamos de estrutura de dados.

Diferentes estruturas de dados são mais performáticas em diferentes cenários. Vamos ver as mais importantes e saber o momento certo de usar cada uma. E, para tornar mais concreto, veremos exemplos de cada uma na linguagem C#.

Arrays e Matrizes

Comecemos pelo mais simples. Array é uma coleção de elementos do mesmo tipo. Podemos acessar, ou modificar, um elemento pelo seu índice, ou sua ordem, no array. Mais comumente criado quando sabemos exatamente o tamanho que o array precisa ter. Já em C#, podemos criar um array de tamanho constante ou de acordo com o valor de alguma variável. Uma coisa bem importante é que o acesso à qualquer elemento de um array é muito rápido. Exemplos:

int[] NewArray(int n)
{
    int[] array = new int[n];
    return array;
}

int[] array = new int[3];

int[] outroArray = {1, 2, 3, 4};

for(int i = 0; i < 4; i++)
{
  //Acessando o valor a partir do índice
    Console.WriteLine(outroArray[i]);
}

outroArray[3] = 99;

for(int i = 0; i < 4; i++)
{
  //Acessando o valor a partir do índice
    Console.WriteLine(outroArray[i]);
}

//Acessar um elemento que não existe gera uma exceção
//outroArray[4] = 100;

Em seguida, temos as matrizes. Basicamente, são arrays multidimensionais. Cada posição do array é um novo array. A ideia é a mesma do array.

int[,] matrix = new int[2,2];
matrix[0, 0] = 1;
matrix[0, 1] = 2;
matrix[1, 0] = 3;
matrix[1, 1] = 4;

for (int i = 0; i < 2; i++)
{
    for (int j = 0; j < 2; j++)
    {
        Console.WriteLine(matrix[i,j]);
    }
}

Também temos os jagged arrays. Podem ser entendidos como arrays de arrays. Cada array pode ter um array de tamanho n.

int[][] jaggedArray = new int[3][];

jaggedArray[0] = [1, 3, 5, 7, 9];
jaggedArray[1] = [0, 2, 4, 6];
jaggedArray[2] = [11, 22];

int[][] jaggedArray2 =
[
    [1, 3, 5, 7, 9],
    [0, 2, 4, 6],
    [11, 22]
];

Fonte: The array reference type - C# reference | Microsoft Learn

Listas e Listas Ligadas

Com os arrays temos uma certa inflexibilidade, pois devemos saber já de cara qual o tamanho que será necessário, mas e nos casos que não sabemos quantos itens iremos guardar, ou se a quantidade irá mudar durante a execução? Para isso temos as listas e listas ligadas.

Listas permitem adicionar elementos com facilidade. O acesso também é rápido, semelhante aos arrays. Por debaixo dos panos, listas, no geral, são implementadas com arrays. Quando se necessita de mais espaço, é alocado um novo array com o dobro de tamanho e todos os elementos são copiados para essa nova estrutura, o que torna a operação mais lenta que o comum. Para remoção, é necessário encontrar o elemento, seja percorrendo ou acessando o índice, e reorganizando os elementos à direita. Similarmente, para encontrar um elemento, sem saber o índice, é necessário percorrê-lo, gastando-se tempo proporcional ao tamanho da lista.

List<int> lista = new List<int>();

lista.Add(1);
lista.Add(2);
lista.Add(3);

Console.WriteLine($"Imprimindo a lista após as inserções");
lista.ForEach(Console.WriteLine);

lista.Insert(1, 99);

Console.WriteLine($"Imprimindo a lista após a inserção do 99");
lista.ForEach(Console.WriteLine);

bool exists = lista.Contains(4);
Console.WriteLine($"O número 4 existe na lista? {exists}");

lista.Remove(1);

Console.WriteLine($"Imprimindo a lista após a remoção do elemento 1");
lista.ForEach(Console.WriteLine);

Já listas ligadas permitem uma adição, remoção e busca mais flexível, mas com um custo de tempo associado. No geral, as operações são mais lentas que as operações numa lista. Por que isso acontece? Vejamos nessa imagem:

Fonte: Lista ligada – Wikipédia, a enciclopédia livre

Uma lista ligada é formada por diversos nós, em cada nó só conhece o próximo vizinho. Temos um campo conhecido como cabeça da lista(do inglês head), que aponta para o primeiro elemento da lista. A partir dessa informação conseguimos entender a causa da dita lentidão em relação à lista: Para adicionar um elemento precisamos percorrer todos os elementos da lista até encontrar um nó que não possui o próximo vizinho. Imagine uma lista ligada com 999 999 elementos, para adicionar o milionésimo, deve-se percorrer todos eles para ao fim ser possível adicioná-lo. Para remoção e acesso, segue o mesmo raciocínio.

Inclusive, existe a lista duplamente ligada, em que cada nó conhece o vizinho anterior e o próximo. E também temos a cabeça e o a cauda(do inglês tail) da lista, facilitando as operações nos cantos da lista.

Em C# a LinkedList é implementada como uma lista duplamente ligada. Além disso, podemos inserir um nó diretamente antes ou após outro nó. O que permite uma inserção rápida quando já tem o nó, mas por outro lado, encontrá-lo necessita de uma busca proporcional ao tamanho da lista. A remoção também é feita dessa forma.

LinkedList<int> listaLigada = new LinkedList<int>();

//Adiciona no início da lista
listaLigada.AddFirst(1);

//Adiciona no fim da lista
listaLigada.AddLast(2);
listaLigada.AddLast(3);

//Imprimindo a lista após as inserções
Console.WriteLine($"Imprimindo a lista após as inserções");
ImprimirListaLigada(listaLigada);

var firstNode = listaLigada.First;
listaLigada.AddAfter(firstNode, 99);

Console.WriteLine($"Imprimindo a lista após a inserção do 99");
ImprimirListaLigada(listaLigada);

bool exists = listaLigada.Contains(4);
//se não encontrar o node, será nulo
var node = listaLigada.Find(4);

Console.WriteLine($"O número 4 existe na lista? {exists}");

listaLigada.Remove(1);
listaLigada.RemoveFirst();

Console.WriteLine($"Imprimindo a lista após a remoção do elemento 1 e o primeiro elemento da lista");
ImprimirListaLigada(listaLigada);

void ImprimirListaLigada(LinkedList<int> listaLigada)
{
    foreach (int node in listaLigada)
    {
        Console.WriteLine(node);
    }
}

Conjuntos e Dicionários

Vamos agora para algumas estruturas de dados mais interessantes para verificação da existência ou não de elementos numa coleção e armazenamento de valores com identificadores.

Primeiramente, os conjuntos são estruturas de dados que guardam elementos únicos. A determinação de unicidade de um elemento é feito por um cálculo de hash, função matemática complicada que gera idealmente um valor único para cada valor de entrada. Normalmente, esse cálculo é feito rapidamente. Então, ao inserir um elemento no conjunto, o hash será calculado e, não havendo repetição, o elemento será inserido. A remoção segue a mesma lógica. Ambos são rápidos.

A partir disso, é perceptível o porquê do conjunto ser uma estrutura de dados interessante quando temos problemas que precisem de unicidade ou verificação se certo elemento está presente: é muito eficiente realizar tal operação.

Comparando as listas com os conjuntos, naqueles o tempo de operação de adição, remoção e busca é proporcional ao tamanho, já nos últimos é um tempo constante - duração do cálculo.

HashSet<int> set = new HashSet<int>();
set.Add(1);
set.Add(2);
set.Add(3);
ImprimirConjunto(set);

Console.WriteLine($"Tentando adicionar 3 no conjunto");
bool added = set.Add(3);

Console.WriteLine($"O valor 3 foi adicionado no conjunto? {added}");
ImprimirConjunto(set);

bool contains = set.Contains(1);
Console.WriteLine($"O valor 1 existe no conjunto? {added}");

void ImprimirConjunto(HashSet<int> conjunto)
{
    Console.WriteLine("{ " + string.Join(" ", conjunto) + " }");
}

Também estão presentes métodos de operações de conjuntos matemáticos, como UnionWith - para união, IntersectWith - para interseção, ExceptWith - para subtração, dentre outros. Sugiro a leitura da documentação para saber mais.

Em seguida, temos os dicionários, que funciona de forma muito semelhante aos conjuntos. A diferença é o dicionário guarda um par de chave e valor. A chave é o identificador do elemento. Aqui também temos o uso da operação de hash, onde age sobre a chave. Ou seja, um elemento será adicionado se a chave não existir. Será removido apenas se a chave existir. E, por fim, será encontrado a partir de sua chave.

Dictionary<string, string> timesEstadios = new Dictionary<string, string>();

timesEstadios.Add("Flamengo", "Maracanã");
timesEstadios.Add("Botafogo-PB", "Almeidão");
timesEstadios.Add("Sport", "Ilha do Retiro");
timesEstadios.Add("Fluminense", "Maracanã");

Console.WriteLine("Times e estádios como mandante");
ImprimirDicionário(timesEstadios);

Console.WriteLine("\n\n");
try
{
    //Adicionar um elemento que já existe causa exceção
    Console.WriteLine("Tentativa de adicionar o Botafogo-PB");
    timesEstadios.Add("Botafogo-PB", "Almeidão2");
}
catch
{
    Console.WriteLine("Tentativa de adicionar elemento que já existe");
}

Console.WriteLine("\n\n");

bool added = timesEstadios.TryAdd("Souza", "Marizão");
if (added)
{
    Console.WriteLine("Sousa adicionado");
}
else 
{
    Console.WriteLine("Sousa não foi adicionado");
}

//Semelhate a fazer desta forma
if (!timesEstadios.ContainsKey("Sousa"))
{
    Console.WriteLine("Sousa não está no dicionário, vamos adicionar");
    timesEstadios.Add("Sousa", "Marizão");
}

Console.WriteLine("\n\n");
Console.WriteLine("Qual estádio do Sport?");
if (timesEstadios.TryGetValue("Sport", out string estadioDoSport))
{
    Console.WriteLine($"Estádio: {estadioDoSport}");
}
else
{
    Console.WriteLine("Sport não está na lista, então não sei.");
}

Console.WriteLine("\n\n");
timesEstadios.Remove("Fluminense");
ImprimirDicionário(timesEstadios);

void ImprimirDicionário(Dictionary<string, string> dicionario)
{
    foreach (var item in dicionario)
    {
        Console.WriteLine($"Time: {item.Key}, Estádio: {item.Value}");
    }
}

Por baixo dos panos, ambas usam arrays como estrutura básica para armazenar os dados. Isso acontece por que a função hash indica idealmente um valor único. Esse valor é usado como índice no array principal, definindo onde o elemento será armazenado.

Um exemplo simples seria um função hash a seguir:

int[] arrayInterno;
int Hash(int n)
{
    //Irá retornar um valor entre 0 e o tamanho do array - 1
    return n % arrayInterno.Length;
}

Nesse sentido, uma boa função hash minimiza a colisão entre entradas diferentes. Mas caso aconteçam, é preciso tratá-las. Exemplos disso seriam:

Adicionar no próximo índice
Cada elemento ser também uma lista/array para adicionar as possíveis colisões.

Além disso, é importante que a estrutura também tenha espaço suficiente para guardar os elementos. Quando não há mais espaço, uma nova é alocado e os valores são copiados para o ele.

Filas e Pilhas

Esta estrutura de dados é bem semelhante a uma fila na vida real. Pessoas chegam na fila do supermercado, a que está na frente é atendida primeiro. Depois a segunda é atendida e assim por diante. Temos uma estrutura em que os elementos processados e descartadas são sempre o que estão na primeira posição.

A adição sempre é feita no fim da fila, o que é bem rápido. A remoção também é bem rápida e sempre feito do começo. Já a busca dura proporcionalmente ao seu tamanho. A fila é implementada como um array circular que permite que velocidade

Queue<int> numeros = new Queue<int>();
numeros.Enqueue(1);
numeros.Enqueue(2);
numeros.Enqueue(3);

Console.WriteLine("Inicialmente:");
foreach (var num in numeros)
{
    Console.WriteLine(num);
}

Console.WriteLine("\n");

Console.WriteLine($"Qual o primeiro elemento? {numeros.Peek()}");

Console.WriteLine("\n");

//também retorna o que foi retirado da fila
numeros.Dequeue();

Console.WriteLine("Por fim:");
foreach (var num in numeros)
{
    Console.WriteLine(num);
}

Por fim, mas não menos importante, temos a pilha. Essa estrutura é semelhante a fila. O que muda é a inserção que acontece no topo da pilha. A remoção também é no início. Em termos de velocidade, igual à fila. Por debaixo dos panos, é implementada como uma lista.

Stack<int> numeros = new Stack<int>();
numeros.Push(1);
numeros.Push(2);
numeros.Push(3);

Console.WriteLine("Inicialmente:");
foreach (var num in numeros)
{
    Console.WriteLine(num);
}

Console.WriteLine("\n");

Console.WriteLine($"Qual o primeiro elemento? {numeros.Peek()}");

Console.WriteLine("\n");

//também retorna o que foi retirado da fila
numeros.Pop();

Console.WriteLine("Por fim:");
foreach (var num in numeros)
{
    Console.WriteLine(num);
}

Conclusão e Referências

Este foi uma introdução a um tema bastante exigidos dos desenvolvedores de software. Gostaria de esclarecer que em determinados momentos fui vago em relação à velocidade das operações, pois não quis introduzir também o assunto de análise de algoritmos e Notação O Grande. Possivelmente, posso trazer isso em futuros artigos. Recomendo pra quem interessou buscar mais sobre.

Baseei meu artigo nas aulas que assiste na universidade, na documentação da Microsoft(https://learn.microsoft.com/en-us/dotnet/standard/collections/) e também no curso de Coding Interview feito por Maurício Aniche na Jornada Dev+Eficiente.

Obrigado e até mais!

Como entender o negócio, ou Padrões Estratégicos de DDD

Rogério Marinho — Mon, 07 Apr 2025 11:38:56 +0000

Um grande marco para a indústria de software foi a publicação de “Domain-Driven Design: Atacando as complexidades no coração do software” de Eric Evans, 2003, o qual trazia a ideia de que o funcionamento do negócio deveria guiar o desenvolvimento do software.

O livro de Evans é também conhecido por ser de difícil leitura e por isso outras obras foram publicados com a intenção de transmitir as ideias de Domain-Driven Design para o público leigo. Um desses livros é “Aprenda Domain-Driven Design: Alinhando Arquitetura de Software e Estratégia de Negócios” de Vladimir Khononov. O conteúdo presente no texto de Khononov será aqui resumido em 3 posts. Cada post aborda uma seção do livro. A primeira seção, assunto deste post, aborda uma visão de entendimento do negócio a partir de padrões, ditos estratégicos.

Análise do negócio

O foco de DDD é a produção de um sistema de software que seja organizado a partir de um entendimento da empresa. Logo, para iniciarmos, é necessário entender qual a área de atuação da empresa. Vendas? Segurança? Transporte? Qual o domínio que a empresa atua?

Podemos dar mais um passo em direção do entendimento da organização ao pensar em como as partes se organizam para formar um todo coeso. Pela teoria do DDD, o domínio se divide em 3 partes: principal, suporte e genérico.

Subdomínio Principal

Este é a causa dos ganhos financeiros da empresa. Qual é o diferencial da empresa? Onde está a vantagem da empresa ante as outras? Qual a complexidade que a empresa entrega com simplicidade para o cliente?

O diferencial da empresa é onde estão os esforços de desenvolvimento e pesquisa. É uma solução desenvolvida pela própria empresa.

Imagine uma empresa de venda de produtos online. O marketplace, a negociação dos produtos é o subdomínio principal.

Subdomínio de Suporte

Neste subdomínio estão as áreas de base para os subdomínios principais. Normalmente, esta área é complexa demais para que existam soluções prontas e, por isso, faz-se necessário a produção pela própria empresa. Além disso, a lógica de negócio desse subdomínio não é complexa. Por não serem áreas críticas, provavelmente, não recebem tanto investimento quanto as principais. Podemos pensar em setores que produzem bibliotecas internas não críticas para outras equipes da empresa.

Subdomínio Genérico

Aqui estão os subdomínios que todas as empresas fazem igual, não há realmente vantagem competitiva. No mercado, existem soluções prontas que já satisfazem a necessidade da organização, em termos funcionais e financeiros. Um exemplo seria a utilização de sistema de gerenciamento de RH. Vale ressaltar que, para a empresa que vende o software, esse seria um subdomínio principal, mas para todas as outras é um subdomínio genérico.

Comparando os tipos de subdomínio

Em linhas gerais, podemos dizer que:

O subdomínio principal é a fonte de diferenciação do negócio frente outras empresas, além de possuir uma complexidade alta de desenvolvimento.

Especialistas de domínio

O subdomínio genérico não é fonte de diferenciação pro negócio, muitas empresas já o fazem. A complexidade pode ser alta, mas como já existe uma solução pronta que satisfaz as necessidades, utilizasse ela mesmo.
O subdomínio de suporte é fonte de diferenciação e é complexo.

O conhecimento sobre o negócio não está presente somente na estrutura da empresa, mas, obviamente, inclui as pessoas, principalmente, os chamados “Especialistas de Domínio”, pessoas que trabalham e vivem o dia a dia do negócio. A partir delas, os engenheiros conseguem entender e derivar os principais casos de uso, regras e necessidades para o negócio consiga fluir.

Linguagem ubíqua

No método tradicional de desenvolvimento, especialistas de domínio traduzem o funcionamento esperado do software em um documento de requisitos que será analisado pelas pessoas responsáveis pelo desenvolvimento da solução. Na prática, ocorre um transformação do conhecimento em diversas formas, o que pode levar a perdas de informações que afetarão o funcionamento do sistema.

Pensando neste problema, o DDD traz um padrão de comunicação chamado linguagem ubíqua. O time de desenvolvimento deve estar conectado e em estreita comunicação com os especialistas internalizando seus modelos mentais. Isso significa internalizar e, por consequência, utilizar o mesmo vocabulário que o negócio em todos os lugares possíveis, como em conversas entre engenheiros, nas documentações, nos testes e no código. Vocabulário o qual precisa ser o mais objetivo e claro possível, sem ambiguidades. E quanto mais complexo o negócio, mais necessário e recorrente deve ser os encontros entre os times.

Contextos delimitados e como se relacionam

A partir da utilização e absorção da linguagem ubíqua pelos desenvolvedores, certo problema começa a aparecer: os especialistas utilizam termos semelhantes com definições distintas ou termos diferentes com a mesma definição. As conversas de negócio conseguem se desenrolar sem muitos problemas mas os engenheiros ficam sem entender. As reuniões possuem continuidade, pois os especialistas entendem o contexto em que o jargão é utilizado.

Como consequência, para o software se alinhar com o negócio, a solução de software será seccionada em conjuntos coesos. Isso pode lembrar os domínios mencionados acima, mas neste a seção será feito de forma consciente, será uma escolha dos desenvolvedores. Tais conjuntos são chamados pela teoria de Contextos Delimitados. São os projetos que os desenvolvedores modelam o(s) domínio(s). E como qualquer modelo, há diferença nos níveis de detalhe necessários para a correta implementação e funcionamento da solução.

Os contextos delimitados podem ser vistos como os projetos, repositórios, da empresa. Cada contexto deve ser cuidado por apenas 1 equipe e 1 equipe pode cuidar de mais de 1 contexto delimitado.

Pensando em como os contextos irão se comunicar, existem algumas estratégias: cooperação, cliente-fornecedor e caminhos separados.

Cooperação

A relação cooperativa entre contextos delimitados se dá pelo uso mútuo de certa modelagem/API mas em que o desenvolvimento é responsável por uma equipe. As mudanças são gerenciadas de forma livre. Espera-se que não haja conflitos para que seja possível o desenrolar do desenvolvimento da solução.

Outra forma de cooperação é de escopo compartilhado, o qual 2 ou mais equipes compartilham o desenvolvimento e uso de uma mesmo núcleo de modelagem. Alterações afetam imediatamente os contextos que a utilizam. Em certo sentido, isso quebra a ideia de contextos delimitados bem definidos e independentes. Por isso, é mais utilizado quando o preço da duplicação de conhecimento é mais caro que o trabalho de integração entre as equipes.

Cliente-Fornecedor

Basicamente, fornecedor é o contexto que mantém e distribui a interface, também dito ascendente. Já o cliente, utiliza a interface, também conhecido como descendente. As abordagens se dividem da seguinte forma.

Conformista

No padrão conformista, o cliente aceita e se adapta às mudanças feitas pelos fornecedores das API. Isso acontece quando, por exemplo, há conexão com bibliotecas de fora da organização. Para se proteger quanto a mudanças na interface pública, uma Camada de Anti-Corrupção é utilizada.

Serviço de host aberto

Neste padrão, a hierarquia inverte e o produtor não pode modificar a seu bel prazer. Uma prática para maximizar a proteção ao cliente é o uso de uma interface pública que caminha em um ritmo diferente da implementação interna.

Caminhos separados

Pode ser necessário que os contextos não se comuniquem. Normalmente, pela dificuldade de integração entre equipes. Mas, também, por necessidade de negócio:

Talvez seja mais simples de integrar uma solução já existente em cada contexto delimitado, como por exemplo, uma biblioteca de log.
Os modelos são tão diferentes que não faz sentido a integração.

Esse padrão deve ser evitado em integração de subdomínios principais, pois isso diminuiria efetividade e otimização do desenvolvimento das ideias de negócio.

Conclusão

DDD é um assunto amplo, muito discutido e complexo, logo esse post é uma introdução de um conhecimento que ajuda a sistematizar o entendimento e tradução do negócio para o mundo tecnológico. Nos próximos post, abordarei sobre os padrões estratégicos e outros temas do livro. Até mais!