> Seria esse um princípio para ser aplicado de forma retroativa? Identificar que uma classe irá sofrer múltiplas mudanças, que causaram problemas em diferentes partes do programa que a utilizam, antes que esses problemas ocorram não me parece factível. Mas pode ser só a minha falta de experiência em uma empresa de fato.

Aí nós podemos falar de arquitetura evolutiva. Basicamente, você precisa aumentar a complexidade do seu software de acordo com a demanda. De igual forma, você precisa cuidar para que o software esteja flexível o suficiente para suportar modificações. Isso quer dizer que você não precisa partir de uma solução completamente desacoplada. Principalmente se você não tem visão de pra onde o sistema vai evoluir. Você caminha com o que conhece e refatora durante o caminho.

DETALHE: refatorar código SEMPRE será preciso; especialmente para diminuir a entropia do design da sua aplicação.

Espero ter ajudado. E desculpe pela demora 🙂

> Não é ruim ter múltiplas classes representando uma mesma entidade, já que alguma parte do código pode ser compartilhado entre elas, de forma que uma alteração nessa parte compartilhada terá de ser repetida em todas essas classes?

Vai depender do modelo arquitetural que você está seguindo. Se você está implementando Micro serviços, não vejo problema. Mesmo porque, cada micro serviço saberia lidar apenas com a complexidade que lhe cabe, não reproduzindo uma função de outro serviço. O lote, no MS de performance, sequer teria os métodos relativos a qualidade.

Se você está implementando um monolito, SOA ou qualquer outro modelo, existem formas de reaproveitar código sim, mas em tese você deveria separar em namespaces diferentes e controlar a visibilidade dos métodos. Para um domínio não deveria acessar diretamente a interface do outro.

> Como os termos “motivo” e “responsabilidade” se encaixa nessa interpretação? Quero dizer, como “ter uma única responsabilidade” ou “apenas um motivo para mudar” pode significar algo como “estar sob um único domínio”.

Motivo é motivo mesmo. Ainda no nosso exemplo, se eu quero alterar a forma como eu calculo a performance de um lote, o módulo que calcula a qualidade não deveria sofrer alterações. Os atores envolvidos, muito provavelmente, não são os mesmos. E aqui não estou falando de usuários. Estamos mais próximos dos stakeholders.

A Classe lote, no domínio de performance, teve o motivo “alterar cálculo de performance” e no contexto de performance ela tem a responsabilidade de “calcular a performance deste lote”. Se for a mesma classe em qualidade, o domínio teria que ser recompilado e redeployado MESMO que nenhuma alteração para ele tenha sido solicitada.

Bom dia, Fernando. Ótima pergunta! A primeira coisa que eu preciso lembrar é que não existe bala de prata. Sei que é clichê, mas é que realmente toda decisão arquitetural/modelagem depende muito do contexto. Dito isto:

> Domínio é um sinônimo de departamento?

Dependendo do tamanho do negócio que você deseja modelar, pode até ser que, coincidentemente, os domínios e departamentos tenham uma relação 1×1. Mas não são sinônimos. Pense, por exemplo, numa empresa de contabilidade. Ela própria é um “departamento financeiro” de alguém, e mesmo assim pode ter vários domínios/sub-domínios.

A melhor forma de pensa em domínios, subdomínios e contextos é entendê-los como “ilhas de complexidade de negócio”. Por exemplo: Ao desenvolver um PCP, para um mesmo setor de uma linha de produção, você pode olhar para ela considerando várias frentes de complexidade. Entre elas: Performance, Qualidade, Manutenção, Segurança do trabalho e etc. Pensando no Operador, ele tem papéis distintos e funções distintas em cada um desses contextos (ou sub-domínios, como queira chamar). No contexto de performance, um operador não deveria conseguir gerar um pedido de manutenção – veja, estamos falando da complexidade e não da jornada do usuário em um sistema – bem como no contexto de Segurança do trabalho, não seria possível anotar o encerramento de um lote. Captou?

Abaixo eu deixo algumas delas. Caso algum leitor ou o autor do texto puder me ajudar a responder essas perguntas, eu agradeço de coração!

“Domínio” é um sinônimo de departamento?

Como os termos “motivo” e “responsabilidade” se encaixa nessa interpretação? Quero dizer, como “ter uma única responsabilidade” ou “apenas um motivo para mudar” pode significar algo como “estar sob um único domínio”.

Não é ruim ter múltiplas classes representando uma mesma entidade, já que alguma parte do código pode ser compartilhado entre elas, de forma que uma alteração nessa parte compartilhada terá de ser repetida em todas essas classes?

Seria esse um princípio para ser aplicado de forma retroativa? Identificar que uma classe irá sofrer múltiplas mudanças, que causaram problemas em diferentes partes do programa que a utilizam, antes que esses problemas ocorram não me parece factível. Mas pode ser só a minha falta de experiência em uma empresa de fato.