Thoughts about layered architecture – Mapping efficiently with SQL by Tim Zöller @ Spring I/O 2022

Spring I/O 2022 - Barcelona, 26-27 May

In enterprise contexts, developers are often taught that we need to decouple our application layers and create reusable access methods for our data – but is that really true? Join me to find out how to write less code and create fast & easily maintainable software with Spring Data Projections.

Software that has multiple domains needs code which maps between them. The reasoning behind this is, that domains have to be decoupled from each other. This is especially important in layered architecture, a style that is widely used in todays’ software projects. Having layers in the application – usually a persistence layer, an application layer and a presentation layer – enforces separation of concerns and decouples the data models from each other. But: does it really?

In this session I will share some thoughts on the up- and downsides of layered architecture, boilerplate code, a common JPA antipattern, why “decoupled classes” do not mean “decoupled data” and how we could make our lives easier, if we let the database do what it does best: Transforming data.

[joerajeev]

TLDR;
In certian cases (e.g when there are many many joins) when there might be a performance overhead or you might end up loading much more data than you need to by doing traditional JPA (e.g eager loading would load half the db, and using lazy loading might cause 100s of queries and kill performance). You can use spring data projection to read straight to a pojo). Disadv: less maintainable as you specify native sql

[jootuubanen]

Excellent summary for senior developers, who like me have been working with financial enterprises for 20+ years. I just enjoyed this presentation, laughing aloud at times: so true
what he was talking about.

[pritamsamanta]

Really enjoyed this session. Will make sure to use Projection from now on.

[chauchau]

A very weird choice of topic for spring i/o

1) sounds like a talk for junior developer new to the industry

2) I am sure the speaker heard of DDD, right? (Don't mistake me thinking DDD is a sliver bullet for his unique use case)

3) just a warning to other viewer: injecting repository into controller is often suicidal in normal use case (whatever language, framework, programming paradigm you are using)

4) this is not about sliver bullet or not. This approach is simply only suitable for small number of unique use case like when it is ok to treat your rest service as a data layer.

My initial thought is this is only suitable for Subdomain without any business logic such as an api for querying pre-massaged data for external consumption

5) if the use case is simply returning JSON without any manipulation, some DBMS like oracle is able to return a JSON object directly

[JosifovGjorgi]

Most of these mistakes can be avoided with:
1. Use sql profiling tool when you are developing (most tools cost money and that is no, no from almost every developer, everyone want free lunch)
2. Don't use the weird abstraction of Spring Data (those interfaces), just use plain JPA with Criteria + sugar library for Criteria API (it's really verbose API). This is easier to debug and modify, because it's verbose.
3. Improve the debugging skills, because most developers have little, to no debugging skills.
4. Learn how to maintain code. It's easy to say, Spring Data interface are easy to write, but when you have to change the code 5-times in 6 months, it will be who wrote this garbage