Subscribe now

Manager:

"We're behind schedule! We need more developers."

Senior developers don’t think:

"Great, we'll finish sooner."

Instead, it's more like:

“We’re about to spend the next month onboarding.”

Because they know what comes next…

• Onboarding

• Interruptions

• Explaining codebase

• More meetings

• More PR reviews

• More merge conflicts

The Rules Nobody Wrote Down

The system is a tangled mess of dependencies.

But after working on it for years, experienced developers have learned to navigate the mess.

They know:

• “Don’t touch that class.”

• “Only Mike understands billing.”

• “Changing this always breaks reporting.”

• “That test is flaky, just rerun it.”

They’ve built a mental map of the codebase.

A new developer hasn’t.

Every feature starts with: “Who knows this part of the system?”

They need someone to explain the codebase, the architecture, and all the hidden pitfalls nobody documented.

More detailed code reviews.

More meetings.

More Developers. Less Progress.

The bottleneck isn’t the number of developers.

It’s the architecture.

When the system is tightly coupled, every change collides with another change.

Adding more people doesn't remove the bottleneck.

It just makes it worse.

📅 Join me: Clean Architecture for Backend Developers on Wed 26th Aug, 5:00 - 6:30 PM (CEST)

Clean Architecture in Practice →

Subscribe now

Your ORM has entities.

Clean Architecture talks about entities.

They sound like the same thing.

They’re not.

❌ Your ORM Becomes Your Domain

You create an ORM entity (JPA entity) because you need to store orders.

@Entity
class Order {
    @Id
    private Long id;

    private OrderStatus status;
    private int quantity;
    private BigDecimal unitPrice;
}

And an ORM repository (JPA repository) to save and load it:

interface OrderJpaRepository extends JpaRepository<Order, Long> {
    // findById and save come out-of-the-box:
    // Optional<Order> findById(Long id);
    // Order save(Order order);
}

So far, so good.

Its job is persistence.

Then you need to place an order — and you expect an order to be in a valid state before it is saved. So you give Order a constructor that refuses to build an invalid order — e.g. one with a non-positive quantity or a null unit price:

Order(int quantity, BigDecimal unitPrice) {
    if (quantity <= 0) {
        throw new RuntimeException("quantity must be positive");
    }

    if (unitPrice == null) {
        throw new RuntimeException("unit price is required");
    }

    this.status = OrderStatus.PLACED;
    this.quantity = quantity;
    this.unitPrice = unitPrice;
}

Now an Order cannot exist in a broken state.

Your use case builds one through it:

class PlaceOrder {

    void execute(int quantity, BigDecimal unitPrice) {
        var order = new Order(quantity, unitPrice);
        orderRepository.save(order);
    }
}

And your use case depends on it.

Your ORM entity has become your domain entity.

It looks fine. It compiles. It runs.

Except — declaring that constructor removed Java’s free no-arg one. And JPA cannot live without one.

That’s worse than a plain compile error. It compiles, it starts up, and it even saves correctly — then breaks the first time someone reads the order back. Nothing warns you until then.

So you’re forced to add it back:

protected Order() {}   // required by JPA — status null, quantity 0, unitPrice null

You wrote a constructor to reject invalid orders.

JPA makes you add a no-arg one next to it — one that builds an order with a null status, zero quantity, no price.

Marking it protected doesn’t help. When Hibernate loads a row, it ignores every access modifier by using reflection: it invokes that no-arg constructor, then sets the fields one by one.

Your validating constructor never runs. Your checks never execute.

An order no business would accept — and Hibernate builds one on every load.

Here is the problem.

An object can only enforce its invariants in one place: its constructor. JPA bypasses it — it forces a no-arg constructor, then sets the fields by reflection, skipping your real constructor on every load.

So the real problem is not that “your domain is coupled.”

It’s this:

This entity cannot guarantee it's always valid (enforce business rules).

Your validation only runs when you call the constructor yourself. JPA never calls it — on every load it constructs the object empty and sets the fields directly.

And every transition you validate later — cancel, ship, and so on — then runs on an object that was never validated in the first place.

The code compiles, it runs, and every invariant you thought you wrote is optional.

And it doesn’t stop at Order.

Use a Money value object instead of BigDecimal — immutable, always valid, exactly what DDD wants:

final class Money {
    private final BigDecimal amount;

    Money(BigDecimal amount) {
        if (amount == null) {
            throw new RuntimeException("amount is required");
        }

        this.amount = amount;
    }
}

To persist it, JPA needs it as @Embeddable. And @Embeddable demands the same price: drop final, add a no-arg constructor.

@Embeddable
class Money {                    // no longer final
    private BigDecimal amount;   // no longer final

    protected Money() {}         // required by JPA — amount null

    Money(BigDecimal amount) {
        if (amount == null) {
            throw new RuntimeException("amount is required");
        }

        this.amount = amount;
    }
}

Your always-valid Money can now be built with a null amount too.

The trap isn’t contained to one class. It spreads to every value object you embed.

Notice what’s happening. You’re no longer modelling the domain — you’re shaping it to fit the ORM. You drop final, add constructors you’d never write, expose state you meant to hide — not because the business asked for it, but because the ORM expects it that way.

You end up violating the very principles the domain is supposed to protect, encapsulation first among them, just to keep the persistence framework happy.

That is not Clean Architecture.

Want to avoid the ORM trap?

📅 Join me: Clean Architecture for Backend Developers on Wed 26th Aug, 5:00 - 6:30 PM (CEST)

✅Domain ≠ ORM

Read more

Subscribe now

Every project starts simple

Most enterprise applications begin with relatively simple requirements.

Creating records.

Updating data.

Calling external systems.

Displaying results.

At this stage, almost any architecture works. The codebase is small, everyone understands it, and adding new features is straightforward.

Then the project grows.

“Just this once”

A business rule needs data that’s already available in the repository.

Instead of passing it back to the use case, the rule is implemented directly in the repository.

It’s only a few lines.

No one wants to create another object or move data around.

The feature ships.

A few weeks later, another feature needs something similar.

The repository already knows about the data, so another business rule is added there.

Still reasonable.

Still working.

Still “just this once.”

Convenience becomes the architecture

As deadlines become tighter, convenience starts winning.

A controller performs a quick permission check because it’s only needed there.

A service calls another service because it avoids duplicating code.

An external API client starts making business decisions because it already has the response.

A repository calculates values because it has all the necessary information.

None of this breaks the application.

But it weakens the boundaries between business logic and infrastructure.

The cost doesn’t appear immediately

This is why architectural decay is so difficult to notice.

The application still works.

Tests still pass.

Deployments continue.

The problem appears months later.

A business rule needs changing.

Now the team isn’t sure where that rule actually lives.

Part of it is in a controller.

Part is inside a repository.

Another piece exists in an API adapter.

There’s similar logic somewhere else too—but no one knows whether it’s safe to change.

A feature that should have taken an hour becomes an afternoon of investigation.

Not because the rule is complicated.

Because the architecture is a Big Ball of Mud.

You’re told: “Why is it taking so long? It’s just a simple requirement.”

The trap is delaying

Most teams recognize when the codebase is becoming harder to change.

They simply postpone doing anything about it.

“We’ll clean it up later.”

“We’ll refactor after this release.”

“We don’t have time right now.”

Meanwhile, every new feature adds another dependency, another shortcut, another place where business logic leaks into infrastructure.

Eventually, everyone agrees the system needs refactoring.
It’s just too difficult to start.

Join the live training session:

Clean Architecture for Backend Developers

🗓 Aug 26
⏰ 5:00–6:30 PM (CEST)

🏆Register now

🏆 Register now

🔒Hello, this is Valentina with a premium issue of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code. This article is part of the TDD in Legacy Code series.

Subscribe now

Backend Component Tests provide fast feedback

We’ve seen in the previous article Backend Component Tests in Legacy Code, that Component Tests can provide us with fast feedback. The Backend Team can test the Backend in isolation, by stubbing out External Systems (such as the ERP).

But they can be a maintenance nightmare!

In Backend Component Tests in Legacy Code, we illustrated the “simplest” Backend Component Test.

The simplest way to write a Backend Component Test is to stub the External System inline (with WireMock), call the Backend API directly (with WebTestClient), and read the response by digging into raw JSON paths.

@Test
void shouldCreateOrderWithTotalPrice() {
    // Arrange
    var productDto = new ProductDto(2.50);
    var productDtoJson = objectMapper.writeValueAsString(productDto);
    erpWireMockStub.stubFor(WireMock.get(“/products?sku=APPLE1001”)
        .willReturn(WireMock.aResponse()
            .withStatus(200)
            .withHeader(“Content-Type”, “application/json”)
            .withBody(productDtoJson)));

    var orderRequest = new OrderRequest(“APPLE1001”, 5);

    // Act & Assert
    webTestClient.post()
        .uri(“/api/orders”)
        .contentType(MediaType.APPLICATION_JSON)
        .bodyValue(orderRequest)
        .exchange()
        .expectStatus().isCreated()
        .expectBody()
        .jsonPath(“$.totalPrice”).isEqualTo(12.5);
}

The problem is that this test is coupled in three places at once: the ERP wire format (the WireMock stub), the Backend API endpoint (webTestClient.post().uri("/api/orders")), and the response (the raw $.totalPrice JSON path).

If the API endpoint changes, or the ERP’s wire format changes (a renamed field, a different status code), then many such tests may break, so we have to waste time fixing tests. The plumbing is also copy-pasted into every test.

How to write maintainable Backend Component Tests?

In this article, I’ll show you how to introduce layers of abstraction, i.e. Component Test Architecture, so that you spend much less time writing & maintaining these tests.

Here are the steps to introduce Maintainable Backend Component Tests in Legacy Code. You’ll get tasks to implement in your GitHub Sandbox Project. ⬇️⬇️⬇️

Read more

Subscribe now

Think back to why you got into this.

Not the title or the pay bump. You wanted to be the person who shapes how the system is built instead of just closing the next ticket.

But how much of last month did you actually spend being that person? Or did it disappear into a three-day slog to make a small change — hoping it wouldn’t break something you couldn’t see?

“Can you just add a field?”

You know the one. A stakeholder wants one extra value on a form, and it lands on your desk — because you’re the one who gets handed the changes nobody else wants to touch. It’s a field. An afternoon, you figure.

Three days later you’re still in it.

The field touched a model. The model was wired straight into a service. The service was called from four places, two of which you didn’t know existed. There were no tests, so every change was a guess you couldn’t verify. And half of it was written by someone who left eighteen months ago, in a style you spent most of Tuesday just reading before you dared touch it.

The field took twenty minutes.

Everything around it took three days.

But… it didn’t feel like work. It felt like waste. Three days of picking through someone else’s tangle just to safely add a field — and not one minute of it went into anything that mattered, or anything that even held your interest.

You closed the ticket bored, drained, and quietly resentful that this is what your week had become.

Little fixes get in the way of better architecture

What makes it maddening is that you can see the work you’d rather be doing. You want to step back and redesign this — draw the boundaries that should’ve been there, untangle the core, build something that doesn’t fight you on every change. That’s the work that’s interesting. That’s the work that makes an impact.

But you never get to it, because there’s always one more little fix in the way, and the little fixes never stop.

And here’s what all that lost time costs you — the system you actually want to build:

• The clean, decoupled layers you know how to design — where a change lands in one place instead of rippling through five — stay tangled, because you only ever get time to patch, never to reshape.

• The codebase that could be a pleasure to move through stays a maze you have to re-learn every time you open it.

• The architecture you can already picture loses, every single sprint, to one more little fix you can’t say no to.

You just notice, a year in, that you’re working as hard as ever, more bored than you’ve ever been, and no closer to the system you wanted to build.

You’re stuck in a vicious cycle

This isn’t bad luck, and it isn’t a talent problem.

The architecture is tightly coupled, so every change is slow and risky. Because every change is slow, there’s never a clear stretch of time to stop and fix the coupling — so you patch around it instead. And every patch wires one more thing to one more thing, which makes the next change even slower.

Tightly coupled architecture. When everything reaches into everything else, a “small” change doesn’t stay small — it ripples across half the codebase, because half the codebase depends on the thing you touched.

No tests, or tests you can’t trust. Without them, every change is a leap in the dark. You can’t move boldly, so you move carefully — and careful is slow.

Unreadable code. Before you can change anything, you have to understand it. If understanding takes a day, every change loses a day to just figuring out what’s there before the real work even starts.

That’s why it doesn’t just stay annoying — it compounds. And the worst part is that you can see it happening: you’re being asked to add another floor to a house you know has no foundations. Every feature makes the structure taller and shakier, and you can feel that one ordinary change, on one ordinary day, is going to bring a piece of it down.

Get the architecture right and everything else gets easier

Here’s the reframe that changes how you spend your week: the architecture isn’t a chore for when there’s spare time, and it isn’t polish you bolt on at the end — it’s the one thing that everything else rides on.

The shape of the system — where the boundaries sit, what depends on what, how independent the core is — decides whether the next change lands in an afternoon or turns into another three-day dig.

And this is exactly where a senior developer makes their mark.

You’re the one teammates already ask “where should this go?” You’re the one who can introduce a boundary, decouple the layers so the core stops depending on the framework around it — and set the pattern the rest of the codebase follows.

You know the architecture is painful

You didn’t become a senior developer to spend three days adding a field.

But that’s what a lot of backend work becomes.

Not because the feature is hard.
Because the system is.

Join the live session:

Clean Architecture for Backend Developers

🗓 Aug 26
⏰ 5:00–6:30 PM (CEST)

🏆Register now

And if you want to talk it through for your situation — not the textbook version — come join the Optivem Circle Membership

Subscribe now

When I first started using ATDD with AI, I did what most people would do.

I wrote a document describing the ATDD process, so that the agent could read that document. The AI was behaving unreliably, sometimes skipping steps in the process - e.g. implementing the code and testing simultaneously, rather than writing the test before the code. I also wasted so many tokens and ended up with an additional > $1,000 bill.

Based on that lesson, I dug into token optimization, including splitting up that document. But still AI was behaving unreliably and I was spending a lot of tokens.

Then I realized the fundamental mistake that I was making…

That’s why in this live session, I shared my lessons learnt and my approach to practicing ATDD & AI effectively.

1. In the live session, I gave the big picture of my ATDD AI workflow design

2. I’m also writing the book “ATDD with AI Agents” - join the waitlist.

3. And, if you want to practice ATDD in your real life job, I’m opening enrollments for the ATDD Accelerator program. Limited spots. Book a call.

Read more

Subscribe now

Ask a manager what a developer does all day and you’ll get one answer:

They code.

The manager pictures eight hours of typing, so when a “two-day” change takes a week, the gap looks like slack.

But the picture is wrong.

Where the time actually goes

Coding is just a small slice.

The rest is:

• Testing — the developer tests it, then QA tests it again

• Deployment — still a manual procedure in most organizations, repeated for every environment

• Code review — PRs that sit, get comments, get revised, get re-reviewed

• Requirements — scattered across tickets, email, Slack, and three half-remembered conversations

• Meetings — the standing tax on every working day

• Rework — the change that comes back because the developer, QA and the PO each understood the requirement differently

The frustrating part, if you’re the one doing the work, is that the thing you actually wanted to do — design and code — is the sliver you fight to protect.

Everything else eats the day.

AI optimized the wrong thing

Because if coding was never the bottleneck…

You’ve sped up the smallest slice and left testing, deployment, review, requirements, and rework exactly where they were.

Faster code without guardrails makes delivery slower

More code, faster — without guardrails (automated testing, automated deployment) — means more regression bugs slip through.

Those regression bugs land on the same manual QA who were already a bottleneck, now buried under even more changes to verify by hand.

And this is happening alongside layoffs justified by “AI makes us faster.”

The real lever is the whole pipeline

If most of the delivery time is non-coding work, build the pipeline so the non-coding steps run automatically.

Testing and deployment are often executed by someone following manual procedures.
But it shouldn’t be.

Unit testing should be run on every change. Deployment and system testing should be run on a regular interval. In this way, we get faster feedback. We refuse to promote anything that fails.

See It in Practice

This isn’t a course you watch alone at 2x speed and forget by Friday.

What you’ll learn:

1. Pipeline Architecture. Stages — Commit, Acceptance, Release — what belongs in each, and why testing the same build makes deployments predictable

2. AI, TDD & ATDD in the Pipeline. Automated tests — unit, narrow integration, component, contract, smoke, acceptance, external system contract, e2e — and how AI & ATDD/TDD workflows fit within the Pipeline

3. Apply it with your team. How to present this architecture to your team, get buy-in, and start the move away from firefighting

When: June 24–25, 2026 | 5-7 PM CET
Where: Live on Zoom
Duration: 4 hours (2 sessions x 2 hours)

💻 Who it’s for: Senior Engineers and Tech Leads who are stuck with stressful releases and ready to do something about it

🚀 Register: Pipelines Workshop
Get €100 off with code DISCOUNT_100

Want to stop stressful releases, late-night fixes, and broken deployments? I’m running a hands-on Pipelines Workshop on June 24-25 (4 hours).

Join the workshop →

Limited spots. Register now with - €100 off with code DISCOUNT_100

Subscribe now

“Should we build once, or build per environment?”

“Should production have its own deploy workflow?”

These are the same question.

The first is about running a fresh docker build per environment — one build for QA, another for production, “because production needs different config baked in.”

The second is about writing a separate deploy workflow per environment — a deploy-qa.yml, a deploy-production.yml, each with its own steps and copy-pasted-then-edited logic, drifting apart commit by commit.

Both come from the same place: this environment is special, so it needs its own thing.

A pipeline’s entire job is to make “what we tested” and “what we shipped” the same. Every per-environment fork is a place where they quietly stop being the same.

Build once: no second build

The build is created in the Commit Stage. Every stage after that uses the same build — it gets tagged and deployed, but never rebuilt.

The temptation to rebuild happens because of configuration: “production needs the production API URL,” “QA needs the QA feature flags.”

So a second docker build happens with different build args, and now production is running a build that no test ever ran against. The green checkmark from QA is for a different build than the one customers actually get.

The build has no environment. Configuration is injected at deploy time — environment variables, mounted config, secrets from the environment — into the same build. That’s what allows the same build to move from Acceptance to QA to Production unchanged.

⚡Want to stop stressful releases, late-night fixes, and broken deployments?

Join the workshop →

Limited spots. Register now - 100 EUR off with code DISCOUNT_100

Deploy once: same script, different environment

Here’s the same deploy step running in three different environments.

Acceptance:

- name: Deploy
  uses: acme/actions/deploy@v1
  with:
    environment: acceptance
    version: ${{ inputs.version }}     # the system version, e.g. v2.5.0-rc.3
    image-urls: |
      ghcr.io/acme/shop/frontend
      ghcr.io/acme/shop/backend

Read more

Subscribe now

Every ticket gets a branch.

Nobody decided this. There was no meeting, no architecture review, no trade-off weighed. It’s just the reflex — the default Git workflow everyone inherited the day they learned git checkout -b. New ticket, new branch. Open it, work on it for as long as the work takes, merge it when it’s done.

And it is quietly the reason “we do CI” is a lie.

A branch that lives for a week is not CI. It’s a private fork.

And a private fork is the opposite of continuous integration — you are NOT integrating continuously. You are integrating at the end.

A Long-Lived Branch Is a Private Fork

Here is what a feature branch actually is: a copy of the codebase that diverges from everyone else’s copy, a little more, every single day it stays open.

On day one, the difference is small — your branch and main differ by your few lines.

By day five, main has changed — three other developers merged their own week-long branches. Your feature branch has changed too, and you only find out how far apart they are when you try to merge.

The conflicts aren’t just textual. Two developers refactored the same function for different reasons. A method you are calling got deleted. An interface was modified.

The merge you keep deferring is getting more expensive every day you don’t do it.

This is the trap: merging hurts, so the team merges less often, so branches live longer, so the next merge hurts more. “I’ll keep my work isolated until it’s solid” — is the exact thing causing the pain.

Trunk-Based Development

Trunk-based development is the decision to stop deferring.

It’s not “no branches.” That’s the strawman people use to dismiss it. It’s no long-lived branches

✔ Everyone integrates to main at least once a day.

✔ Branches are fine — as long as they live hours, not weeks.

✔ The trunk is the single shared integration point. There is no “at the end” — only now.

❌ No branch that survives the sprint.

❌ No “I’ll merge it when the feature is done.”

The whole mechanism is small batches. Integrate a little, constantly, and changes never get big enough to become a conflict.

The merge that hurt when you did it once a week stops hurting when you do it three times a day — not because the work got easier, but because each piece is small enough that there’s nothing to collide with.

You’re not avoiding the painful thing. You’re doing it so often it stops being painful.

“But how do we ship half-finished work?”

This is the real objection. If I merge to main every day, and my feature takes two weeks, won’t I be pushing broken, half-built code into the shared trunk?

No — because you hide unfinished work in main, not from main.

With Trunk-based development you integrate incomplete work safely:

• Feature flags — the code is merged and deployed, but dark. It doesn’t run until you enable it.

• Branch by abstraction — add an abstraction layer (like an interface) in front of old code, and swap the implementation behind it incrementally, with main green the entire time.

• Keystone interface — build the feature, but don’t expose it to users yet. “Turn on” the feature in the UI at the end.

You integrate code that isn’t finished without integrating code that’s broken. The feature is incomplete; the trunk is always releasable. This makes sense once you stop thinking “merged” = “done”.

The team that says “we can’t do trunk-based, our features are too big to finish in a day” has it backwards.

The features don’t have to be finished in a day. The integrations do.

How Long Do Your Branches Live?

You don’t need to think too hard to know which camp you’re in. Open your repo’s branch list and find the oldest open branch. Look at its age.

If it’s measured in hours, you’re integrating. If it’s measured in days or sprints, you’re feature branching — and every one of those branches is a deferred merge that gets harder over time, no matter how green the build looks today.

Trunk-based development isn’t “no branches.” It’s no long-lived ones.

The thing that breaks CI was never branching itself — it’s how long the branch lived before it was merged into main. Shrink the branch lifetime, and the merge pain you’ve organised your whole workflow around avoiding simply stops existing.

👉 Next week, I’m running a live workshop where we walk through a working e-shop example with a pipeline architecture, so you can see how it works in practice.

No rebuild hacks. No “it passed CI but broke anyway” surprises.

Join Pipelines Workshop →

That’s not on you — it’s the gap between the book and reality. ORM entities sneaking into the domain, business logic forced into memory until the system crawls, external DTOs leaking straight into your core. I see these three mistakes in almost every codebase that “did Clean Architecture.”

📅 Join me: Clean Architecture: Stop doing it wrong on Wed 26th Aug, 5:00 - 6:30 PM (CEST)

→ Reserve your spot

🔒 Hello, this is Valentina with a premium issue of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code.

Subscribe now

Misconception: “Repository interfaces exist so databases can be swapped”

One of the most common criticisms of Hexagonal Architecture and Clean Architecture goes like this:

“Why are you abstracting over the database? You’re never going to swap it anyway.”

And honestly?

If the goal is database swappability, I partly agree.

Most teams aren’t going to wake up tomorrow and replace PostgreSQL with MongoDB.

Most applications will use the same database for years.

So if database swappability is your main justification for repository interfaces, it’s not a particularly convincing one.

But that’s not why I use them.

❌ Dragging the database into every change and every test

You want to test:

Premium customers receive 20% discount.
Regular customers receive 5% discount.

That sounds simple.

But if the business logic directly calls ORM classes / uses Entity Framework or JPA, the test looks like this:

1. Insert test customer
2. Execute business logic
3. Read result
4. Clean database

@SpringBootTest
@Testcontainers
class DiscountServiceDatabaseTest {

    @Container
    static PostgreSQLContainer<?> postgres =
        new PostgreSQLContainer<>("postgres:16");

    @DynamicPropertySource
    static void datasource(DynamicPropertyRegistry registry) {
        registry.add("spring.datasource.url", postgres::getJdbcUrl);
        registry.add("spring.datasource.username", postgres::getUsername);
        registry.add("spring.datasource.password", postgres::getPassword);
    }

    @Autowired CustomerRepository customers;       // JPA repository
    @Autowired DiscountService discountService;    // business logic, talks to JPA directly

    @AfterEach
    void cleanUp() {
        customers.deleteAll();                     // 4. clean database
    }

    @Test
    void premiumCustomersReceive20PercentDiscount() {
        // 1. insert test customer
        var alice = customers.save(new CustomerEntity("Alice", Tier.PREMIUM));

        // 2. execute business logic (which loads the customer back out of the DB)
        var finalPrice = discountService.priceFor(alice.getId(), BigDecimal.valueOf(100));

        // 3. read result
        assertThat(finalPrice).isEqualTo(BigDecimal.valueOf(80));
    }

    @Test
    void regularCustomersReceive5PercentDiscount() {
        // 1. insert test customer
        var bob = customers.save(new CustomerEntity("Bob", Tier.REGULAR));

        // 2. execute business logic (which loads the customer back out of the DB)
        var finalPrice = discountService.priceFor(bob.getId(), BigDecimal.valueOf(100));

        // 3. read result
        assertThat(finalPrice).isEqualTo(BigDecimal.valueOf(95));
    }
}

Just to verify a discount calculation.

The database isn’t the thing you’re interested in.

The business rule is.

But you’re forced to involve the database just to test it.

✅ Repository interfaces exist so business logic can be tested independently from infrastructure

Read more

Subscribe now

The cost of software is NOT in writing it.

The real cost is:
maintaining it,
changing it,
debugging it,
extending it,
and understanding it years later.

Does code quality matter?

I came to realize that software maintenance has a high cost because:

• Tightly coupled architecture → a “small” change ripples across half the codebase

• No tests or poor tests → no protection when making a change

• Unreadable code → hard to make any change (update code or add new feature)

With poor technical practices, software maintenance costs skyrocket, become unmanageable, and eventually, like an avalanche, destroy successful products.

Clean Architecture and testing are NOT optional.

That’s why I want to show you how to design your architecture such that it is maintainable & testable.

Join the live session:

Clean Architecture for Backend Developers

🗓 Aug 26
⏰ 5:00–6:30 PM (CEST)

🏆Register now

🔒 Hello, this is Valentina with a premium issue of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code.

Subscribe now

The mistake is to look at the finished use case — availability check, number generation, persistence, a response — and write all of it in one go.

That’s not TDD.

That’s writing the answer and then sprinkling tests on top.

TDD is incremental: write the simplest behavior that could possibly work, get it green.

The next failing test decides what gets added next.

Behavior 1: a guest can reserve a room

Requirement:

“Guest can reserve a room.”

Notice what’s not in that sentence yet: nothing about availability. So we don’t build availability checking. We build the smallest thing the requirement asks for — a reservation gets added, and we get a reservation number back.

🔴 RED — Write the failing test

class PlaceReservationTest {

    private FakeReservationRepository reservationRepository;
    private StubReservationNumberGenerator reservationNumberGenerator;
    private PlaceReservationUseCase placeReservationUseCase;

    @BeforeEach
    void setUp() {
        reservationRepository = fakeReservationRepository();            // fake — in-memory, query state back
        reservationNumberGenerator = stubReservationNumberGenerator();  // stub — canned number
        placeReservationUseCase = new PlaceReservationUseCase(
            reservationRepository, reservationNumberGenerator);
    }

    @Test
    void createsReservation() {
        reservationNumberGenerator.returns("RES-123");

        var placeReservationRequest = PlaceReservationRequest.builder()
            .guestId("guest-1")
            .roomId("room-101")
            .build();

        var response = placeReservationUseCase.execute(placeReservationRequest);

        assertThat(response.reservationNumber()).isEqualTo("RES-123");

        var reservation = reservationRepository.findByReservationNumber("RES-123");
        assertThat(reservation.guestId()).isEqualTo("guest-1");
        assertThat(reservation.roomId()).isEqualTo("room-101");
    }
}

Notice what exists so far:

• repository to add the reservation

• number generator so the test can pin the returned number (RES-123) deterministically.

There is no AvailabilityGateway — nothing requires one yet.

Look at the request, too: it only has a guest and a room — no dates. A real reservation obviously has dates, but no behavior here uses them yet, so they’re not in the request yet.

The requirement was “reserve a room,” nothing about when. You add data for the same reason you add code: when a test needs it, not before.

🟢 GREEN — Make it pass with the simplest code

public class PlaceReservationUseCase {

    private final ReservationRepository reservationRepository;
    private final ReservationNumberGenerator reservationNumberGenerator;

    public PlaceReservationUseCase(ReservationRepository reservationRepository,
                                   ReservationNumberGenerator reservationNumberGenerator) {
        this.reservationRepository = reservationRepository;
        this.reservationNumberGenerator = reservationNumberGenerator;
    }

    public PlaceReservationResponse execute(PlaceReservationRequest request) {
        var reservationNumber = reservationNumberGenerator.next();

        reservationRepository.add(new Reservation(
            reservationNumber,
            request.guestId(),
            request.roomId()
        ));

        return new PlaceReservationResponse(reservationNumber);
    }
}

Green. It always adds the reservation — it never checks anything — because no test has demanded a check yet.

This feels too simple, and that’s the point. You are not allowed to add the availability logic now. There’s no failing test pushing you there.

🔵 REFACTOR — only if you see the need

With the test green, you now get a safe moment to improve the design — rename, extract, remove duplication — without changing behavior. You take it only if you actually see an improvement worth making; if nothing stands out, you skip it and move on.

Here the use case is a few straight-line statements with nothing to tidy, so there's nothing to do.

Behavior 2: only if the room is available

Now a new requirement arrives:

“A room can only be reserved if it is available for the selected dates.”

Now we need to know if the room is available.

🔴 RED — Write the failing test

    @Test
    void rejectsReservationWhenRoomIsUnavailable() {
        availabilityGateway
            .forRoom("room-101")
            .from("2026-07-10")
            .to("2026-07-12")
            .returnsUnavailable();

        var placeReservationRequest = PlaceReservationRequest.builder()
            .guestId("guest-1")
            .roomId("room-101")
            .from("2026-07-10")
            .to("2026-07-12")
            .build();

        assertThatThrownBy(() -> placeReservationUseCase.execute(placeReservationRequest))
            .hasMessage("Room is not available");
    }

Read more

Subscribe now

Most teams do the opposite.

Pain → delay → bigger merge → more pain.

That is the system.

“We’ll merge when it’s done”

Because:

• merge is painful

• integration is slow

• system breaks in unexpected ways

What teams do next:

❌ integrate less often
❌ delay merging

Wrong.

1. Integrate into main frequently

Not “eventually”. Not “when finished”.

✔ multiple times per day (or at least daily)
✔ small changes only

❌ no “feature branch for 2 weeks”
❌ no “merge at the end of development”

2. Every integration triggers a system check

When code is merged (or proposed for merge), the system must verify:

✔ compilation works
✔ unit tests pass
✔ component tests pass
✔ system tests pass

Not “some tests”.

The goal is:

• do the components work in isolation? AND

• does the system still work as a whole?

Note: quick verification (compilation, unit tests & component tests) is triggered on merge, whereas slower verification (system tests) are triggered on an interval-based schedule.

3. Broken main is not allowed to persist

This is the most important rule in real CI.

✔ if main breaks → fix immediately
✔ nobody continues building on a broken state
✔ the team treats main as always releasable

❌ “we’ll fix it later”
❌ “let’s ignore it and keep going”

4. Changes are small by design

CI only works if changes stay small.

• small commits

• small merges

• easy rollback

Because:

❌ large batches hide integration problems
✔ small batches expose them immediately

5. Integration problems are found immediately, not later

CI is basically: shorten the time between “change” and “system feedback”

So instead of:

❌ change → days later → production breaks

You get:

✔ change → minutes later → system check fails

6. The system is always in a working state

This is the outcome CI is trying to enforce.

✔ main branch always works
✔ every change is either:

• integrated and working

• or not integrated at all

❌ no “half-working shared state”

What CI/CD is NOT (important)

❌ running Jenkins
❌ having a pipeline
❌ building artifacts
❌ running tests once per day
❌ merging occasionally

Those are tools or schedules.

Not CI/CD.

✅ A Real Pipeline = Continuous Delivery

👉 I’m running a live workshop where we walk through a working e-shop example with a pipeline architecture, so you can see how it works in practice.

No rebuild tricks. No “it passed CI but broke anyway” surprises.

Join Pipelines Workshop →

€100 off with code EARLYBIRD100 — limited spots.

Subscribe now

“How to handle errors properly?”

You’ve seen:

• SQLException and DataAccessException caught inside controllers

• catch (Exception e) returning a hand-rolled 500

• giant try/catch blocks wrapping every endpoint

• RuntimeException thrown and swallowed at random

And nobody agrees on the “right” way to do it.

Start where those mistakes happen — the API layer — and get one rule right: a controller turns errors into HTTP responses, and it should never reach for a database or framework exception to do it.

Error Handling at the API layer

This layer should turn errors into HTTP responses.

Examples:

• HTTP status codes

• error messages

• API response bodies

❌ Controllers should NOT handle database/framework errors

@GetMapping("/orders")
public ResponseEntity<?> getOrders() {

    try {
        return ResponseEntity.ok(orderRepository.findAll());
    } catch (DataAccessException e) {
        return ResponseEntity.status(500).body("Database error");
    }
}

That’s the wrong place for database exception handling.

👉 I’m running a live workshop where we walk through a working e-shop example with a pipeline architecture, so you can see how it works in practice.

No rebuild tricks. No “it passed CI but broke anyway” surprises.

Join Pipelines Workshop →

€100 off with code EARLYBIRD100 — limited spots.

✅ The API layer should turn errors into responses — via a global exception handler

Read more

Subscribe now

Most teams I talk to will tell me they have a pipeline.

They have GitHub Actions. Or Jenkins. Or Azure DevOps. The build compiles, the Docker image gets pushed, a deploy script runs, and a green checkmark shows up next to the commit. That’s a pipeline, right?

It isn’t.

What they have is build and deployment automation. The green checkmark only proves the code compiled. Nothing in that verified that the code actually works before the bytes reach a customer.

I know this because the symptom is always the same.

The release went out on Tuesday. By Wednesday morning, the support inbox is full — somebody broke a critical path that nobody tested. Someone stays late. War room reconvenes.

And it ends with the line every senior engineer has heard a hundred times: “the pipeline didn’t catch it.”

The pipeline didn’t catch it because there was no pipeline. There was a conveyor belt.

A Pipeline Has Checkpoints, NOT Steps

Here is the part most teams skip: a pipeline is not a sequence of build steps. It is a sequence of checkpoints.

Because steps just run.

But a real pipeline doesn’t just move code forward. It asks at every checkpoint:
“Does this build move forward?”

If the answer is no, everything stops.

Most “pipelines” don’t do that.

They just run jobs until they’re done and call it success.

“The Pipeline Didn’t Catch It”

Each stage ran. Each stage passed.

But there were no tests.
So the bugs slipped through.

A real pipeline tests the system at each stage:

“Does it work on my machine?”

• Commit Stage — compile, run the fast tests (unit, narrow integration, component, contract), run static analysis, package, publish. Fast. Under five minutes. Triggered on every push.

“Does it work when deployed?”

• Acceptance Stage — deploy it and runs system tests (smoke, acceptance, external system contract, E2E).

“Do we release it?”

• Release Stage — takes it through QA and into production.

Each stage verifies something different. Each stage can stop the pipeline. The Commit Stage’s job is not the Acceptance Stage’s job, and treating them as one big “CI/CD workflow” is how you end up with code that “passed CI” but breaks the moment it gets deployed.

If you compile and deploy but never run the deployed code and check whether the deployed version does what it is supposed to do, you’re skipping the most important point.

You Didn’t Deploy the Same Build You Tested

Now here’s the part that quietly breaks most pipelines — even the ones with good tests.

The Commit Stage produces a build (e.g. a backend image and a frontend bundle). And from that point on, every stage is supposed to run the same build.

No rebuilds. No separate “QA build.” No special “production image.”

Testing the SAME build makes deployments predictable. "Works in Acceptance" means it will work in Production, because it's the same build.

The moment you rebuild between stages — even to swap a config, even to “just bump the version” — the guarantee disappears. The build your tests verified is not what is shipped.

This is the single most common quiet failure mode I see in real pipelines. The team did the work. They wrote the tests. They setup up the stages. And then somewhere in the middle, a “for deployment convenience” rebuild crept in and silently invalidated the whole chain.

Is It a Pipeline or Just Automation?

If you want to know whether your team has a pipeline or just automation, ask three questions:

1. What does the green checkmark prove?

“The code compiled” — this is a build, not a pipeline.

“The code was tested” — this is a pipeline.

❌ Just ran
✅ Verified behavior

2. What runs between commit and production?

If the answer is “compile, package, deploy,” you’re missing the Acceptance Stage. The pipeline cannot tell you whether the version works — only that it built.

❌ Just built
✅ It works

3. Are you running the same build in production that you tested earlier?

If you rebuild between stages, the answer is no. If you cannot tell, the answer is also no.

❌ Different built
✅ Same build

If any of those answers comes back wrong, the green checkmark is lying to you.

A pipeline is not a deploy script.

It is a sequence of checkpoints that decide whether a build should move forward.

If your green checkmark only means “it compiled and got deployed,” then you don’t have a pipeline — you have a conveyor belt that moves broken code faster.

And that’s why release day still feels like a gamble.

👉 I’m running a live workshop where we walk through a working e-shop example with a pipeline architecture, so you can see how it works in practice.

No rebuild tricks. No “it passed CI but broke anyway” surprises.

Join Pipelines Workshop →

€100 off with code EARLYBIRD100 — limited spots.

Subscribe now

“Never allow similar code to exist.”

That’s not DRY.

The original idea behind DRY wasn’t “remove every repeated line.”

It was:

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

— Andrew Hunt and David Thomas (The Pragmatic Programmer)

Knowledge duplication.

Not code duplication.

Want releases to stop feeling stressful and unpredictable?

I’m running a live CI/CD Pipeline Workshop where we build systems that catch issues before production — not after deployment panic.

Reserve My Spot

€100 off with code EARLYBIRD100 — limited spots.

❌ Two identical lines are not always duplication

Developers see this:

public class InvoiceTaxCalculator {

    public BigDecimal calculateTax(BigDecimal subtotal) {
        return subtotal.multiply(new BigDecimal("0.20"));
    }
}

…and then later see this:

public class ImportDutyCalculator {

    public BigDecimal calculateDuty(BigDecimal subtotal) {
        return subtotal.multiply(new BigDecimal("0.20"));
    }
}

The callers would call:

var tax = invoiceTaxCalculator.calculateTax(subtotal);
var duty = importDutyCalculator.calculateDuty(subtotal);

And immediately someone says:

“We should extract this into a shared utility.”

So it gets merged.

So we decide to get rid of the duplication, by extracting duplicated code here:

public class Calculator {
    public BigDecimal calculate(BigDecimal subtotal) {
        return subtotal.multiply(new BigDecimal(”0.20”));
    }
}

We then realize we don’t need neither InvoiceTaxCalculator nor ImportDutyCalculator, so we delete them too.

Then, the callers would call:

var tax = calculator.calculate(subtotal);
var duty = calculator.calculate(subtotal);

But the problem is that Invoice Tax and Import Duty calculations are completely unrelated from the business perspective. They have completely different business rules.

Today, they happen to have the same formula, but that is just incidental.

Tomorrow, they will end up with different business rules:

public class InvoiceTaxCalculator {
    public BigDecimal calculateTax(BigDecimal subtotal, String category) {
        if (category.equals("FOOD")) return subtotal.multiply(new BigDecimal("0.05"));
        if (category.equals("ELECTRONICS")) return subtotal.multiply(new BigDecimal("0.18"));
        return subtotal.multiply(new BigDecimal("0.20"));
    }
}

public class ImportDutyCalculator {
    public BigDecimal calculateDuty(BigDecimal subtotal, String country) {
        if (country.equals("US")) return subtotal.multiply(new BigDecimal("0.25"));
        return subtotal.multiply(new BigDecimal("0.30"));
    }
}

Now the shared abstraction becomes a bug factory.

• flags everywhere

• branching logic explosion

• “generic” calculator that no longer represents a real concept

The duplication was never the code.

The real mistake was coupling two unrelated business concepts because they happened to look similar at one moment in time.

✅ DRY is about knowledge, not code

Read more

Subscribe now

Jenkins does NOT equal continuous integration (CI).

Many teams believe:

“We have Jenkins, therefore, we are practicing CI.”

This is wrong.

Jenkins is just a tool

If a team has Jenkins, but developers work on long-lived branches for days or weeks, then they are not practicing CI.

If merges happen only before release day, they are not practicing CI.

If testing is mostly manual, they are not practicing CI.

If bugs are discovered late, they are not practicing CI.

No TDD = no CI

Without automated tests you CANNOT:

• merge code frequently without fear of breaking things

• ship small, incremental changes

• catch regressions early in the pipeline

• get fast feedback from unit tests

• verify system behavior with acceptance tests

Releases are big, risky, and infrequent.

Do you have CI?

Don’t ask:

“Do we have Jenkins?”

Ask:

• Do we merge into main daily?

• Are we protected by automated tests?

• Do we have Trunk Based Development (TBD) or short-lived branches?

• Can we merge safely multiple times per day?

• Is the main branch always releasable?

If the answer is “no” to most of these, you don’t have CI.

You have a build server.

CI in practice

This workshop is for Senior Engineers & Tech Leads who are:
▪ Stuck with stressful releases
▪ Stay late fixing production deployments
▪ See releases break critical paths that nobody tested

Join the CI/CD workshop →

Limited spots. Register now with the early bird discount - 100 EUR off with code EARLYBIRD100

Subscribe now

You went straight into microservices because… well, everyone else was doing it.

“Scalable.”
“Cloud-native.”
“Future-proof.”
“Independent deployments.”

Suddenly there are:

• 12 services

• 14 repositories

• RabbitMQ

• Kafka

• Kubernetes

…before you even fully understand the domain.

❌ The Distributed Monolith Trap

You are guessing domain boundaries, so microservice boundaries based on your guesses.

The problem is you discover, during the next months, that you’ve modelled the domain in the wrong way. You discover that your microservices are too tightly coupled, and to implement a simple User Story, you have to coordinate changes across multiple microservices. Changes become expensive.

Immediately jumping to microservices — especially the wrong microservices — is expensive to build and expensive to run.

You can call it “microservices”…

…but it’s just a distributed monolith.

⚠️Fear of the Monolith

Some developers hear “monolith” and imagine:

• massive bloated classes

• tangled dependencies

• painful future migrations

But not every monolith has to become a “big ball of mud.”

🚀 Register now: ATDD – Acceptance Testing Workshop
Get 100 EUR off with code DISCOUNT_100

Hexagonal Architecture Inside the Modules

• Modular Monolith → all the modules are deployed as a single artifact

• Microservices → each microservice is deployed independently

Read more

Subscribe now

It’s not because developers hate talking.

Developers can talk for hours — just ask them about architecture.

The 6-person call where 2 people speak

Two people talk the entire time.

The rest are:

• on mute

• pretending to follow

• occasionally saying “yeah” at the wrong moment

The developer translation layer

• “we’ll figure it out” → this is now my problem

• “should be simple” → it absolutely isn’t

• “just a small change” → redesign incoming

• “we can iterate” → nothing is defined

You get asked for estimates on something that is vaguely described.

You give a number.

Everyone writes it down like it’s a fact.

Then later the same number becomes:

“why is this taking longer than expected?”

What developers actually need

Developers don’t need more meetings.

They don’t need longer discussions either.

Not 20 minutes of debate.

Not “we’ll figure it out later.”

Just enough concrete detail so the work isn’t being invented mid-implementation.

A few examples instead of abstract descriptions.

Most of the frustration comes from building something that wasn’t fully defined, and then being judged as if it was.

Vague requests → Concrete examples

This is exactly where acceptance testing and ATDD help.

They take requirements that sound like:

“It should handle refunds properly”

and turn them into concrete examples developers can implement.

Acceptance tests turn that into questions like:

• Given this input, what should happen?

• When this happens, what is the expected output?

• What should not happen?

⚡Ready to see this in action?

I’m running a hands-on ATDD – Acceptance Testing Workshop on May 25–26 (4 hours).

Join the workshop →

Limited spots. Register now - 100 EUR off with code DISCOUNT_100

Subscribe now

I thought bugs came from bad code.

But I noticed that a lot of the bugs we were fixing in QA…
weren’t really coding bugs.

The implementation matched the ticket.
The unit tests passed.
The code review passed.

And somehow, the feature was “wrong behavior.”

Not because the code was broken.

But because people had imagined different things in their mind — usually in the same meeting where everyone thought they agreed.

That mismatch only shows up later.

QA raises issues.

The product owner says: “That’s not what I expected.”

Acceptance Testing Isn’t Really About Testing

Acceptance testing — or ATDD — isn’t just about “more tests.”

It’s about creating shared understanding before implementation starts.

It’s asking questions like:

• What should happen here?

• What does success actually look like?

• Can we describe this with real examples?

• What happens in edge cases?

That’s where a lot of bugs get prevented.

Not during coding.

During alignment.

⛔ Without Acceptance Testing

The developer gets a ticket: “Apply a 10% discount to orders over €100.”

The developer reads the ticket and assumes:

• discount applies before tax

• only for logged-in users

• applies to the entire cart total

QA, later on, tests and assumes:

• discount applies after tax

• also works for guest users

• applies per item, not cart total

The product owner expected:

• discount applies before tax

• only for logged-in users

• based on cart total

Same ticket. Three different interpretations.

And nobody realises until QA finds it — or worse, after release.

✅ With Acceptance Testing

Before coding starts, the team writes examples like:

• Given the customer is logged in, when the customer makes an order of €120, then a 10% discount is applied before tax

• Given the customer is logged in, when the customer makes an order of €80, no discount is applied

• Given a guest user, when the guest makes an order of €150, no discount is applied

Suddenly, there’s no room for interpretation.

Everyone is reacting to the same examples — not their own mental version of the feature.

That’s the shift.

Acceptance testing doesn’t add “more testing.”

It removes guessing before the code is even written.

Why Teams Skip This

Teams want to jump straight into implementation.

Writing code feels productive.

Clarifying expectations sometimes feels like “extra process.”

Until the feature comes back three times for rework.

Then suddenly those early conversations don’t seem so expensive anymore.

See It In Practice

I’m running a live, hands-on workshop where we build acceptance tests. We go from vague requirements → to concrete examples → to executable acceptance tests.

⚡In 4 hours, you’ll:

• Design acceptance tests using DSL + driver architecture

• Apply ATDD Cycle with AI to write an acceptance test and implement the change

• Learn how to introduce acceptance testing in your team

📅 May 25-26, 2:00-4:00 PM CET

Join the workshop →

Limited spots. Register now and get 100 EUR off with code DISCOUNT_100