Anatomy of a Spring Boot App with Clean Architecture by Steve Pember @ Spring I/O 2023

Spring I/O 2023 - Barcelona, 18-19 May

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.

[nviorres]

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).

[fipabrate]

SOLID presentation. I'll let myself out 😆

[costel]

One of the best presentations from Spring I/O 2023!

[muthmi]

I love the delivery for this talk. Thank you!!

[lmb_codes]

mapping out DTOs are a nightmare, but a trade im willing to make 😎

[BorisTreukhov]

In the end it's all about your Postgres scaling/admin skills and ability to work overtime in the office)

[nicolasdemaio]

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?

[avwie]

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.

[nilangavirajith]

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?

[NguyenHung-wryz]

How can i implement JPA into this architecture, where should i put JPA Entity ?

[lowabstractionlevel]

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?

[TristanOnGoogle]

Would have been nice to see how u integrate with Spring Data repositories without the domain knowing about them.

[zartcolwing]

When are you going to drop the damn bottle? It completely distracted me from the presentation.