O design de um programa reflete as responsabilidades de cada parte dele, sejam arquivos, procedimentos, classes, funcoes, metodos, modulos ou qualquer outro nome dado para uma unidade dentro dele.
Em um programa orientado a objetos ele reflete as responsabilidades e o relacionamento entre diferentes classes que ao utilizarem recursos como encapsulamento e polimorfismo restringem esse relacionamento, reduzindo a fragilidade e aumentando a flexibilidade. Não importa qual seja o paradigma, não importa qual e o nome da estrutura, o design e a forma como vamos utiliza-las.
Relacoes na Orientacao a Objetos
Essas relacoes podem ser associacoes, dependencias ou heranca.
Associação: temos uma relação "has a", ou seja, variáveis de instância que fazem referência para outra classe ou interface.
class Contract {
customer: Customer;
}
Heranca: temos uma relação "is a", ou seja, uma classe herda de outra classe.
class CarLoan extends Loan {}
Dependência: parametros de um metodo que fazem referência para outra classe ou interface.
class Order {
code: string;
lines: Line[];
addProduct(product: Product, quantity: number) {
this.lines.push(new Line(product.idProduct, product.price, quantity));
}
}
Implementando Novas Responsabilidades
Conforme o programa amadurece, novas responsabilidades precisam ser implementadas. Por exemplo, persistir um pedido no banco de dados:
class OrderData {
save(order: Order) {
await connection.query("insert into order (code) values ($1)", [order.code]);
}
}
E se fosse necessario receber esse pedido de uma requisicao HTTP para depois persisti-lo? Essa classe iria interagir diretamente com OrderData? Quem seria responsavel por interagir com a classe Order para passar as informacoes da requisicao para a instância?
Viu quanta decisão podemos tomar? Da pra fazer o programa funcionar com ou sem associação, com ou sem heranca.
Design vs. Arquitetura
O que guia essas decisões? E o design ou a arquitetura?
Na prática, ambos.
Podemos definir que vamos utilizar o protocolo HTTP por padrao e compatibilidade, uma fila para trazer resiliencia, persistir em um banco de dados SQL ou NoSQL, utilizar containers em cloud providers como AWS ou Azure por portabilidade e custos, escolher Java ou Go por performance, ou React, Angular ou Vue por gosto da equipe. Existem diversas decisões que são decisões de arquitetura com foco em requisitos não funcionais como performance, segurança e compliance.
Isso afeta o design? Totalmente.
Cada decisão de arquitetura impoe restricoes ou desafios ao design. Ainda assim temos muita liberdade para definir quem tem qual responsabilidade dentro de um programa. Essa e uma decisão "aberta", que não tem necessariamente "certo ou errado" e por Isso é ao mesmo tempo causa inseguranca e nos desafia a apostar em um determinado caminho.
Quando falamos em Design Patterns, Domain-Driven Design, Clean Architecture, Ports and Adapters, SOLID principles, nada disso tem relação com Java ou Go, nem com Oracle ou MongoDB, nem com HTTP, nem com AMQP. E o simples fato de decidir quem faz o que dentro da estrutura que você criou, e Isso é o mais puro design, influenciado pela arquitetura.
Conclusão
Todo programa tem um design e a alternativa a um "bom" design e um "mau" design, não nenhum design.
Lembre-se, nosso desafio além de fazer tudo funcionar e fazer com que no médio e longo prazo seja possível continuar desenvolvendo o programa de forma saudavel, em um ritmo sustentavel, sem precisar fazer um esforco desnecessario, sem precisar passar semanas corrigindo defeitos ou reescrevendo tudo. Um bom design pode proporcionar tudo isso.