Dívida tecnica Code smeells (pistas de problemas): Repetição de códigos
Experiência de outros devs: Patterns Princípios S.O.L.I.D
Metodos e classes devem ter uma unica responabilidade (coesos)
Ao escrever um módulo de software você precisa garantir que quando as mudanças forem solicitadas, elas só originem de uma pessoa ou grupo de pessoas representando uma função de negócio específica.
Como analiso as dependências de uma classe? Vendo quais metodos e propriedades ela usa de outras classes
Qual a diferença entre acoplamento bom e ruim? bom dificilmente vai ser alterado
O que são classes instáveis? classes que dependem de classes que podem ser alteradas e dependem de classes que dependem de outras classes
Que estratégias utilizo para minimizar os acoplamentos ruins?
De que maneira o AspNet Core ajuda a minimizar o acoplamento de nossos controladores e tipos em geral?
Crie abstrações e dependa delas para melhorar a qualidade do acoplamento. Esse hábito é formalizado através do Princípio da Inversão das Dependências (DIP), a letra D na sigla S.O.L.I.D.
Explicite as dependências de uma classe. Uma das maneiras de fazer isso é usando parâmetros do construtor. Desse jeito aplicamos um conceito chamado Injeção de Dependência (DI). AspNet Core ajuda a injetar as dependências que foram vinculadas no método ConfigureServices() da classe Startup e assim dizemos que o AspNet Core tem como uma de suas principais funcionalidades ser um container de injeção de dependências.
Quando a classe dependente deixa de resolver as dependências diretamente e cede esse controle para outrém temos o uso do conceito Inversão de Controle (IoC)
Mantenha sua aplicação fechada para mudanças, mas aberta para extensões
Sempre manter o habito de criar novas classes quando quiser alterar algo
Service Layer uma camada arquitetural que separa as regras de negócio das camadas mais externas
Decorator - Uma classe nova chama a antiga com exceção das novas funcionalidades - https://en.wikipedia.org/wiki/Decorator_pattern
Manter a coesão entre interfaces
Sempre cumprir as promessas das implementações (LSP)
Não implemente funcionalidades que ainda não foram solicitadas! Essa idéia foi cunhada no acrônimo Y.A.G.N.I., You Aint Gonna Need It.
Sempre que possível busque separar as operações das interfaces em grupos menores. Essa idéia é o Princípio da Segregação das Interfaces (ISP)
CQRS (em português)
SRP. classes e métodos devem ter alta coesão
OCP. mantenha seu projeto aberto a mudanças mas fechado a alterações
LSP. cumpra as promessas definidas nas abstrações
ISP. preocupe-se com coesão e acoplamento em suas interfaces
DIP. dependa de abstrações ao invés de classes concretas
