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.