[TDC Floripa 2025] Modelagem de domínios como construção de teorias

Peter Naur, em seu artigo seminal "Programming as theory building", define que grande parte do desenvolvimento de programas está ligada à criação de teorias, sustentadas pelo conhecimento necessário para resolver o problema que o programa se propõe a solucionar. Esta palestra discute como esse conceito se aplica à modelagem de domínio e à compreensão do domínio, mostrando como ele pode ser definido em função da construção de teorias.

Transcript

1. Modelagem de domínios como construção de teorias
2. Talysson Oliveira Software architect & Chief Learning Officer na Codeminer42
3. codeminer42.com @codeminer42
4. Peter Naur, 1985 "Programming as Theory Building"
5. "[...] 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
6. O que é uma teoria?
7. “ 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
8. 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
9. Convergência de ideias
10. 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
11. 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
12. 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
13. 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
14. Código, especificações e documentação são transcendidos pelo conhecimento do time sobre o modelo em pelo menos 3 áreas
15. Quem tem a teoria pode explicar como a solução se relaciona com as questões do mundo que ela ajuda a resolver 1
16. 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
17. Quem tem a teoria pode explicar porque cada parte do programa é como é 2
18. 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
19. 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
20. 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
21. A vida e morte de um modelo
22. “ 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
23. 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
24. Programação não é sobre produzir texto
25. “ [...] É 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
26. 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
27. 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*
28. Não é a primeira vez que várias dessas ideias se repetem
29. "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"
30. 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
31. Obrigado! @talyssonoc | @codeminer42
32. 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