Forem: Dominik Paszek

Aggregate Root in Spring Boot — Sealed Classes, Lifecycle Guards, and Why @Entity Doesn't Go on Your Domain Object

Dominik Paszek — Tue, 31 Mar 2026 19:00:00 +0000

Aggregate Root in Spring Boot — Sealed Classes, Lifecycle Guards, and Why @entity Doesn't Go on Your Domain Object

Episode 3 of the DDD series — watch on YouTube | source code on GitLab

Last episode we replaced primitives with Value Objects. PackageSize, PackageWeight, LockerAddress — all self-validating, immutable, typed.

But we left something open. The status field on Parcel was still mutable with no guards. Anyone could do this:

parcel.setStatus(ParcelStatus.COLLECTED);
parcel.setStatus(ParcelStatus.CREATED);  // backwards?
parcel.setStatus(ParcelStatus.CANCELLED); // after collection?

The compiler was fine with all of it. That's what Aggregate Root fixes.

What Is an Aggregate Root?

An Aggregate Root is the only object in a cluster that outside code is allowed to call directly.

Parcel owns PackageSize, PackageWeight, TrackingNumber, ParcelStatus. They have to be consistent with each other — a COLLECTED parcel can't go back to CREATED. The AR is what enforces that.

Three rules:

External code talks to the root only. Nobody reaches past Parcel to modify PackageSize directly.
Business rules live in the root. Not in a service that might forget to call a validator. In the object itself.
One aggregate, one transaction. You save the whole Parcel or nothing.

BaseAggregateRoot

Before building Parcel, we set up a base class in common/:

public abstract class BaseAggregateRoot<ID extends Serializable> {

    private final List<Object> domainEvents = new ArrayList<>();

    protected void registerEvent(Object event) {
        domainEvents.add(Objects.requireNonNull(event));
    }

    @DomainEvents
    protected Collection<Object> domainEvents() {
        return Collections.unmodifiableList(domainEvents);
    }

    @AfterDomainEventPublication
    protected void clearDomainEvents() {
        domainEvents.clear();
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof BaseAggregateRoot<?> other)) return false;
        return getId() != null && getId().equals(other.getId());
    }

    @Override
    public int hashCode() { return getClass().hashCode(); }

    public abstract ID getId();
}

equals and hashCode are identity-based — two Parcel objects with the same ParcelId are equal regardless of field values. That's the difference between an AR and a Value Object.

@DomainEvents and registerEvent() are there for episode 6 when we cover domain events. For now the infrastructure is in place, the calls aren't wired yet.

Parcel as an Aggregate Root

public final class Parcel extends BaseAggregateRoot<ParcelId> {

    private final ParcelId parcelId;
    private final TrackingNumber trackingNumber;
    private final PackageWeight packageWeight;
    private final PackageSize packageSize;
    private ParcelStatus status;
    private final LocalDateTime createdAt;

    @Override
    public ParcelId getId() { return parcelId; }

    public static Parcel register(ParcelId parcelId,
            PackageWeight weight, PackageSize size) {
        return new Parcel(parcelId, weight, size,
            ParcelStatus.CREATED, LocalDateTime.now());
        // domain event: episode 6
    }

    public static Parcel restore(ParcelId parcelId, PackageWeight weight,
            PackageSize size, ParcelStatus status, LocalDateTime createdAt) {
        return new Parcel(parcelId, weight, size, status, createdAt);
    }
}

status is the only non-final field. Everything else is set once at creation.

Two factory methods with different purposes:

register() is the business operation — creates a new parcel, will publish a domain event in ep6
restore() is the persistence operation — reconstructs existing state from the database, no events, no guards

Without restore() you either bypass invariant checks (dangerous) or re-validate already-persisted state (wasteful and fragile). Naming them differently makes the intent explicit.

Lifecycle Guards

Every transition method has a guard at the top:

public void pickUpFromSender() {
    if (this.status != ParcelStatus.CREATED) {
        throw new IllegalStateException(
            "Parcel must be CREATED to be picked up. Got: " + this.status
        );
    }
    this.status = ParcelStatus.PICKED_UP_FROM_SENDER;
    // domain event: episode 6
}

public void storeInLocker(LockerSlotId slotId) {
    if (this.status != ParcelStatus.IN_TRANSIT_TO_LOCKER) {
        throw new IllegalStateException(
            "Parcel must be IN_TRANSIT_TO_LOCKER. Got: " + this.status
        );
    }
    this.status = ParcelStatus.STORED_IN_LOCKER;
    // domain event: episode 6
}

public void collect() {
    if (this.status != ParcelStatus.STORED_IN_LOCKER) {
        throw new IllegalStateException(
            "Parcel must be STORED_IN_LOCKER. Got: " + this.status
        );
    }
    this.status = ParcelStatus.COLLECTED;
}

public void cancel() {
    if (this.status == ParcelStatus.COLLECTED) {
        throw new IllegalStateException(
            "Cannot cancel a collected parcel"
        );
    }
    this.status = ParcelStatus.CANCELLED;
}

The full ParcelStatus lifecycle:

CREATED
  → PICKED_UP_FROM_SENDER
    → IN_TRANSIT_TO_WAREHOUSE
      → IN_WAREHOUSE
        → IN_TRANSIT_TO_LOCKER
          → STORED_IN_LOCKER
            → COLLECTED (terminal)
  → CANCELLED (terminal, from most states)

Every arrow is a method with a guard. COLLECTED and CANCELLED have no outgoing transitions.

Order — Sealed Class, Two ARs

One parcel always creates two orders — a SenderOrder and a ReceiverOrder. Same ParcelId, different actors, different lifecycles. We express that with a sealed class:

public abstract sealed class Order extends BaseAggregateRoot<OrderId>
        permits SenderOrder, ReceiverOrder {

    protected final OrderId orderId;
    protected final ParcelId parcelId;
    protected final PartyId senderId;
    protected final PartyId receiverId;
    protected final DeliveryOption deliveryOption;
    protected OrderStatus status;
}

sealed means the compiler knows every possible subtype. A switch on Order won't compile unless you handle both SenderOrder and ReceiverOrder. Add a third subclass and every existing switch breaks until you update it.

ReceiverOrder has an assign() method that stores the locker ID and pickup code when a slot is ready:

public void assign(LockerId lockerId, String pickupCode) {
    if (this.status != OrderStatus.NOT_ASSIGNED
            && this.status != OrderStatus.REGISTERED) {
        throw new IllegalStateException(
            "Cannot assign ReceiverOrder in status: " + status
        );
    }
    this.lockerId = lockerId;
    this.pickupCode = pickupCode;
    this.status = OrderStatus.ASSIGNED;
    // domain event: ReceiverOrderAssigned — episode 6
    // handler in party/ sends SMS with locker address + pickup code
}

In episode 6 we add ReceiverOrderAssigned here. A handler in the party module picks it up and sends the notification. ReceiverOrder doesn't know any of that — it just records the state change.

Why @entity Doesn't Go on Parcel

JPA needs a no-arg constructor. JPA accesses fields through reflection. If @Entity goes on Parcel, JPA starts managing the aggregate's lifecycle — it gets to decide when things load and when they flush. The AR loses control.

Two separate classes:

// domain — no JPA
public final class Parcel extends BaseAggregateRoot<ParcelId> { ... }

// adapter/out/persistence — JPA only
@Entity
@Table(name = "parcels")
public class ParcelJpaEntity { ... }

The adapter converts between them. toDomain() calls Parcel.restore(). from(parcel) builds the entity from the domain object. Neither class leaks into the other's layer.

What Is NOT an Aggregate Root

LockerSlot — no meaning without Locker. Package-private constructor so only Locker can create slots. The locker enforces one parcel per slot in assignParcel(). One aggregate, one transaction, slots included.

Customer.orders — we removed List<OrderId> from Customer this week. Every new order would have had to modify Customer — two aggregates in one transaction, a list that grows without a business rule attached to it. That's a query, not domain state. orderRepository.findByReceiverId(partyId) does the job without touching any aggregate.

Quick gut-check: does it have invariants to protect across its own fields? Probably AR. Is it coordinating other objects or just holding data? Probably not.

Next Episode

Repository pattern. ParcelRepository as a port in application/port/out/. ParcelPersistenceAdapter implementing it. Manual wiring through @Configuration — no @Autowired, no @Component on use cases.

Source code: gitlab.com/PaszekDevv/locker — branch part2-aggregate-root

Branch off it, try something differently, open a merge request — I read them.

Primitive Obsession in Spring Boot DDD — before and after replacing UUID/Integer/String with Value Objects (code + video)

Dominik Paszek — Thu, 26 Mar 2026 18:42:21 +0000

Your Compiler Could Have Caught This Bug. It Didn't.

This post accompanies episode 2 of my DDD series — building a real parcel locker system in Spring Boot from scratch. Source code on GitLab.

We had a method like this in our codebase:

public Parcel assignParcelDimensions(
        Integer weightKg,
        Integer heightCm,
        Integer widthCm,
        Integer depthCm) {
    this.weightKg = weightKg;
    this.heightCm = heightCm;
    this.widthCm = widthCm;
    this.depthCm = depthCm;
    return this;
}

Four Integer parameters in a row. Swap two — it compiles. Passes review. Ships. And somewhere in production, a package ends up in the wrong locker because weight and width got mixed up.

The compiler had all the information it needed to stop this. We just didn't give it the right types.

The Problem: Primitive Obsession

Here's the full Parcel domain class before we touched it:

public final class Parcel {
    private final UUID parcelId;      // any UUID fits — even a lockerId
    private Integer weightKg;         // mutable, non-final
    private Integer heightCm;
    private Integer widthCm;
    private Integer depthCm;
    private String lockerSlotId;
    private String deliveryAddress;   // identical type to lockerSlotId
    private final LocalDateTime createdAt;
}

And Locker:

public final class Locker {
    private final String lockerId;
    private final String postalCode;  // three naked strings
    private final String city;        // with no connection between them
    private final String street;      // and no format validation
}

This has a name: Primitive Obsession. Using raw built-in types where domain concepts need their own type with their own rules.

The problems in Parcel alone:

UUID parcelId — any UUID works here, including a lockerId passed by mistake
Integer weightKg is non-final — weight can change after registration, which should never happen
Four integers in assignParcelDimensions with no type safety between them
String deliveryAddress and String lockerSlotId are identical types with completely different semantics

What Is a Value Object?

A Value Object represents a domain concept through its value, not its identity. Three properties, all required:

1. Immutable. Once created, it cannot change. No setters. Java records enforce this — every component is final.

2. Value equality. Two Value Objects with the same content are equal, regardless of reference. Records give you equals() and hashCode() automatically.

3. Self-validating. A Value Object cannot exist in an invalid state. Validation happens in the compact constructor. If you hold one, it is valid — no exceptions, no "did someone validate this first?"

That third property is the one that changes how you write code. You stop writing defensive checks everywhere and start designing types that can't hold bad data.

Step 1: Unit — The Smallest Value Object

Before tackling dimensions, we need a Unit. Right now the unit information lives only in field names — weightKg, heightCm. The type itself tells you nothing.

public record Unit(String symbol, String name) {
    public Unit {
        if (symbol == null || symbol.isBlank())
            throw new IllegalArgumentException(
                "Unit symbol cannot be null or blank"
            );
        if (name == null || name.isBlank())
            throw new IllegalArgumentException(
                "Unit name cannot be null or blank"
            );
    }

    public static final Unit KILOGRAM   = new Unit("kg", "kilogram");
    public static final Unit CENTIMETER = new Unit("cm", "centimeter");
    public static final Unit GRAM       = new Unit("g",  "gram");
}

Common units are static constants — immutable singletons, safe to share freely.

Note: A subtle bug worth flagging — if you write if (symbol != null && !symbol.isBlank()) throw ... you're throwing when the value is valid. The correct guard is == null || isBlank(). Easy to miss, breaks everything.

Step 2: PackageSize — Replacing Three Integers

Should width, height, and depth be three separate Value Objects or one? In our domain, dimensions always travel together — they describe one concept. One Value Object:

public record PackageSize(int width, int height, int depth, Unit unit) {

    public PackageSize {
        if (width <= 0 || height <= 0 || depth <= 0)
            throw new IllegalArgumentException(
                "All dimensions must be positive. Got: "
                + width + "x" + height + "x" + depth
            );
        if (unit == null)
            throw new IllegalArgumentException("Unit is required");
        if (unit.equals(Unit.CENTIMETER)
                && (width > 120 || height > 120 || depth > 180))
            throw new IllegalArgumentException(
                "Exceeds maximum dimensions (120x120x180 cm)"
            );
    }

    public LockerSlotSize requiredSlotSize() {
        if (width <= 40 && height <= 40 && depth <= 60)   return LockerSlotSize.SMALL;
        if (width <= 60 && height <= 60 && depth <= 100)  return LockerSlotSize.MEDIUM;
        if (width <= 100 && height <= 100 && depth <= 150) return LockerSlotSize.LARGE;
        // Reachable: 110x50x50 passes the constructor (110 <= 120)
        // but doesn't fit any slot (110 > 100 for LARGE)
        throw new IllegalStateException(
            "Parcel doesn't fit any locker slot: "
            + width + "x" + height + "x" + depth
        );
    }
}

Why is the max 120 and not 100? Our largest locker slot is 100×100×150. But a slightly oversized parcel should still be registerable — it just can't be assigned to a slot. These are two different business rules. The constructor enforces the absolute limit. Assignment logic enforces the locker limit. Conflating them would mean you can't even create an object for an oversized parcel.

The assignParcelDimensions method now becomes:

// Before — four integers, any order
public Parcel assignParcelDimensions(Integer weightKg,
        Integer heightCm, Integer widthCm, Integer depthCm)

// After — one type, no positions to swap
public Parcel assignDimensions(PackageSize size)

Step 3: PackageWeight — Immutability With Operations

public record PackageWeight(int value, Unit unit) {

    public PackageWeight {
        if (value <= 0)
            throw new IllegalArgumentException("Weight must be positive");
        if (unit == null)
            throw new IllegalArgumentException("Unit is required");
        if (unit.equals(Unit.KILOGRAM) && value > 30)
            throw new IllegalArgumentException(
                "Max 30kg for locker delivery, got: " + value
            );
    }

    public PackageWeight add(PackageWeight other) {
        if (!this.unit.equals(other.unit))
            throw new IllegalArgumentException(
                "Cannot add weights with different units"
            );
        return new PackageWeight(this.value + other.value, this.unit);
    }

    public boolean requiresSignature() {
        return unit.equals(Unit.KILOGRAM) && value > 10;
    }
}

add() returns a new PackageWeight. The original is unchanged. Operations on Value Objects produce new values — they never mutate state. This also means PackageWeight is safe to share, safe to use as a map key, safe to cache.

The field in Parcel goes from private Integer weightKg (non-final, mutable) to private final PackageWeight weight. Weight cannot change after registration.

Step 4: LockerAddress — Grouping Related Strings

Three naked strings in Locker become one:

public record LockerAddress(String street, String city, String postalCode) {

    public LockerAddress {
        if (street == null || street.isBlank())
            throw new IllegalArgumentException("Street is required");
        if (city == null || city.isBlank())
            throw new IllegalArgumentException("City is required");
        if (postalCode == null || !postalCode.matches("\\d{2}-\\d{3}"))
            throw new IllegalArgumentException(
                "Invalid postal code. Expected XX-XXX, got: " + postalCode
            );
    }
}

Locker goes from three separate fields to:

private final LockerAddress address;

The postal code format is now a type-level guarantee. You can't create a LockerAddress with a malformed postal code. There's no moment to forget the validation — it runs at construction or not at all.

How to Persist Value Objects

Three approaches, all legitimate:

@Embeddable — put the JPA annotation directly on the Value Object. JPA stores its fields inline in the parent table. This is what Vaughn Vernon uses in his IDDD reference code. One annotation imports jakarta.persistence, which is a light coupling you may or may not care about.

AttributeConverter — best for single-value objects like ParcelId. Zero annotations on the domain class, truly final fields, clean separation.

@Converter(autoApply = true)
public class ParcelIdConverter
        implements AttributeConverter<ParcelId, String> {

    @Override
    public String convertToDatabaseColumn(ParcelId id) {
        return id != null ? id.value().toString() : null;
    }

    @Override
    public ParcelId convertToEntityAttribute(String value) {
        return value != null
            ? new ParcelId(UUID.fromString(value))
            : null;
    }
}

Separate JPA entity + mapper — full isolation. Domain has zero persistence knowledge. Most code, most control. The right call if you're planning to support multiple storage backends.

For this project: AttributeConverter for identifiers, @Embeddable for multi-field objects like PackageSize and LockerAddress.

Where They Live

parcels/
  domain/model/
    Parcel.java           ← Aggregate Root
    Unit.java             ← Value Object
    PackageSize.java      ← Value Object
    PackageWeight.java    ← Value Object
    ParcelId.java         ← Value Object
  adapter/out/persistence/
    ParcelJpaEntity.java  ← @Entity lives here, not in domain/

lockers/
  domain/model/
    Locker.java           ← Aggregate Root
    LockerAddress.java    ← Value Object
    LockerId.java         ← Value Object

domain/model/ is the innermost layer. Zero framework annotations — unless you choose @Embeddable, which is your decision, not a rule.

The Point

If you hold a Value Object, it is valid. You don't need to check. You can't forget to check. The type guarantees it.

assignParcelDimensions(Integer, Integer, Integer, Integer) is gone. You cannot swap weight and width anymore — they're different types and the compiler knows it.

Next episode: Aggregate Root. We take these Value Objects and enforce the real business rules on Parcel and Locker — the domain classes, not the JPA entities. What can change after a parcel is registered? What cannot? That's where the Aggregate Root lives.

Source code: gitlab.com/PaszekDevv/locker — branch part1-valueobjects

Branch off, try your own approach, open a discussion. That's the point.

Hexagonal Architecture in Spring Boot — Win a Free Book

Dominik Paszek — Thu, 19 Mar 2026 17:28:55 +0000

We're Running a Contest — Refactor to Hexagonal Architecture and Win a Book

I just published a full tutorial on Hexagonal Architecture in Spring Boot, and we're running a contest alongside it.

The prize is "Get Your Hands Dirty on Clean Architecture" by Tom Hombergs as an ebook — the book that popularized this exact pattern in the Java world.

What the video covers

In Episode 1 of my Spring Boot series I showed a basic api/domain/infrastructure structure. This episode takes it further — proper Ports & Adapters, an explicit application layer, and the thing that makes it all worth it: business logic tests that run in 50 milliseconds instead of 45 seconds.

The key insight the video builds toward: Spring's dependency injection is already the hexagonal mechanism. When your controller injects RegisterUser and Spring provides RegisterUserService — that IS ports and adapters. You just need to be intentional about which interfaces go where.

→ [Watch the full episode here: youtube link]

The contest

Fork the repo, refactor the user and order packages to Hexagonal Architecture, open a Merge Request, and drop the link in the YouTube comments.

Three things that make a valid submission: ports use business names (loadUser not findById), the domain package has zero Spring annotations, and at least one test runs without @SpringBootTest.

One random winner from all valid submissions gets the ebook.

Deadline: [02.04.2026]
Repo: GitLab link

Part of an ongoing Spring Boot + DDD series. Next up: Value Objects.

Spring Boot @Transactional: 5 Bugs That Are Probably in Your Production Code

Dominik Paszek — Tue, 17 Mar 2026 21:00:00 +0000

Spring Boot @Transactional: 5 Bugs That Are Probably in Your Production Code

You deploy a new feature. Tests pass. Code review done. Production looks normal.

A week later someone calls. Money is missing. The transfer left one account and never arrived at the other. No error in the logs. No exception. The transaction just... didn't work.

These aren't exotic edge cases. They're the five most common @Transactional bugs, and they all share one property: they fail silently. No warning, no stack trace, just wrong data in your database.

Why these bugs are hard to find: the proxy model

Before the bugs, you need one piece of context.

@Transactional doesn't work on your object. It works on a proxy that wraps it. When Spring creates a @Transactional bean, it builds a CGLIB subclass that intercepts incoming method calls and wraps them in transaction management. Calls that go through the proxy get a transaction. Calls that bypass the proxy don't.

Every bug below is a different way of bypassing the proxy.

Bug #1 — Self-invocation

The most Googled Spring problem. People spend five hours on this because there's zero runtime feedback.

// ❌ BUG
@Service
public class OrderService {

    public void placeOrder(Order order) {
        validateOrder(order);
        saveOrder(order);  // this.saveOrder() — bypasses the proxy
    }

    @Transactional
    public void saveOrder(Order order) {
        orderRepository.save(order);
        notificationRepository.save(new Notification(order));
        // RuntimeException here → NO rollback
        // the first save is already committed
    }
}

placeOrder calls saveOrder via this. The proxy never intercepts it. The @Transactional annotation is decorative.

Two fixes. The architecturally clean one is to extract saveOrder into a separate bean:

// ✅ FIX 1 — separate bean
@Service
public class OrderPersistenceService {
    @Transactional
    public void saveOrder(Order order) {
        orderRepository.save(order);
        notificationRepository.save(new Notification(order));
    }
}

The faster workaround when a refactor isn't realistic:

// ✅ FIX 2 — self-injection
@Service
public class OrderService {
    private final OrderService self;

    public OrderService(@Lazy OrderService self, ...) { this.self = self; }

    public void placeOrder(Order order) {
        self.saveOrder(order); // via proxy ✓
    }
}

IntelliJ flags self-invocation with a yellow underline through SpringTransactionalMethodCallsInspection. If you've disabled it, turn it back on.

Bug #2 — Checked exceptions commit

Spring rolls back on RuntimeException and Error. On a checked exception, it commits. Always.

This is intentional — inherited from EJB, where checked exceptions meant "expected business event, continue." The logic falls apart when you're throwing IOException halfway through a money transfer.

// ❌ BUG — money debited, never credited
@Transactional
public void transferMoney(Long fromId, Long toId, BigDecimal amount)
        throws IOException {

    Account from = accountRepository.findById(fromId).orElseThrow();
    from.debit(amount);
    accountRepository.save(from);  // persisted

    callComplianceApi(from);       // throws IOException → COMMIT
}

// ✅ FIX
@Transactional(rollbackFor = Exception.class)
public void transferMoney(...) throws IOException { ... }

If you're on Spring Boot 3.2+, there's a global option that changes the default for your entire application:

@EnableTransactionManagement(rollbackOn = RollbackOn.ALL_EXCEPTIONS)

One config change, eliminates this class of bug everywhere.

There's a related trap worth naming: swallowing exceptions inside @Transactional. If you catch and log without rethrowing, the transaction manager never sees the exception and commits. No indication anything went wrong.

Bug #3 — Private and final methods

CGLIB creates a proxy by subclassing your bean. Private and final methods can't be overridden — that's a Java rule, not a Spring one. The annotation is silently ignored.

// ❌ BUG
@Service
public class PaymentService {

    @Transactional  // does nothing
    private void persistPayment(Payment p) {
        paymentRepository.save(p);
        throw new RuntimeException("fail");
        // NO rollback — no transaction was ever started
    }
}

Fix: make it public. Spring 6.0 fixed this for protected and package-private methods. private and final will never work.

Bug #4 — REQUIRES_NEW deadlock

This one works perfectly in development and kills production under load, with no exception pointing to the cause.

REQUIRES_NEW doesn't create a nested transaction — it suspends the current database connection and opens a new, independent one from the pool. HikariCP defaults to 10 connections.

Under load, 10 concurrent requests each grab a connection for their outer transaction — pool is full. Each then calls auditService which needs a second connection for REQUIRES_NEW. No connections left. Every thread waits forever. No exception. Application freezes.

// ❌ BUG
@Transactional  // holds conn #1
public void createOrder(Order order) {
    orderRepository.save(order);
    auditService.logAudit("Order: " + order.getId());
    // needs conn #2 → pool exhausted → DEADLOCK
}

@Transactional(propagation = Propagation.REQUIRES_NEW)
public void logAudit(String message) {
    auditRepository.save(new AuditLog(message));
}

Audit doesn't need to be inside the main transaction — it just needs to run after the order commits.

// ✅ FIX
@Transactional
public void createOrder(Order order) {
    orderRepository.save(order);
    eventPublisher.publishEvent(new OrderCreatedEvent(order.getId()));
}

@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
@Transactional(propagation = Propagation.REQUIRES_NEW)
// safe — outer TX is already gone, no connection held
public void handle(OrderCreatedEvent event) {
    auditRepository.save(new AuditLog("Order: " + event.getOrderId()));
}

REQUIRES_NEW is only safe when the outer transaction no longer exists — exactly what AFTER_COMMIT guarantees.

Bug #5 — readOnly=true silently drops writes

readOnly = true is a hint, not a constraint. Hibernate responds by disabling dirty checking and entity snapshots — a real performance improvement for reads, up to 50% in some cases. But it also means modified entities are never flushed. No exception, no warning.

// ❌ BUG
@Service
@Transactional(readOnly = true)
public class ProductService {

    public void updatePrice(Long id, BigDecimal price) {
        Product p = productRepository.findById(id).orElseThrow();
        p.setPrice(price);
        // Hibernate does NOT flush — change is silently lost
    }
}

The fix: annotate the class with readOnly = true as the default, then override each write method with plain @Transactional:

// ✅ FIX
@Service
@Transactional(readOnly = true)
public class ProductService {

    @Transactional  // overrides to readOnly = false
    public void updatePrice(Long id, BigDecimal price) {
        Product p = productRepository.findById(id).orElseThrow();
        p.setPrice(price); // dirty checking active, flushed at commit ✓
    }
}

Note: MySQL enforces readOnly at the DB level and will throw an error on writes. PostgreSQL doesn't enforce it — writes may silently succeed. Don't rely on the database to catch this.

The pattern behind all five

Every bug above is a version of the same thing: something bypasses the proxy. Self-invocation goes through this. Private methods can't be intercepted. REQUIRES_NEW opens a connection outside the current transaction context. If @Transactional isn't working, the first question is always: are you bypassing the proxy?

Cheat sheet

Bug	Symptom	Fix
Self-invocation	Annotation present, no transaction	Separate bean or `@Lazy` self-injection
Checked exceptions	Rollback expected, commit happens	`rollbackFor = Exception.class` or `RollbackOn.ALL_EXCEPTIONS`
Private/final methods	Annotation silently ignored, zero feedback	Make it `public`
REQUIRES_NEW deadlock	App freezes under load, no exception	`@TransactionalEventListener(AFTER_COMMIT)`
readOnly trap	Entity changes silently lost	`@Transactional` override on write methods

Video walkthrough with live demos: [https://youtu.be/XOR-mmipVlU]

Source code: [https://gitlab.com/PaszekDevv/transactional]

Next: Hexagonal Architecture in Spring Boot — how to structure your code so that business logic tests run in 50ms instead of 45 seconds.

Java 26 Is Out — Here's What Actually Matters for Spring Boot Developers

Dominik Paszek — Tue, 17 Mar 2026 20:08:48 +0000

Java 26 Is Out — Here's What Actually Matters for Spring Boot Developers

Java 26 dropped today. And like every non-LTS release, most of the internet will spend the next week writing "everything new in Java 26" posts that include the Applet API removal and then act surprised you might care.

Let me skip straight to the three things that are actually relevant if you write Spring Boot applications for a living.

The release in one sentence

Ten JEPs, five final. No new language syntax reaches production-ready status. What you get is a faster runtime, HTTP/3 in the standard library, and the beginning of Java actually enforcing what final means.

1. G1 GC got faster — you don't have to do anything

JEP 522 redesigns how the G1 garbage collector tracks object references. Before this, application threads and GC threads shared a single card table, which meant they had to coordinate on every write barrier. The fix is a dual card table — each side gets its own, no more synchronization overhead.

The result is a 5–15% throughput improvement on reference-heavy workloads. Which is most Spring Boot applications — every HTTP request, every JPA entity load, every object you create in a service method benefits from this.

What do you have to do? Nothing. G1 is the default. Upgrade the JDK, collect the improvement for free.

If you're still on Java 21, this is also a good moment to notice what's accumulated since then. Compact Object Headers landed in Java 25 and reduce heap usage by roughly 22% by shrinking object headers from 12–16 bytes to 8. These two gains together are a meaningful performance argument for planning a migration.

2. HTTP/3 is finally in the JDK HttpClient

JEP 517. The HttpClient that ships with the JDK can now speak HTTP/3 over QUIC. The API change is one line:

HttpClient client = HttpClient.newBuilder()
        .version(HttpClient.Version.HTTP_3)
        .build();

If the server doesn't support HTTP/3, it falls back to HTTP/2 automatically. No QUIC library to pull in, no Netty configuration — it's in the JDK.

For Spring Boot: if you're using RestClient backed by the JDK HttpClient, you can configure this at the client level. If you're on WebClient with Reactor Netty (the WebFlux default), this doesn't apply yet — Netty has its own HTTP/3 story.

Where does this actually make a difference? High-concurrency external API calls, AI inference endpoints, payment gateway integrations. HTTP/3 eliminates head-of-line blocking — one slow request no longer holds up everything behind it on the same connection.

3. `final` is starting to actually mean final

This is the one that might show up in your logs whether you upgrade or not, because JEP 500 affects the third-party libraries your app already uses.

For years, you could do this:

Field field = SomeClass.class.getDeclaredField("FINAL_VALUE");
field.setAccessible(true);
field.set(instance, newValue); // mutates a final field

The JVM allowed it. A surprising number of libraries depend on it — Hibernate in some configurations, Mockito's spy mechanism, Lombok, various serialization frameworks.

On Java 26, doing this prints a warning:

WARNING: Final field SomeClass.FINAL_VALUE has been mutated reflectively

Still a warning, not an error. The error comes in a future release (timeline not confirmed). But the migration window is open now.

The action item: add Java 26 to your CI matrix and grep the logs for "has been mutated reflectively". Warnings from your own code are yours to fix. Warnings from libraries — check if a Java 26 compatible version exists.

Two flags worth knowing:

# Treat it as an error now — good for catching issues in CI before they matter
--illegal-final-field-mutation=deny

# Temporary suppression while you wait for library updates
--enable-final-field-mutation=ALL-UNNAMED

Spring Framework 7.0 has already cleaned up its reflection usage, so the framework itself is unlikely to be the source. Hibernate 7.x and test frameworks are the more probable culprits.

Bonus: UUIDv7 is now in the standard library

Not a JEP, just a method — but worth knowing. UUID.randomUUID() generates version 4 UUIDs, which are completely random. Used as database primary keys, they cause index fragmentation because every insert lands at a random position in the B-tree.

Java 26 adds UUID.ofEpochMillis(long timestamp), which generates time-ordered UUIDs. The first bits contain a millisecond timestamp, so new rows always insert at the end of the index. No library needed, no configuration, just a method swap.

The honest preview roundup

Structured Concurrency is in its sixth preview. It's been in preview since Java 19. This cycle adds onTimeout() to Joiner. It will be genuinely useful for async Spring Boot code when it's final. That day is not today.

The Vector API is in its eleventh incubation. It's explicitly waiting for Project Valhalla's Value Classes. No changes this cycle.

String Templates were previewed in Java 21 and 22, then withdrawn entirely because the design team decided the API wasn't right. Still no timeline.

Should you migrate?

Not to production. Java 26 gets six months of Premier support — it ends in September. That's not enough runway for production workloads that need long-term security patches.

The right play: stay on Java 25 LTS for production. Add Java 26 to your CI pipeline today to surface JEP 500 warnings from your dependencies. If you're still on Java 21, the accumulated changes since then — virtual thread pinning fixed, Compact Object Headers, improved AOT caching — make a migration to Java 25 LTS genuinely worth planning.

Spring Boot 4.0.x officially supports up to Java 25. Java 26 is "best effort" — it works in practice, but it's not guaranteed. Expect an upcoming patch release to add official documentation.

*Video walkthrough with code demos: https://youtu.be/qBgzvfx4gJk

How I Structure Every Spring Boot Application as a Senior Developer

Dominik Paszek — Thu, 12 Mar 2026 17:00:00 +0000

How I Structure Every Spring Boot Application as a Senior Developer

Six months ago I reviewed a Spring Boot codebase that had been running in production for two years. 40,000 lines of code. Eight developers. And every single package looked like this:

com.company.app
├── controller/
├── service/
├── repository/
└── model/

The team knew it was wrong. They'd talked about refactoring it "eventually." But after two years of features piled on top of each other inside those four folders, nobody dared touch it.

That's what bad project structure does. It doesn't break you on day one — it breaks you slowly, until the codebase becomes something you maintain instead of something you build.

This is the structure I use instead. And the reasoning behind every decision.

The Problem With Package by Layer

Package by layer is what every tutorial shows you. It's also the first thing you should move away from once your project grows past three endpoints.

The issue isn't the folders themselves — it's what they represent. Your packages describe the technology stack. They say nothing about what the system actually does. If I want to understand the User feature, I open four packages. If I want to delete the Order module, I hunt through every layer to find its pieces.

Package by feature is better. Everything about Users lives in one place. But it still mixes things that shouldn't be mixed — your JPA entity sits next to your domain object, your @Repository annotation lives in the same package as your business logic. When you want to swap JPA for JDBC, you're touching code you shouldn't have to touch.

The approach I settled on makes the dependency rule explicit in the folder structure itself.

The Structure

com.company.app
├── user/
│   ├── api/              ← HTTP: controllers, request/response DTOs
│   ├── domain/           ← business logic: entities, services, repository interfaces
│   └── infrastructure/   ← adapters: JPA, REST clients, mappers
├── order/
│   ├── api/
│   ├── domain/
│   └── infrastructure/
└── shared/               ← cross-cutting: exceptions, config

Three sub-packages inside each feature. One rule that governs all of them:

domain/ never imports from api/ or infrastructure/. Ever.

Your domain package has zero Spring annotations. No @Component, no @Autowired, no @Entity. It defines interfaces — what it needs — and infrastructure implements them. The domain is pure Java.

Why does this matter? Because when you want to swap your persistence layer, add a message queue, or test your business logic without booting Spring, you can. The domain doesn't know what surrounds it.

What This Looks Like in Code

The UserRepository in your domain package is an interface:

// user/domain/UserRepository.java
public interface UserRepository {
    Optional<User> findById(UserId id);
    User save(User user);
}

No JPA. No Spring. This is a port — it describes what the domain needs in its own language.

The JPA implementation lives in infrastructure and implements that interface:

// user/infrastructure/UserRepositoryAdapter.java
@Repository
public class UserRepositoryAdapter implements UserRepository {

    private final UserJpaRepository jpaRepository;
    private final UserMapper mapper;

    @Override
    public Optional<User> findById(UserId id) {
        return jpaRepository.findById(id.value())
            .map(mapper::toDomain);
    }
}

And your domain service test needs no Spring context at all:

class UserServiceTest {

    UserRepository repository = mock(UserRepository.class);
    UserService service = new UserService(repository);

    @Test
    void shouldReturnUser() {
        var user = new User(new UserId(UUID.randomUUID()), new Email("jan@example.com"));
        when(repository.findById(user.id())).thenReturn(Optional.of(user));

        assertThat(service.getUser(user.id()).email()).isEqualTo(user.email());
    }
}

No @SpringBootTest. No context loading. That test runs in milliseconds and tests exactly one thing.

Adding a Second Domain

When you add order/ next to user/, the same pattern repeats. What doesn't repeat — and shouldn't — is any import between the two.

// ✗ Wrong
// order/domain/OrderService.java
import com.company.app.user.domain.User; // direct cross-domain import

If you write this, you've coupled two independent features. Changing User can now break Order. You've recreated the tangled mess you were trying to escape — just with feature folders instead of layer folders.

The correct approach: Order doesn't need a User. It needs a UserId.

// shared/UserId.java
public record UserId(UUID value) {}

// order/domain/Order.java
public record Order(
    OrderId id,
    UserId customerId,   // ← just an ID, not the whole User
    Money total
) {}

Domains communicate through identifiers and events. Never through direct object imports. This is the rule that makes your features independently deployable if you ever need to split them into microservices.

Visibility as Architecture Enforcement

Most developers treat public/private as a style choice. I treat them as architecture.

// user/domain/UserService.java
public class UserService {

    // public — callable from api/ and infrastructure/
    public User getUser(UserId id) { ... }

    // package-private — stays inside domain/, no keyword needed
    void validateBusinessRules(User user) { ... }

    // private — implementation detail of this class
    private void applyAudit(User user) { ... }
}

That middle modifier — package-private, no keyword — is the most underused tool in Java. If a class or method in domain/ is package-private, nothing in api/ or infrastructure/ can import it. The compiler enforces your architecture for free. You don't need ArchUnit. You don't need custom rules. Just don't write public when you don't mean it.

My default: make everything package-private first. Promote to public only when something genuinely needs to cross a package boundary.

Java 21 Makes This Cleaner

Three features from modern Java that fit this structure well.

Records for domain objects and DTOs. Immutable by default, one line:

// domain
public record User(UserId id, Email email) {}

// api
public record UserResponse(String id, String email) {}

Sealed interfaces for domain states. The compiler knows every possible state:

public sealed interface OrderStatus
    permits Pending, Confirmed, Cancelled {}

record Pending()                     implements OrderStatus {}
record Confirmed(Instant at)         implements OrderStatus {}
record Cancelled(String reason)      implements OrderStatus {}

Pattern matching switch. No default branch needed — if you add a new state and forget to handle it somewhere, it's a compile error:

String label = switch (status) {
    case Pending   p -> "Waiting for confirmation";
    case Confirmed c -> "Confirmed at " + c.at();
    case Cancelled x -> "Cancelled: " + x.reason();
};

That last one is a big deal in practice. An enum with a default: throw new IllegalStateException(...) silently passes compilation. A sealed interface with pattern matching doesn't compile until every state is handled.

One Note on DDD

This is not full Domain-Driven Design. In DDD you'd have a fourth layer — application/ — sitting between api/ and domain/, for Use Cases and Command Handlers. Your domain model would use proper Aggregate Roots and Value Objects throughout.

What I've shown here is a lighter-weight approach that gives you 80% of the benefit without the full ceremony. It's also a solid foundation to migrate toward proper DDD if your project grows in that direction. We'll cover that properly in a dedicated episode.

When to Go Multi-Module

Not as soon as you think.

A single Maven module with good package discipline works for most projects. Go multi-module when you have a specific reason: different teams owning different domains with separate release cycles, or you want compile-time enforcement of boundaries (the domain module literally can't have Spring on its classpath).

Start with one module. Apply the folder structure. Extract modules when you have a concrete reason — not because you read somewhere that it's more "enterprise."

Test Structure

Mirror your main structure in tests, one class per production class:

src/
├── main/java/.../user/
│   ├── domain/UserService.java
│   └── infrastructure/UserRepositoryAdapter.java
└── test/java/.../user/
    ├── domain/UserServiceTest.java          ← plain JUnit, no Spring
    └── infrastructure/UserRepositoryIT.java ← @DataJpaTest

Domain tests: zero Spring context, run in milliseconds.

Infrastructure tests: @DataJpaTest or Testcontainers, test only the adapter.

API tests: @WebMvcTest, test only the controller slice.

Never load the full application context for a unit test. That's the number one cause of slow test suites — and a topic worth its own article.

The Short Version

If I had to summarise it in a few lines:

Package by feature as the outer layer
api/ / domain/ / infrastructure/ inside each feature
domain/ has zero Spring annotations, ever
Cross-domain communication through IDs, not object imports
Make things package-private by default, promote to public deliberately
Use Java 21 records and sealed interfaces — they fit this model naturally

More structure upfront? Yes, about 20 minutes. Saves hours later when the codebase actually grows.

Video walkthrough with full source code: YouTube link

Source code: GitLab link

Next up: Spring Boot @Transactional — five bugs that are probably in your production code right now.

Signals vs Observables — I Built the Same Feature 3 Ways. Here's What I Learned.

Dominik Paszek — Tue, 10 Mar 2026 19:00:00 +0000

Signals vs Observables — I Built the Same Feature 3 Ways. Here's What I Learned.

Every Angular tutorial explains what Signals are. Every RxJS guide explains what Observables are. Neither one tells you which to reach for when you sit down to write an actual component.

That question kept coming up in my own work. So I took a real feature — a search input with debounce and an HTTP call — and built it three ways. Same result on screen. Completely different code underneath.

Here's what I found.

The Feature

A search input. User types, list filters. Debounce 300ms before the HTTP call fires, so we're not hammering the API on every keystroke.

Simple enough that the code stays readable. Real enough that it shows up in production.

[ search input ] → debounce 300ms → HTTP call → [ user list ]

Way #1 — BehaviorSubject + async pipe

This is how Angular developers have been doing it for years. Nothing wrong with it.

@Component({
  selector: 'app-user',
  template: `
    <input (input)="search$.next($event.target.value)" />

    @for (user of results$ | async; track user.id) {
      <p>{{ user.name }}</p>
    }
  `
})
export class UserComponent {
  private readonly userService = inject(UserService);

  protected search$ = new BehaviorSubject<string>('');

  protected results$ = this.search$.pipe(
    debounceTime(300),
    distinctUntilChanged(),
    switchMap(query =>
      query ? this.userService.searchUsers(query) : of([])
    )
  );
}

What's good: battle-tested, the entire team knows how to read it, full RxJS power available in the pipeline.

What's not: look at the template. The async pipe is there. In a component with three or four streams, you start stacking async pipes everywhere — or reaching for *ngIf as tricks to combine them. The template starts to know too much about what's happening in the class.

Way #2 — BehaviorSubject + toSignal()

One change. We wrap the final Observable in toSignal() before it hits the template.

export class UserComponent {
  private readonly userService = inject(UserService);

  protected search$ = new BehaviorSubject<string>('');

  protected results = toSignal(
    this.search$.pipe(
      debounceTime(300),
      distinctUntilChanged(),
      switchMap(query =>
        query ? this.userService.searchUsers(query) : of([])
      )
    ),
    { initialValue: [] as UserData[] }
  );
}

Template:

@for (user of results(); track user.id) {
  <p>{{ user.name }}</p>
}

No async pipe. No subscribe(). Cleanup is automatic.

The RxJS pipeline stays exactly where it belongs — inside the component class, invisible to the template. toSignal() is just a thin wrapper at the output end that converts the Observable's last value into something the template can read synchronously.

This is my default recommendation for most situations. You get the full power of RxJS where you need it, and a clean template surface that doesn't leak implementation details.

One thing to remember: toSignal() must be called in an injection context — a field initializer or the constructor. Not in ngOnInit.

Way #3 — Signal + toObservable + toSignal

This is the fully modern approach. Zero Observables in the template, zero BehaviorSubject.

export class UserComponent {
  private readonly userService = inject(UserService);

  protected searchQuery = signal('');

  protected results = toSignal(
    toObservable(this.searchQuery).pipe(
      debounceTime(300),
      distinctUntilChanged(),
      switchMap(query =>
        query ? this.userService.searchUsers(query) : of([])
      )
    ),
    { initialValue: [] as UserData[] }
  );
}

Template:

<input
  [value]="searchQuery()"
  (input)="searchQuery.set($event.target.value)"
/>

@for (user of results(); track user.id) {
  <p>{{ user.name }}</p>
}

toObservable() bridges the Signal into the RxJS pipeline. toSignal() brings the result back out. The template only ever sees Signals.

One thing worth knowing: toObservable() uses effect() under the hood, which runs asynchronously — the Observable emits in the next microtask, not synchronously. For UI interactions and HTTP calls this is completely invisible. For synchronous unit tests, you'll need to flush microtasks explicitly with fakeAsync + flushMicrotasks().

The Decision Framework

After going through all three, here's how I think about it:

Working on legacy code?
Keep BehaviorSubject + async pipe. Don't refactor for sport. The risk isn't worth the cosmetic improvement.

New component, but you already have Observable sources coming in?
Wrap the result with toSignal(). Clean template, zero risk, works with any existing pipe chain.

New component, starting fresh?
signal + toObservable + toSignal. This is where Angular is heading. Zero subscriptions, zero manual cleanup, RxJS where it belongs.

Need to share state between components?
Signal in a service. That's a separate topic — but the short version is: a signal() defined at the service level, injected where needed, is the modern replacement for a shared BehaviorSubject.

What Actually Changed Across the Three

The RxJS pipeline — debounceTime, distinctUntilChanged, switchMap — is identical in all three. That part doesn't change. RxJS is still the right tool for time-based stream manipulation.

What changes is how you feed it input and how you expose the output. That's it.

Way #1: Observable in, Observable out, async pipe in template.
Way #2: Observable in, Signal out, no async pipe.
Way #3: Signal in, Signal out, no Observable anywhere in the template.

The further right you move, the more Angular Signals owns the surface area. The RxJS stays inside, doing exactly what it's good at.

Resources

Full video with live coding (all three approaches built from scratch): YouTube — Dominik Paszek
Source code: GitLab — link
Angular docs — rxjs-interop

If this kind of content is useful, the channel covers Angular, Spring Boot, Kubernetes and real production engineering patterns — no padding, no filler. Worth a subscribe if that's your area.

This wraps up the Angular Signals & RxJS block. Next up on the channel: Java, Spring Boot, backend architecture. Angular is coming back — Micro Frontends, state management at scale, performance patterns. Stay tuned.

toObservable() — How to Bridge Angular Signals and RxJS

Dominik Paszek — Thu, 05 Mar 2026 17:00:00 +0000

toObservable() — Bridging the Gap Between Angular Signals and RxJS

If you've been working with Angular Signals, you've probably hit this wall at some point.

You have a Signal — maybe a search input, maybe a selected filter from a dropdown — and you need to debounce it. Or switchMap it. Or pipe it through a chain of RxJS operators before sending it to an API.

And then you realise: Signals don't have debounceTime. They don't have switchMap. They live in a completely different reactive world.

That's where toObservable() comes in. It's the reverse bridge — and once you understand how it works, the combination of Signals and RxJS becomes genuinely powerful.

The Context: Two Reactive Worlds

Angular 16+ ships with two reactive primitives that serve different purposes:

Signals — synchronous, pull-based, zero boilerplate. Perfect for local component state and template bindings. No subscriptions, no cleanup, no async pipe.

Observables (RxJS) — asynchronous, push-based, operator-rich. Perfect for HTTP calls, debouncing, stream composition, and anything time-based.

The problem is that these two worlds don't talk to each other natively. That's why Angular ships @angular/core/rxjs-interop — a dedicated interop layer with two functions:

Observable ──── toSignal() ────▶ Signal
Signal     ──── toObservable() ──▶ Observable

In a previous article on toSignal(), we covered the first direction. This one is about the second.

What toObservable() Actually Does

At its core, toObservable() wraps a Signal in an Observable. Every time the Signal's value changes, the Observable emits that new value.

import { toObservable } from '@angular/core/rxjs-interop';

const searchQuery = signal('');
const searchQuery$ = toObservable(searchQuery);

// searchQuery$ now emits every time searchQuery changes

Under the hood, it uses Angular's effect() primitive — the same reactive context that tracks Signal reads. When the Signal changes, effect() fires, and the Observable emits.

This has one important implication worth knowing upfront.

The Async Timing Gotcha

Because toObservable() uses effect() internally, and effects always run asynchronously (in the next microtask), the Observable does not emit synchronously.

signal.set('new value')
       ↓
  NOT emitted synchronously
       ↓
  emitted in next microtask (async)

Why asynchronous? Because effect() is scheduled asynchronously by design — it protects against infinite reactive loops where a signal change triggers an effect that changes a signal that triggers an effect...

For 99% of real-world use cases — UI bindings, HTTP calls, debounced search — this doesn't matter at all. The timing is imperceptible to users.

Where it does matter: synchronous unit tests. If you set a signal value and immediately expect the Observable to have emitted, your test will fail. You'll need to flush microtasks (e.g. with fakeAsync + flushMicrotasks() in Angular's testing utilities).

Keep that in the back of your head and you'll never be surprised by it.

The Real Power: Combining Both Directions

Here's where things get interesting. The most common pattern isn't just converting a Signal to an Observable — it's using both conversion functions together to keep your component template completely free of RxJS concepts.

The pattern looks like this:

results = toSignal(
  toObservable(someSignal).pipe(
    // full RxJS pipeline here
  ),
  { initialValue: [] }
);

Signal in. Observable pipeline in the middle. Signal out. Your template never touches an Observable.

Let's build something real.

Real Example: Search with Debounce

The classic use case. A search input bound to a Signal, debounced, piped through an HTTP call, result exposed as a Signal.

The Component

import { Component, inject, signal } from '@angular/core';
import { toSignal, toObservable } from '@angular/core/rxjs-interop';
import { debounceTime, distinctUntilChanged, switchMap } from 'rxjs/operators';
import { of } from 'rxjs';
import { UserService } from './user.service';
import { UserData } from './user.model';

@Component({
  selector: 'app-user',
  imports: [],
  templateUrl: './user.html',
})
export class UserComponent {
  private readonly userService = inject(UserService);

  protected searchQuery = signal('');

  protected results = toSignal(
    toObservable(this.searchQuery).pipe(
      debounceTime(300),
      distinctUntilChanged(),
      switchMap(query =>
        query
          ? this.userService.searchUsers(query)
          : of([])
      )
    ),
    { initialValue: [] as UserData[] }
  );
}

The Template

<input
  [value]="searchQuery()"
  (input)="searchQuery.set($event.target.value)"
/>

@for (user of results(); track user.id) {
  <p>{{ user.name }}</p>
}

The Service

searchUsers(query: string): Observable<UserData[]> {
  return of(MOCK_USERS.filter(u =>
    u.name.toLowerCase().includes(query.toLowerCase())
  )).pipe(delay(500));
}

Take a moment to look at what this component doesn't have:

No ngOnInit
No subscribe()
No unsubscribe() or takeUntilDestroyed
No async pipe in the template
No BehaviorSubject

Two signals, one pipeline. The RxJS operators do exactly what they're good at — time-based stream manipulation — while Signals handle the template binding cleanly.

The query ? ... : of([]) check is a small but important production detail: if the search field is empty, return an empty array immediately instead of firing an API call.

Why Not Just Use a BehaviorSubject?

Fair question. The traditional approach using a BehaviorSubject as the source works perfectly well:

protected search$ = new BehaviorSubject<string>('');

protected results$ = this.search$.pipe(
  debounceTime(300),
  distinctUntilChanged(),
  switchMap(query => ...)
);

And in the template:

<input (input)="search$.next($event.target.value)" />

@for (user of results$ | async; track user.id) { ... }

This is battle-tested and there's nothing wrong with it. But notice what leaks into the template: the async pipe. In a component with multiple streams, you start stacking async pipes everywhere. The template starts to know too much about the reactive mechanics underneath.

The Signal approach keeps all of that inside the component class where it belongs. The template stays declarative and clean.

Injection Context Requirement

Like toSignal(), toObservable() must be called within an injection context. In practice this means:

In a field initializer (most common):

protected results = toSignal(toObservable(this.searchQuery).pipe(...));

In the constructor:

constructor() {
  this.results = toSignal(toObservable(this.searchQuery).pipe(...));
}

In ngOnInit — this will throw a runtime error.

The injection context requirement exists because toObservable() needs to register a cleanup callback tied to the component's lifecycle. Angular handles this automatically — you just need to make sure you're calling it in the right place.

Quick Reference

toObservable(signal)
  → Observable<T>
  → emits every time the signal changes
  → async (next microtask) — not synchronous
  → must be called in injection context
  → auto-cleanup — nothing to unsubscribe

Standard pattern:
  toSignal(
    toObservable(signal).pipe(
      debounceTime(300),
      switchMap(...)
    ),
    { initialValue: [] }
  )

Wrapping Up

toObservable() closes the loop between Angular's two reactive primitives. You get the simplicity of Signals for state and template binding, and the full expressiveness of RxJS for stream composition — without either one leaking into the other's domain.

The pattern toSignal(toObservable(signal).pipe(...)) is going to show up a lot in modern Angular codebases. Get comfortable with it now.

Resources

Full video walkthrough (with live coding demo): YouTube — Dominik Paszek
Source code: [GitLab — link]
Angular official docs — rxjs-interop

If this was useful, the YouTube channel covers Angular, Spring Boot, Kubernetes, and real production engineering patterns — no fluff, no padding. Worth a subscribe if that's your kind of content.

Part of the Angular Signals & RxJS series. Next up: choosing between Signals, Observables, and the bridge functions — a practical decision framework.

Stop Writing .subscribe() in Angular Components — Use toSignal Instead

Dominik Paszek — Tue, 03 Mar 2026 19:00:00 +0000

If you've been writing Angular for more than a week, you know this pattern by heart:

protected userData = signal<UserData | undefined>(undefined);

ngOnInit() {
  this.userService.getUserData()
    .pipe(
      tap(data => this.userData.set(data)),
      takeUntilDestroyed(this.destroyRef)
    )
    .subscribe();
}

Signal. Subscribe. tap. set. Cleanup. Every. Single. Time.

It works, but there's a lot of moving parts for something that boils down to "I want to show this data in my template." Turns out Angular has a one-liner for exactly this — toSignal.

The core idea

Observables and Signals live in different worlds. Observables are async — they emit values over time, can be cold or hot, and can stay silent for a while. Signals are synchronous — they always have a current value and work directly in templates without any pipe magic.

toSignal is the bridge. You hand it an Observable, it gives you back a Signal that:

subscribes automatically
updates on every emission
cleans itself up when the component is destroyed

Zero .subscribe() calls in your component.

Basic usage

import { toSignal } from '@angular/core/rxjs-interop';

@Component({ ... })
export class UserComponent {
  private readonly userService = inject(UserService);

  protected userData = toSignal(this.userService.getUserData());
}

That's it. No ngOnInit, no DestroyRef, no takeUntilDestroyed. The type is inferred automatically — because getUserData() returns Observable<UserData>, you get Signal<UserData | undefined> back.

In the template:

@if (userData(); as user) {
  <h2>{{ user.name }}</h2>
} @else {
  <p>Loading...</p>
}

No async pipe. Just call it like a function.

One rule to remember: toSignal must be called inside an injection context — a constructor, a field initializer, or a function called during construction. Same rules as inject().

Why `| undefined`?

There's a gap between when your component loads and when the Observable actually emits. Observables can be silent — Signals cannot. Before the first emission, the Signal needs something to hold. That something is undefined by default, hence Signal<T | undefined>.

You have two options to get rid of it.

Option 1: `initialValue`

Use this when you have a sensible empty state — an empty array, an empty string, a default object.

protected posts = toSignal(
  this.userService.getUserPosts(1),
  { initialValue: [] as Post[] }
);
// Type: Signal<Post[]> — no undefined

Option 2: `requireSync`

Use this when your Observable is guaranteed to emit synchronously — like a BehaviorSubject.

protected liveUser = toSignal(
  this.userService.getUserDataHot(),
  { requireSync: true }
);
// Type: Signal<UserData> — TypeScript knows it's never undefined

If you get this wrong and the Observable doesn't emit synchronously, Angular tells you immediately:

Error: NG0601: toSignal() was called with requireSync,
but the Observable did not emit synchronously.

No silent bugs. Fast feedback.

What about multiple signals from the same source?

This is where it gets slightly more interesting. If you need two signals derived from the same Observable, naively doing this creates two separate subscriptions:

protected userData = toSignal(this.userService.getUserData());
protected posts = toSignal(
  this.userService.getUserData().pipe(
    switchMap(data => this.userService.getUserPosts(data.id))
  )
);

The fix is shareReplay(1) — share the upstream, and replay the last value to any late subscribers:

private readonly userData$ = this.userService.getUserData().pipe(shareReplay(1));

protected userData = toSignal(this.userData$);
protected posts = toSignal(
  this.userData$.pipe(
    switchMap(data => this.userService.getUserPosts(data.id))
  ),
  { initialValue: [] as Post[] }
);

shareReplay(1) does two things: it multicasts (one HTTP request, multiple consumers) and it replays the last value to subscribers who come in slightly later — which matters because toSignal subscribes at slightly different times internally.

Auto-cleanup — same engine as `takeUntilDestroyed`

If you've seen the takeUntilDestroyed pattern, the cleanup story here is identical. toSignal internally grabs DestroyRef from the injection context and unsubscribes when the component is destroyed. You don't have to think about it.

That's also why the injection context requirement exists — without it, toSignal has no way to know when to clean up.

Quick reference

// Default — use when Observable is async and you have no meaningful fallback
toSignal(obs$)
// → Signal<T | undefined>

// initialValue — use when you have a sensible empty state
toSignal(obs$, { initialValue: [] as T[] })
// → Signal<T>

// requireSync — use with BehaviorSubject or any synchronous Observable
toSignal(obs$, { requireSync: true })
// → Signal<T>

Before / After

Before:

protected userData = signal<UserData | undefined>(undefined);
private readonly destroyRef = inject(DestroyRef);

ngOnInit() {
  this.userService.getUserData()
    .pipe(
      tap(data => this.userData.set(data)),
      switchMap(data => this.userService.getUserPosts(data.id)),
      takeUntilDestroyed(this.destroyRef)
    )
    .subscribe(posts => this.posts.set(posts));
}

After:

private readonly userData$ = this.userService.getUserData().pipe(shareReplay(1));

protected userData = toSignal(this.userData$);
protected posts = toSignal(
  this.userData$.pipe(switchMap(d => this.userService.getUserPosts(d.id))),
  { initialValue: [] as Post[] }
);

The component no longer knows that Observables even exist. It just has Signals.

This is part 2 of a series on modern Angular patterns. Part 1 covered takeUntilDestroyed and Hot vs Cold Observables. Next up: toObservable — going the other direction, from Signal back to Observable.

The Angular memory leak that kept sneaking into my code (and how to fix it)

Dominik Paszek — Fri, 27 Feb 2026 11:16:13 +0000

Hey DEV community,

In my day-to-day work reviewing Angular codebases, there is one specific memory leak that constantly sneaks into pull requests. It’s a silent performance killer that happens when we navigate between pages, and it usually slips right past standard testing.

Instead of just writing another comment on a PR, I realized it's much easier to show the problem visually. So, I decided to step completely out of my comfort zone and record my first-ever YouTube coding tutorial.

I quickly learned that centering a div is an absolute breeze compared to editing out my "umms" and trying to animate RxJS streams.

Here is the "TL;DR" of what I cover, in case you prefer reading over watching:
The "Unsubscribe from Everything" Myth

A lot of developers are taught to aggressively unsubscribe from absolutely every observable. But Angular's HttpClient returns "Cold Observables". They emit a value, complete, and clean up after themselves automatically. No memory leak there.

The real danger comes from "Hot Observables" like a global BehaviorSubject (e.g., in a shared service or NgRx store). If your component subscribes to it, and the user navigates away, the component is visually destroyed. But the RxJS stream doesn't know that. It keeps firing data at the ghost component in the background, and your RAM usage slowly climbs.

The Modern Angular 16+ Fix

We used to do the whole ngOnDestroy dance with .unsubscribe(). Now, we have a much cleaner way: takeUntilDestroyed().

export class UserProfileComponent implements OnInit {
  private destroyRef = inject(DestroyRef);
  private userService = inject(UserService);

ngOnInit() {
    this.userService.getUserData()
     .pipe(takeUntilDestroyed(this.destroyRef)) // This single line fixes the leak
     .subscribe(data => {
        console.log('Data received:', data);
      });
  }
}

Nested Subscribes (Callback Hell)

The other thing I tackle in the video is when one API call depends on another (like fetching a user ID, then fetching their posts). Nesting subscribe inside another subscribe creates race conditions. I show how to flatten this using the switchMap operator, which also automatically cancels outdated in-flight requests in the Network tab.
The Video

I tried to make this as visual as possible. I actually open up the Chrome DevTools Memory tab to show the exact moment the RAM spikes, how to track detached DOM nodes, and how the memory Delta drops back to zero after the fix.

Since this is literally my first time recording, editing, and trying to make technical animations, I’d really appreciate your honest feedback. Did the DevTools explanation make sense? And please, any tips from experienced video creators on how to make the next one less painful to edit would be amazing!

Thanks for reading (and watching)!

Forem: Dominik Paszek

Aggregate Root in Spring Boot — Sealed Classes, Lifecycle Guards, and Why @Entity Doesn't Go on Your Domain Object

Aggregate Root in Spring Boot — Sealed Classes, Lifecycle Guards, and Why @entity Doesn't Go on Your Domain Object

What Is an Aggregate Root?

BaseAggregateRoot

Parcel as an Aggregate Root

Lifecycle Guards

Order — Sealed Class, Two ARs

Why @entity Doesn't Go on Parcel

What Is NOT an Aggregate Root

Next Episode

Primitive Obsession in Spring Boot DDD — before and after replacing UUID/Integer/String with Value Objects (code + video)

Your Compiler Could Have Caught This Bug. It Didn't.

The Problem: Primitive Obsession

What Is a Value Object?

Step 1: Unit — The Smallest Value Object

Step 2: PackageSize — Replacing Three Integers

Step 3: PackageWeight — Immutability With Operations

Step 4: LockerAddress — Grouping Related Strings

How to Persist Value Objects

Where They Live

The Point

Hexagonal Architecture in Spring Boot — Win a Free Book

We're Running a Contest — Refactor to Hexagonal Architecture and Win a Book

What the video covers

The contest

Spring Boot @Transactional: 5 Bugs That Are Probably in Your Production Code

Spring Boot @Transactional: 5 Bugs That Are Probably in Your Production Code

Why these bugs are hard to find: the proxy model

Bug #1 — Self-invocation

Bug #2 — Checked exceptions commit

Bug #3 — Private and final methods

Bug #4 — REQUIRES_NEW deadlock

Bug #5 — readOnly=true silently drops writes

The pattern behind all five

Cheat sheet

Java 26 Is Out — Here's What Actually Matters for Spring Boot Developers

Java 26 Is Out — Here's What Actually Matters for Spring Boot Developers

The release in one sentence

1. G1 GC got faster — you don't have to do anything

2. HTTP/3 is finally in the JDK HttpClient

3. final is starting to actually mean final

Bonus: UUIDv7 is now in the standard library

The honest preview roundup

Should you migrate?

How I Structure Every Spring Boot Application as a Senior Developer

How I Structure Every Spring Boot Application as a Senior Developer

The Problem With Package by Layer

The Structure

What This Looks Like in Code

Adding a Second Domain

Visibility as Architecture Enforcement

Java 21 Makes This Cleaner

One Note on DDD

When to Go Multi-Module

Test Structure

The Short Version

Signals vs Observables — I Built the Same Feature 3 Ways. Here's What I Learned.

Signals vs Observables — I Built the Same Feature 3 Ways. Here's What I Learned.

The Feature

Way #1 — BehaviorSubject + async pipe

Way #2 — BehaviorSubject + toSignal()

Way #3 — Signal + toObservable + toSignal

The Decision Framework

What Actually Changed Across the Three

Resources

toObservable() — How to Bridge Angular Signals and RxJS

toObservable() — Bridging the Gap Between Angular Signals and RxJS

The Context: Two Reactive Worlds

What toObservable() Actually Does

The Async Timing Gotcha

The Real Power: Combining Both Directions

Real Example: Search with Debounce

The Component

The Template

The Service

Why Not Just Use a BehaviorSubject?

Injection Context Requirement

Quick Reference

Wrapping Up

3. `final` is starting to actually mean final

Why `| undefined`?

Option 1: `initialValue`

Option 2: `requireSync`

Auto-cleanup — same engine as `takeUntilDestroyed`