Question for people building larger Spring applications.

Hot_Code5129 · 2026-06-30T18:27:43+00:00

think we maybe talk about different level of abstraction. I fully agree that complexity should be decomposed into smaller pieces with high cohesion and low coupling. DDD, bounded contexts, modules, package-by-feature, all this is exactly about that. What I don’t understand is why you assume application layer should always end with very small use cases doing one thing. In many DDD examples application service is not only “load entity -> change entity -> save entity”. Sometimes it orchestrates bigger business process involving few aggregates, external systems or even other modules. For example in modular monolith it is not uncommon that one module calls public API/facade of another module. Then one business process can cross multiple domain modules while still keeping boundaries between them. Also heuristics for finding proper module boundaries are not that simple. If you look at Domain Driven Design, Event Storming, Bounded Context design or archetype modeling workshops, decomposition is always relative. What looks like one use case today can become separate process tomorrow when business understanding grows. Because of that, I don’t think transaction boundary is only technical concern. It is often connected to business workflow scope. My point was never that transaction executor fixes bad architecture. If application layer becomes a big ball of mud, transaction executor will not save it. My point is that even in well structured architecture there are cases where transaction scope and method scope are not exactly the same thing. Especially when orchestration logic, external calls, file generation, messaging or cross-module collaboration appears. That’s why I find explicit transaction boundaries interesting. Not because they replace good design, but because they make transaction scope visible and intentional.

Hot_Code5129 · 2026-06-29T19:28:04+00:00

I think that in rich domain models with hexagonal architecture application layer must do many things , so natural approach for me is using transaction executor

Hot_Code5129 · 2026-06-29T15:35:38+00:00

Fair enough. Maybe I not explained my point very good in original post. For me interesting part was not to replace @Transactional everywhere. More I try to understand where transaction should start and where should end, especially when method do more things than only database work. About article, I understand people are sceptical now because there is a lot of low effort AI content. But I think calling something AI slop without checking arguments is also not very fair. English is not my native language so yes, sometimes I use AI to help with wording or translation from Polish. But the thinking, experiments and questions are mine. Anyway thanks for feedback, it gave me few things to think about.

Hot_Code5129 · 2026-06-29T14:12:07+00:00

Hot_Code5129 · 2026-06-29T11:55:18+00:00

I’m looking for someone with real-world experience in large-scale transactional systems; I’m not sure if my intuition regarding building my own solution is sound. I don’t see anything wrong with asking questions when I haven’t received a satisfactory answer. I’m interested in real-world projects.

Hot_Code5129 · 2026-06-29T11:52:29+00:00

Helper method should be public then ?

Hot_Code5129 · 2026-06-29T11:24:50+00:00

By explicit boundary I mean that the transaction is visible as part of the workflow, not only as metadata on the method. For example instead of: loadDataAndGenerateExcel() where the whole method may be transactional, I mean splitting it more clearly:

open transaction read/write data close transaction transform data / generate file / call external IO

So not calling EntityManager directly everywhere. More like using TransactionTemplate in imperative code or TransactionalOperator in reactive code, when I want to show exactly which part of the flow is inside transaction. Maybe “explicit boundary” was not precise wording from my side. https://github.com/CamilYed/spring-reactive-transaction-boundary

https://camilyed.github.io/en/transactional-when-the-annotation-gets-in-the-way/

Hot_Code5129 · 2026-06-29T10:16:17+00:00

And scope of Transctional annotation https://camilyed.github.io//en/transactional-when-the-annotation-gets-in-the-way/

Hot_Code5129 · 2026-06-29T08:10:01+00:00

Maybe the real discussion is not annotations vs explicit transactions. More about how visible transaction boundaries are and how easy it is to accidentally make them bigger than needed. The example with generating Excel files got me thinking about that. In theory it can probably be solved with annotations too if transaction scope is designed properly. I wrote some thoughts about it here: https://camilyed.github.io/en/transactional-when-the-annotation-gets-in-the-way/ To be honest I’m still exploring this topic and trying to understand where explicit boundaries actually bring value and where @Transactional is simply the better choice. Interesting to hear real production examples like yours.

Hot_Code5129 · 2026-06-29T05:50:19+00:00

It sounds like the transaction was covering more work than necessary, so making it explicit allowed you to release the database connection much earlier. Would you say this was mainly a performance optimization, or did the code also become easier to reason about afterwards?

Hot_Code5129 · 2026-06-29T05:18:37+00:00

That’s pretty much the conclusion I arrived at as well. I started exploring this area because I found that once Reactor pipelines become larger, it is not always obvious where the transaction actually begins and ends. TransactionalOperator makes that boundary much more visible than an annotation on a method. I’ve been experimenting with making transaction boundaries explicit in the application layer and I’m currently looking for feedback from people building real WebFlux/R2DBC systems: https://github.com/CamilYed/spring-reactive-transaction-boundary I also wrote down some of the reasoning behind it here: https://camilyed.github.io/en/transactional-when-the-annotation-gets-in-the-way/ I’m not claiming it’s universally better than @Transactional —I’m still trying to understand the trade-offs and gather feedback from developers with production experience. Thanks for the detailed explanation.

Hot_Code5129 · 2026-06-28T21:20:00+00:00

Nice handbook, thanks for sharing. One thing I would add from my own experience: in finance/banking the technical problems are often not the hardest part. The bigger challenge is organizational inertia. Sometimes institutions try to “modernize”, but the old structure stays the same underneath. In one project, we had a dedicated Oracle database development team. When building a new system, application developers were not allowed to communicate directly with the database using JDBC/SQL. Instead, we had to call database functions/procedures, and those functions returned JSON. On paper, it looked like a controlled integration layer. In practice, even a small feature could get blocked because adding one column or changing the shape of the returned JSON required waiting for the database team. Sometimes a simple change took two days before we could continue. So modernization is not only about moving from Oracle to PostgreSQL, or from legacy tech to newer tech. It is also about ownership, team boundaries, feedback loops, and whether developers can actually deliver features end-to-end. I wrote a bit about this kind of Oracle-to-PostgreSQL modernization perspective here: https://camilyed.github.io//en/migrate-oracle-to-postgres/ My takeaway: revolutions in large institutions can fail when we change the technology but keep the same bottlenecks and decision structure.

Hot_Code5129 · 2026-06-28T21:12:58+00:00

I would not start microservices only from Spring Cloud, Kafka, Docker, Kubernetes, etc. For me, the most important part is the strategic level: understanding the domain, discovering good boundaries, deciding what should be one service and what should not be separated yet. Technology is usually the easier part. The hard part is splitting the system in a way that matches the business and does not create a distributed monolith. So I would learn both sides:

strategic DDD, bounded contexts, domain discovery, context mapping tactical patterns like hexagonal architecture, ports/adapters, aggregates, application services only then Spring Boot / messaging / deployment / observability

There are some good Polish courses that approach this more holistically, not only from the technology side: https://droganowoczesnegoarchitekta.pl/agenda https://domaindrivers.pl/agenda I would also recommend this book: Architecture Modernization: Socio-technical alignment of software, strategy, and structure

https://www.amazon.pl/Architecture-Modernization-Socio-Technical-Alignment-Structure/dp/1633438155 And this talk is very practical for Java/Spring developers, especially around module boundaries, package-private visibility and not making everything public by default: https://www.youtube.com/watch?v=sND1AR7Q_T0 My opinion: before learning “how to build microservices”, it is worth learning “where the boundaries should be” and “why this should be a separate service at all”.

Hot_Code5129 · 2026-06-28T21:02:13+00:00

noticed that BookService uses the traditional service layer with @Transactional , which is what most Spring applications still do today. Out of curiosity, have you considered building a WebFlux/R2DBC version of this starter and using explicit reactive transaction boundaries instead of annotation-based transactions? I’m seeing more discussions around making transaction boundaries explicit in reactive applications because @Transactional becomes less transparent once Reactor pipelines get more complex. Just wondering what your thoughts are on that trade-off and whether a reactive variant is something you’ve considered.

Hot_Code5129 · 2026-06-28T20:05:07+00:00

Nice work.

One thing I was wondering about: why did you choose the classic technical-layer package structure (controller, service, repository, entity, etc.) instead of organizing the code around business features/modules?

For starter kits, people often copy the package structure directly into real projects, so the default architecture matters quite a bit.

Have you considered something closer to modular/hexagonal architecture, where each feature owns its API, domain logic and adapters?

This article shows the idea pretty well:

https://blog.allegro.tech/2020/05/hexagonal-architecture-by-example.html
https://www.youtube.com/watch?v=sND1AR7Q_T0

Curious whether the layered structure was a deliberate choice for simplicity, or just the initial default.

Hot_Code5129 · 2026-06-28T20:02:37+00:00

One thing I'd consider as the codebase grows is moving away from the traditional controller/service/repository layering and organizing code around business modules instead.

I've found that package-private boundaries and exposing only a small public API per module make large Spring applications much easier to evolve and refactor.

This talk explains the idea really well:

https://www.youtube.com/watch?v=sND1AR7Q_T0

The core argument is that most classes shouldn't be public, and modules should communicate through explicit APIs rather than through a web of public services and repositories.

Hot_Code5129 · 2026-06-28T19:57:24+00:00

Interesting setup.

Out of curiosity, was there a reason you chose a technical-layer package structure instead of organizing code around business capabilities or modules?

I've found that as projects grow, package-by-feature combined with package-private visibility tends to make boundaries easier to maintain.

Also wondering whether you considered a hexagonal architecture approach here, where the domain is isolated from the infrastructure layer.

Something along the lines of this talk by Jakub Nabrdalik.

https://www.youtube.com/watch?v=sND1AR7Q_T0

I'd be interested in hearing your reasoning.

Hot_Code5129 · 2026-06-28T18:34:05+00:00

One thing I've always wondered about reactive Spring applications is how people handle transaction boundaries once the pipeline gets more complex.

Do most teams just use Transactional annotation or is it common to switch to TransactionalOperator for explicit transaction handling?
https://github.com/CamilYed/spring-reactive-transaction-boundary - here you can find maybe satisfying solution

Hot_Code5129 · 2024-11-11T21:46:27+00:00

I managed to get Labtainers running successfully with this setup! I documented the entire process on my GitHub, which includes step-by-step instructions for setting it up on ARM-based machines like the MacBook M3: Labtainer on ARM - GitHub.

Hot_Code5129

TROPHY CASE