There is something codesmell I think. Domain layer should be written as pure as possible. Repository definition and entity definitions violate something here.Tests of the domain layer should also be written independently. But there is JPA dependency here.
so all the control/validation/restrictions/events will be in an Entity/POJO, services and business layers are empty :/ ... you manage the entire flow of a project by the actions performed against "the domain"
Jesus Christ, we have SQL, why are people so obsessed to complicate things so much. They literally created a thing that replicates SQL when we can just use SQL and map the result to a class
Obrigado pelo comentário! 😊 Eu discuti vários problemas e soluções na talk, e a maioria roda bem com a maioria dos bancos relacionais, mas podem sim haver nuances. De qual abordagem vc fala exatamente?
bom dia Rafael eu tentei usando Oracle 12c subindo 2 instâncias no ecs mas ao executar um job que busca do banco e publica em um tópico as instâncias trazem registros repetidos! Parabéns pela live de ontem no deveficiente! Agora tb serei seu aluno lá
@@fonfux0123 valeu! então, Oracle suporta bem o que discuti na talk. Como está o SELECT executado pela aplicação? Ele está sendo gerado FOR UPDATE ou FOR UPDATE SKIP LOCKED?
@@RafaelPonte com for update skip locked! acho que tem algo a ver com os cursores do oracle como funcionam! posso estar enganado! ou entao o fato de eu estar delimitando a qtd de registros da consulta e ele so da o lock depois de obter o resulta pra cada uma das linhas
@@fonfux0123 Entendi. Isso é verdade. No caso do SKIP LOCKED, o Oracle somente faz o locking durante o fetching do registro, e não durante a seleção (filtering) do mesmo. Mas isso normalmente acontece quando você está manipulando explicitamente cursores via PL/SQL ou alguma API de persistência. Aqui nessa outra talk sobre SKIP LOCKED focada em Oracle, eu comento essa "limitação": ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-8DVFc7gXfIQ.html Espero que ajude!
Hmm I did not get this topic. JPA is ORM, Object-Relational Mapping . Some implements JPA because we want to look all tiers including DB/table part as object view. I feel he is trying to do JDBC as ORM. I would consider DAO pattern to solve it. Nothing right or wrong, it likes EJB, CMP vs BMP.
If one uses jpa entity classes that need mapping to domain objects there will be quite so code gymnastics to lazy load collections because mapping them will always result in an eager fetch
Thank you for the insightful talk! I appreciate the points made, but I respectfully disagree with Oliver’s statement around minute 17 regarding the necessity of using jMolecules to define aggregate roots. In my experience with Spring Data JPA and Domain-Driven Design (DDD), we can effectively define aggregate roots by leveraging the `AbstractAggregateRoot` class provided by Spring Data, without needing to rely on jMolecules. This approach works well for managing domain events and maintaining the boundaries of the aggregate in a clean, straightforward manner.
Interesting but Domain driven design I still don't get the benefits on micro services at least. A lot of classes and complexity. Yes small classes are simpler to maintain. Anyway I will continue the journey with the videos you mentioned.
I would say this talk is great for beginners. He explains the subject very well but you'd already know most of the stuff he talks about if you've written tests.
I tried learning spring Security via doc and it was terrible hahaha 🤣 I got a tutorial on the internet from amigoscode and now I advocate forthe usage of spring security
I really enjoyed the Video but did anyone tested it? Note I like the concepts provided and agree in most of them but checking DomainEventListener located under application or Catalog module fails modulith verification with the LoanCreated and Closed events from Lending module: - Module 'catalog' depends on non-exposed type library.lending.domain.LoanCreated within module 'lending'! LoanCreated declares parameter LoanCreated.handle(LoanCreated) in (DomainEventListener.java:0)
As a side note, the original example program has one further problem which wasn't discussed - if the job runs every 60 seconds, what happens if it takes more than 60 seconds to complete, giving you unintended parallel processing? I've been bitten by that one a few times...
Thanks for the comment! 😊 In the context of the talk, this is not an issue. I mean, Spring will not allow running multiple jobs for the same task, even if it takes longer than 60 sec. But if the method is annotated with @Async then we can not say the same 😬
@@RafaelPonte Fair enough... you're right that a good scheduler will avoid the problem (for sync operations, at least). My negative experiences have typically been with more naive scheduling tools...
Great video! Under the heading of "more functional" I do wish Urs had mentioned the fact that many more things are expressions in Kotlin than in Java. For example, try, if, and when among others all return a value. This eliminates the all-too-common and error prone pattern of creating a local variable initialized to null upstream of a block, and then assigning to it inside a conditionally-executed block. Instead, the if/else or try/catch itself returns a value. This contributes to concision, safety, and readability.
This is truly and event sourcing revolution. The condictional append is better than just enabling multi stream transactions at the persistence layer. Thanks Sara Pellegrini and Milan Savic
Thanks for the comment. Yeah, you're right. The number of rows is unimportant in understanding how the SQL feature works. The idea was to be didactic and straightforward.
I found the idea of coding the implementation as userstories / usecases extremely insightfull, seeems to work really well with ddd. Goes hand in hand with good architecture documentation and requirements engineering and is pretty good from a perspective as "code as documentation". Never thought of this. Its roughly at timecode 34:30
Good Job 👏🏽 helping and empowering Spring Developers. Just to point out to think our decisions. 24:12 Domain coupled to infrastructure. - You can not port this domain to other framework. Trade off or Smell ? You could dispatch a domain exception. `InvalidBookIdException` and get rid of the framework dependency.