Modelagem de domínios como construção de teorias 

Talysson Oliveira Software architect & Chief Learning Officer na Codeminer42 

codeminer42.com @codeminer42 

Peter Naur, 1985 "Programming as Theory Building" 

"[...] Programação deve ser considerada como a produção de um programa e determinados outros textos." "[...] Programação deve ser considerada apropriadamente como uma atividade onde a pessoa programadora forma ou encontra algum tipo de insight, uma teoria, sobre os assuntos em questão." VS 

O que é uma teoria? 

“ Uma pessoa que possui uma teoria […] sabe como fazer determinadas coisas e além disso pode sustentar o que é realmente feito com explicações, justificativas, e respostas a indagações sobre a atividade em questão "The Concept of Mind", Gilbert Ryle 

O que é realmente construído por quem programa? - Não é código, especificações e documentações, etc. - Uma teoria de como algumas questões do mundo são tratadas por um programa 

Convergência de ideias 

Convergência de ideias - O que Naur chama de "questões do mundo": - "a área em que o usuário aplica um programa" - "uma esfera de conhecimento, influencia ou atividade" - Esta é a definição de domínio no livro Domain-Driven Design (2003), de Eric Evans 

Domínio (Questões do mundo) Sistema de abstrações que descrevem aspectos específicos do domínio, e pode ser usado para resolver problemas relacionados ao domínio Avião (Domínio) Aeromodelo Modelo de domínio (Teoria) Aeromodelo 

Avião (Domínio) Aeromodelo (Modelo) Asa Trem de pouso Combustível Empuxo Assento Bagagem Cinto de segurança Luz de leitura Tripulação Pouso e Decolagem Radar Caixa-preta Finger - Relevância para o negócio - Presença em conversas: linguagem ubíqua - Regras de negócio associadas 

Código, especificações e documentação são transcendidos pelo conhecimento da pessoa programadora sobre a teoria em pelo menos 3 áreas — Peter Naur 

Código, especificações e documentação são transcendidos pelo conhecimento do time sobre o modelo em pelo menos 3 áreas 

Quem tem a teoria pode explicar como a solução se relaciona com as questões do mundo que ela ajuda a resolver 1 

Explicar como a solução se relaciona com o problema - Conhecer a teoria envolve entender como o domínio é representado no modelo - Conceitos são enraizados no conhecimento dos especialistas de domínio, destilando-o - O modelo não se expressa com texto, deve viver no conhecimento compartilhado do time 1 

Quem tem a teoria pode explicar porque cada parte do programa é como é 2 

Explicar o porque a solução é como é - Conhecer o modelo envolve sustentar a explicação de porque um conceito do domínio é representado da forma como é em código - Esta representação deve ser o mais alinhada com o modelo quanto possível - Isto tem um impacto muito importante no uso de design patterns em código de domínio 2 

Quem tem a teoria é capaz de responder construtivamente a qualquer demanda por modificação do programa para suportar as questões do mundo de uma maneira diferente 3 

Responder a mudanças - Um bom modelo acomoda elegantemente novos conceitos do mesmo domínio - Um código pode ser modificado sem seguir o modelo, mas causa o apodrecimento dele - Só faz diferença pra quem conhece a teoria - Refatoração do modelo impacta em refatoração do código, e isso é bom! 3 

A vida e morte de um modelo 

“ A construção de um programa é o mesmo que a construção da sua teoria pelo time e no time "Programming as Theory Building", Peter Naur 

A vida e morte de um modelo - A dissolução de um time marca a morte da construção de um programa - Código, documentação e especificações não são capazes de comunicar a teoria ou modelo - O modelo pode ser transmitido através de convivência do time antigo com o novo 

Programação não é sobre produzir texto 

“ [...] É importante ter um entendimento correto do que a programação é. Se o seu entendimento é incorreto, iremos entender errado as dificuldades que surgem na atividade e nossas tentativas de superá-las darão origem a conflitos e frustrações "Programming as Theory Building", Peter Naur 

Programação não é sobre produzir texto - Programar é sobre construir uma teoria, não sobre produzir o código do programa - A teoria é criada pelo time e no time - Não é possível obter a teoria sem participar desta atividade 

Programação não é sobre produzir texto - A forma que a teoria toma é influenciada por fatores técnicos, sociais, políticos, econômicos… - O código não contém a teoria - LLMs que produzem código não são capazes de construir e entender teorias - O que não quer dizer que não possam ajudar na tarefa de escrever código* 

Não é a primeira vez que várias dessas ideias se repetem 

"Programming as Theory Building" Peter Naur "Domain-Driven Design" Eric Evans 1985 2003 1986 "No Silver Bullet" Fred Brooks (Autor de The Mythical Man-Month) "Eu acredito que a parte difícil de construir software está na especificação, design e teste do construto conceitual, e não na tarefa de representar e testar a fidelidade das representações" 1990 "Designing C++ libraries" James M Coggins "[...] tem-se construído classes como listas encadeadas ou conjuntos (sets), em vez de classes como interfaces do usuário, ou feixe de radiação, ou modelo de elementos finitos. [...] Meus colaboradores oftalmologistas não se importam com pilhas (stacks), eles se importam com as descrições do formato polinomial de Legendre de córneas" 

Conclusões - Construa teorias: o entendimento de como e porque um programa resolve um problema - Construir uma teoria é análogo à modelagem - Orientar o desenvolvimento pelo modelo faz com que tenhamos soluções mais precisas - Programar não é produzir texto 

Obrigado! @talyssonoc | @codeminer42 

Referências - "Programming as Theory Building", Peter Naur - "Domain-Driven Design", Eric Evans - "The Mythical Man-Month, 20th Anniversary Edition", Fred Brooks - "Go read Peter Naur's "Programming as Theory Building" and then come back and tell me that LLMs can replace human programmers", Dave Gauer