Domain Driven Design

Domain Driven Design

Por Eric Evans

Todo software corporativo resolve problemas de negócio. E nada melhor do que o código fonte falar a mesma linguagem dos negócios em vez de tentar reinventar a roda com jargões e termos que não serão compreendidos pelas pessoas de negócios. Este livro ensina a criar uma linguagem comum entre desenvolvedores e usuários, e a pensar no design do código de uma maneira que favoreça o entendimento e a evolução do software através de padrões que colocam em primeiro lugar o domínio de negócio.

Versão em Inglês http://amzn.to/2DYqGe6 ou Português http://amzn.to/2Ds1EmJ

Domain-Driven Design – Resumo

Filosofia – filo (amor), sofia(sabedoria) – O software tem que ser importante para você.

Tracking complexity – O software não precisa ser complexo.

Heart of Software / Core Domain – O que faz as pessoas usarem o seu software e não usarem outro.

Domain – Tudo que compreende o software. Alinhamento com o negócio. Isolamento entre domínio. Reutilização. Mínimo acoplamento. Independente de tecnologia.

Modelo – é um gráfico

Domain model – A representação de uma domain.

Modelar um domínio – abstrair o que não é necessário, e focar no que é interessante.

Problemas de Comunicação – Fazemos presunções o tempo todo. Você acha que entendeu, mas não entendeu.

Ubiquitous Language – Existem um vocabulário em cada mercado. Por exemplo em um imobiliária.

Literate Programming –  When/Given/Then – BDD

Status quaestionis – Public request (PR), commit message etc.