Parte I. Construir uma arquitetura para apoiar a modelação de domínios
A maioria dos programadores nunca viu um modelo de domínio, apenas um modelo de dados.
Cyrille Martraire, DDD EU 2017
A maioria dos programadores com quem falamos sobre arquitetura tem uma sensação incómoda de que as coisas podiam ser melhores. Muitas vezes, estão a tentar salvar um sistema que, de alguma forma, correu mal e estão a tentar colocar alguma estrutura de volta numa bola de lama. Sabem que a sua lógica empresarial não devia estar espalhada por todo o lado, mas não fazem ideia de como a corrigir.
Descobrimos que muitos programadores, quando lhes é pedido que concebam um novo sistema, começam imediatamente a construir um esquema de base de dados, sendo o modelo de objectos tratado como uma reflexão posterior. É aqui que tudo começa a correr mal. Em vez disso, o comportamento deve vir em primeiro lugar e orientar os nossos requisitos de armazenamento. Afinal, nossos clientes não se importam com o modelo de dados. Eles se importam com o que o sistema faz; caso contrário, eles usariam apenas uma planilha.
A primeira parte do livro analisa como construir um modelo de objeto rico através do TDD (no Capítulo 1) e, em seguida, mostramos como manter esse modelo dissociado das preocupações técnicas. Mostramos como construir código ignorante de persistência e como criar APIs estáveis em torno do nosso domínio para que possamos refatorar agressivamente.
Para tal, apresentamos quatro padrões de conceção fundamentais: ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access