> Inner layers are immune to changes in outer layers. Well and very concisely sums up the value and rationale of this. Thanks - I'm stealing that sentence
Great talk. I agree with almost everything he said, one thing I have found out in practice though is that the last bit is tough: Keeping JPA out of your core when your DB is going to be a relational one creates a lot of extra boilerplate and loads of extra conversions/copies of objects. This can get cumbersome (but the price you pay if you don't do it is the coupling he mentions).
The problem I have with a lot of architects is that you can NOT plan ahead. The blueprint is an excellent example, because it shows exactly what the architect conjured up, but when the builders put the first spade in the ground they find an old Roman settlement.
Good video! But I need some help ... What are the steps to create project with these modules? I created a Spring Boot project, but then ... I need to create an internal module with only Java kotlin? And another equals for store-details for example?
that's the joke he made at the end of the presentation. You will need some maoping code to convert a Domain entity back and forth to a JPA entity in a "detail" repository class
replace “Datasource” with XJpaRepository, kinda confusing with the names though, so i usually use “Datastore” or DAO as a substitute for core interface names
Your domain model object should not have *any* JPA annotations, that's the rule - so that you can reuse your domain objects into another application. But nothing prevents you from having another JPA-annotated model within the package of your database adapter. The adapter (the SPI interface really) takes and returns only Core Domain Model objects to preserve the core from knowing anything about the JPA-annotated model. The adapter then performs the conversion/mapping (using MapStruct) from the Core domain Model object to the private JPA-annotated models before performing the database operation, and performs a conversion/mapping from the JPA-annotated model to the Core Domain Model objects after the database operation. That's the way to go. Lots of mappers and lots of unit tests to test them all.
As a beginner in software architecture, I find the chart at 12:50 really confusing. What do the lines represent? it seems to me that some of them represent dependency, some inheritance, some data flow. For example, what does the arrow from OrderDetails to OrderController represent? What about the one from OrderController to OrderQuery? Or the one from Psql to PostgreOrderRepository?
They are UML class diagram notations. Order details is dependent on OrderController. Psql is partially dependent on PostgreOrderRepository. PostgreOrderRepository implements OrderRepository which is an interface
@@reallylordofnothing Thank you for the help, but I still don't get it. How can OrderDetails be dependent on OrderController? shouldn't it be the other way around? Same for Psql. And what do you mean with "partially dependent"?
Any idea how transactions can be handled within the core module which is framework agnostic? If core had Spring, we'll simply use @Transactional, but how to manage transactions without Spring or any framework?
While CoreServices are not allowed to use any infrastructure framework, ApplicationServices (or usecaseServices as they are called in the clean architecture) have a higher scope and are allowed to use _some_ infrastructure dependencies - usually transaction annotations and resiliance4j annotations are OK in application service (but not in core services). You must make sure you have no - or just the minimal amount of - business code inside those usecaseServices. They should only coordinate the calls to core services like an orchestrator or a mediator.
@@zartcolwing3218 Thank you for your response. But what if the scope of the transaction is solely based on the business logic and it must be within core?
@@nilangavirajith5318Application Layer in the entry point of your "core business". If you are using spring, you shd put @Transactional annotation on a method of a Application Service class which might invoke one or multiple "business logic" operations (including querying or writing). Take a look at Vaughn Vernon's Implementing Domain-driven Design book. I think most of your questions you will find an answer already there waiting for you to discover it
@@zartcolwing3218 I was almost sold on this approach, but now not only do I need DTOs I also need to proxy the service layer in core with a service layer in the application just so that I can use transactions. I can see where clean architecture is valuable in a huge monolithic application, but in modern "micro"/smaller services I think it is overkill.
One of the best presentations from Spring I/O 2023!
SOLID presentation. I'll let myself out 😆
> Inner layers are immune to changes in outer layers.
Well and very concisely sums up the value and rationale of this. Thanks - I'm stealing that sentence
Great talk. I agree with almost everything he said, one thing I have found out in practice though is that the last bit is tough: Keeping JPA out of your core when your DB is going to be a relational one creates a lot of extra boilerplate and loads of extra conversions/copies of objects. This can get cumbersome (but the price you pay if you don't do it is the coupling he mentions).
Thank you for the great talk.
Great job, old friend!
In the end it's all about your Postgres scaling/admin skills and ability to work overtime in the office)
Great talk! I learned a lot, thanks!
mapping out DTOs are a nightmare, but a trade im willing to make 😎
Awesome talk!
Just loved it, It was Pro ❤
The problem I have with a lot of architects is that you can NOT plan ahead. The blueprint is an excellent example, because it shows exactly what the architect conjured up, but when the builders put the first spade in the ground they find an old Roman settlement.
Great talk, Steve 🥳
Good video!
But I need some help ...
What are the steps to create project with these modules?
I created a Spring Boot project, but then ... I need to create an internal module with only Java kotlin? And another equals for store-details for example?
That's Cool 🔥
Nice talk!
How can i implement JPA into this architecture, where should i put JPA Entity ?
With your repository code. Your core/service isn't allowed to know about JPA so you'll have to convert at the repository side.
that's the joke he made at the end of the presentation. You will need some maoping code to convert a Domain entity back and forth to a JPA entity in a "detail" repository class
Go Steve Go!!
Would have been nice to see how u integrate with Spring Data repositories without the domain knowing about them.
replace “Datasource” with XJpaRepository, kinda confusing with the names though, so i usually use “Datastore” or DAO as a substitute for core interface names
Your domain model object should not have *any* JPA annotations, that's the rule - so that you can reuse your domain objects into another application. But nothing prevents you from having another JPA-annotated model within the package of your database adapter. The adapter (the SPI interface really) takes and returns only Core Domain Model objects to preserve the core from knowing anything about the JPA-annotated model. The adapter then performs the conversion/mapping (using MapStruct) from the Core domain Model object to the private JPA-annotated models before performing the database operation, and performs a conversion/mapping from the JPA-annotated model to the Core Domain Model objects after the database operation. That's the way to go. Lots of mappers and lots of unit tests to test them all.
As a beginner in software architecture, I find the chart at 12:50 really confusing. What do the lines represent? it seems to me that some of them represent dependency, some inheritance, some data flow.
For example, what does the arrow from OrderDetails to OrderController represent?
What about the one from OrderController to OrderQuery? Or the one from Psql to PostgreOrderRepository?
They are UML class diagram notations. Order details is dependent on OrderController. Psql is partially dependent on PostgreOrderRepository. PostgreOrderRepository implements OrderRepository which is an interface
@@reallylordofnothing Thank you for the help, but I still don't get it. How can OrderDetails be dependent on OrderController? shouldn't it be the other way around? Same for Psql. And what do you mean with "partially dependent"?
Any idea how transactions can be handled within the core module which is framework agnostic? If core had Spring, we'll simply use @Transactional, but how to manage transactions without Spring or any framework?
While CoreServices are not allowed to use any infrastructure framework, ApplicationServices (or usecaseServices as they are called in the clean architecture) have a higher scope and are allowed to use _some_ infrastructure dependencies - usually transaction annotations and resiliance4j annotations are OK in application service (but not in core services).
You must make sure you have no - or just the minimal amount of - business code inside those usecaseServices. They should only coordinate the calls to core services like an orchestrator or a mediator.
@@zartcolwing3218 Thank you for your response. But what if the scope of the transaction is solely based on the business logic and it must be within core?
@@nilangavirajith5318Application Layer in the entry point of your "core business". If you are using spring, you shd put @Transactional annotation on a method of a Application Service class which might invoke one or multiple "business logic" operations (including querying or writing).
Take a look at Vaughn Vernon's Implementing Domain-driven Design book. I think most of your questions you will find an answer already there waiting for you to discover it
@@zartcolwing3218 I was almost sold on this approach, but now not only do I need DTOs I also need to proxy the service layer in core with a service layer in the application just so that I can use transactions. I can see where clean architecture is valuable in a huge monolithic application, but in modern "micro"/smaller services I think it is overkill.
Super..
When are you going to drop the damn bottle? It completely distracted me from the presentation.
you have some serious OCD buddy ha