17. Fronteiras: Estabelecendo Limites
Linhas separam o que importa dos detalhes. Detalhes viram plugins.
Resumo
- Fronteiras separam elementos e impedem que um conheça o outro. Traçadas cedo, mas decisões de detalhe adiadas.
- Acoplamento prematuro (ex.: três camadas com servidores, ORM, rede) drena recursos. Caso W e P.
- Caso FitNesse: abstração de banco permitiu adiar banco por 18 meses e trocar por arquivos.
- Trace linhas entre o que importa (regras) e o que não importa (GUI, banco). Interface do lado das regras.
- Arquitetura de plugins: banco e GUI plugam nas regras. Eixos de mudança diferentes = fronteira (SRP).
Perguntas-chave
responda de cabeça, depois abraOnde traçar uma fronteira?
Entre coisas que importam e coisas que não importam: regras de negócio de um lado; GUI, banco, IO do outro.
Para que lado aponta a dependência na fronteira banco/regras?
Do banco para as regras. As regras definem a interface; o acesso a banco a implementa.
Qual o custo de fronteiras prematuras e erradas?
Infraestrutura desnecessária (servidores, ORMs, serviços) que atrasa o desenvolvimento sem valor.
Exercícios de fixação
0/5 respondidas1.
Em uma fronteira entre regras de negócio e banco de dados, a interface
DatabaseInterface deve ficar:2.
Por que o autor considera a GUI um plugin?
3.
A empresa W adotou servidores de aplicação, objetos de domínio e rede antes de ter necessidade. Qual o resultado?
4.
Qual princípio sustenta traçar fronteiras entre coisas que mudam em ritmos e motivos diferentes?
5.
Qual o benefício central de tratar banco e GUI como plugins?