Anatomy of a Spring Boot App with Clean Architecture by Steve Pember @ Spring I/O 2023
ฝัง
- เผยแพร่เมื่อ 22 พ.ค. 2023
- Spring I/O 2023 - Barcelona, 18-19 May
Slides: www.slideshare.net/StevePembe...
GitHub repo: github.com/spember/spring-sho...
In my years of experience, Clean Architecture and its inspirations have been the easiest way to create readable, flexible codebases that can be worked on by large teams. This will be a good introductory talk with example code that attendees can reference at a later date.
We as an industry often talk quite a bit about the design of platform: the high-level architectures involving microservices, distributed systems, etc. But what about the internal architecture of a given application? How can one prevent their individual codebases from becoming the muddiest of mud balls?
Over the years we have found great success in keeping our codebases coherent and straightforward by following many of the principles of Clean Architecture - which itself can be considered an evolution of “Ports and Adapters”, and “Hexagonal Architecture”. Its main concept is that a given system must be imagined as Layers of ‘circles’ with a Dependency Rule which states that code dependencies many only point inwards; outer layers may call inner layers, but inner layers know nothing of the outer layers. These layers and their relationship rules give clear guidelines on where different code should live. This keeps your core business logic independent of and agnostic to the Details. Which database are we using to store “User” entity records? Which third-party service are we using for Authorization? While important, these Details are not the concern of your core business logic. They can be swapped in and out by implementing an interface; these concerns do not and can not pollute the rest of your core business logic. If followed correctly, the end result is a clearly structured, easily testable application, that is quick to react when external details need to change.
In this presentation we will present the general philosophy of Clean Architecture, Hexagonal Architecture, and Ports & Adapters: discussing why these approaches are useful and general guidelines for introducing them to your code. Chiefly, we will show how to implement these patterns within your Spring (Boot) Applications. Through a publicly available reference app, we will demonstrate what these concepts can look like within Spring and walkthrough a handful of scenarios: isolating core business logic, ease of testing, and adding a new feature or two. - วิทยาศาสตร์และเทคโนโลยี
SOLID presentation. I'll let myself out 😆
One of the best presentations from Spring I/O 2023!
Great job, old friend!
Thank you for the great talk.
mapping out DTOs are a nightmare, but a trade im willing to make 😎
I love the delivery for this talk. Thank you!!
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!
Great talk, Steve 🥳
Just loved it, It was Pro ❤
That's Cool 🔥
Awesome talk!
Go Steve Go!!
Nice talk!
Super..
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?
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
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.
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.
When are you going to drop the damn bottle? It completely distracted me from the presentation.