284 - Domain-Driven Design (DDD) com Programação Funcional?!?! 🤔🤔🤔 | theWiseDev Functional

[@bielr]

"Domain Modeling Made Functional" Scott Wlaschin, é um bom livro sobre o tema.

[@otaviolemos]

Sim, recomendei na descrição do vídeo junto com o From Objects to Functions. :)

[@jeffersonwilliammachado]

Sensacional mano! Obrigado por compartilhar. Tudo de bom.

[@otaviolemos]

Obrigado, Jefferson!

[@isaacdsc513]

Muito bacana, indico para ti dar uma olhada em Golang pois ele tem uma mistura e consegue aproveitar o lado bom do funcional e o lado "Orientação a objetos"

[@otaviolemos]

Massa, algum dia vou pegar pra ver… 😄

[@Anselmme]

Muito legal!

[@otaviolemos]

Valeu!

[@faadias]

Sensacional! Adoro seus vídeos, pois sempre trazem uma discussão bacana sobre DDD e diversos outros assuntos da área, mostrando que se trata de uma disciplina em constante evolução. Mesmo um conceito aparentemente "bem definido" na teoria acaba se transformando quando é aplicado na prtática. Aproveitando o comentário, um ponto que nunca fica claro para mim no DDD é a questão de onde tratar problemas de concorrência. Por exemplo, nessa abordagem funcional citada no artigo do Anthony Manning-Franklin, é feita uma verificação do saldo do usuário no "deriveUpgradeSubscriptionOutcome "; contudo, a efetivação no banco de dados não ocorre ao mesmo tempo, sendo executada mais para frente. Ou seja, poderia ocorrer de o usuário ter saldo no momento que o deriver foi chamado, mas entre a execução do deriver e a chamada para efetivar no banco de dados, o usuário poderia fazer alguma operação que gasta o saldo. Dessa forma, quando a camada imperativa for efetivar a transação, ela o fará em cima do resultado inicial do deriver, que era o de haver saldo positivo, criando uma inconsistência no banco de dados. Claro que estou falando de uma situação pouco provável, visto que tanto o deriver quanto a transação em si são chamados na mesma função "upgradeSubscription" e estão separados por poucas linhas de código, de modo que devem rodar com pouca diferença de tempo. Mas é uma situação que não pode ser descartada, pois poderia ser desencadeada por duplo clique no botão da interface, demora na execução do deriver por questões de performance etc. Daí eu fico: e agora, tem como resolver isso no código conforme descrito? Devo adicionar uma camada de complexidade ao código colocando as transções em "filas" por alguma key, de modo que elas obrigatoriamente sejam serializadas? Crio uma thread "verificadora" que busca por inconsistências, dando menos prioridade para o caso, visto que talvez não seja algo tão comum de acontecer?

[@otaviolemos]

Ótima pergunta, Felipe. No livro Architecture Patterns with Python ele lida com esse problema e usa agregados, o padrão unit of work, repositórios e lock otimista para resolver. O livro tem uma versão gratuita on-line. O capítulo no qual ele trata disso é esse aqui: www.cosmicpython.com/book/chapter_07_aggregate.html

[@faadias]

@@otaviolemos Legal! Valeu!

[@faadias]

​@@otaviolemos estou simplesmente devorando o livro. Que material fantástico! Uma leitura direta e bastante acessível, mesmo não conhecendo muito de python. Estou chegando agora ao capítulo de Unit of Work, mas já me deu uma base de conhecimento fantástica sobre arquitetura de software. Mais uma vez, muito obrigado por indicar o livro!

[@otaviolemos]

@@faadias esse livro é top demais mesmo!

[@dieg0dgm]

Muito bom, só da uma revisada no volume do audio que ta ficando muito baixo os ultimos vídeos