🧹 Your Spring Service Does Not Need That Interface

UserService. UserServiceImpl. One interface, one implementation, and there will only ever be one. Open any Spring codebase and you will find dozens of these pairs. Nobody on the team remembers deciding to do it this way. It is just how services are written.

Here is the part most people never learned: the reason this pattern exists stopped being true around Spring Boot 2.0.

Why the interface used to be mandatory

Go back to early Spring and EJB. When you put @Transactional on a bean, Spring did not run your method directly. It wrapped your bean in a proxy, and the proxy opened the transaction, called your method, then committed or rolled back.

The default proxy mechanism was the JDK dynamic proxy. And JDK dynamic proxies have one hard rule: they can only proxy interfaces. The proxy is a synthetic class that implements your interface and delegates to the real object. No interface, no proxy.

So if you wanted @Transactional, @Async, @Cacheable, or any other AOP-driven annotation on a service, you needed that service to implement an interface. It was not a design decision about abstraction or testability. It was a mechanical requirement of the framework. The Impl class was the price of admission.

That is where the muscle memory came from. A whole generation of Spring developers learned "services have interfaces" as a rule, without the context that it was a workaround for a proxy limitation.

The constraint is gone

Spring Boot flipped the default to CGLIB proxies. Since Boot 2.0, proxyTargetClass is true out of the box. CGLIB does not implement an interface, it generates a runtime subclass of your concrete class and overrides each method to add the advice.

That means @Transactional works perfectly on a plain class:

@Service
public class UserService {

    private final UserRepository userRepository;

    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    @Transactional(readOnly = true)
    public User findById(Long id) {
        return userRepository.findById(id)
            .orElseThrow(() -> new UserNotFoundException(id));
    }

    @Transactional
    public User create(CreateUserRequest request) {
        return userRepository.save(User.from(request));
    }
}

No interface. CGLIB subclasses UserService at startup, the transactional advice still runs, and everything behaves exactly as it did with the interface in place. The framework reason for the interface evaporated, but the habit did not.

Compare that to what the "proper" version used to look like:

public interface UserService {
    User findById(Long id);
    User create(CreateUserRequest request);
}

@Service
public class UserServiceImpl implements UserService {

    private final UserRepository userRepository;

    public UserServiceImpl(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    @Override
    @Transactional(readOnly = true)
    public User findById(Long id) {
        return userRepository.findById(id)
            .orElseThrow(() -> new UserNotFoundException(id));
    }

    @Override
    @Transactional
    public User create(CreateUserRequest request) {
        return userRepository.save(User.from(request));
    }
}

Twice the files. The method signatures written out twice. An @Override on everything. And not a single new behavior to show for it.

"But I need the interface to mock it"

This is the second defense, and it is just as dead as the first.

Mockito has mocked concrete classes for years. It generates a subclass at runtime, the same trick CGLIB uses. You do not need an interface to write a test double:

@ExtendWith(MockitoExtension.class)
class OrderServiceTest {

    @Mock
    UserService userService; // concrete class, mocked fine

    @InjectMocks
    OrderService orderService;

    @Test
    void rejects_order_for_missing_user() {
        when(userService.findById(42L))
            .thenThrow(new UserNotFoundException(42L));

        assertThrows(OrderRejectedException.class,
            () -> orderService.place(42L, cart));
    }
}

The same goes for @MockBean in a slice test. Spring replaces the bean with a mock whether the type is an interface or a class. "Interface for testability" describes a world that ended a long time ago.

The Impl suffix is the tell

When the only way to name your implementation is to staple Impl onto the interface name, that is the code telling you the interface is not doing anything. A good abstraction has a name that means something on its own. PaymentProvider and StripePaymentProvider. Cache and RedisCache. The interface describes a role, the implementation describes one concrete way to fill it.

UserService and UserServiceImpl describe the same thing twice. It is one concept wearing two files. And you pay for the split constantly: every "go to definition" lands on the interface, and you click through to the impl to see what the code actually does. Multiply that by every service, every navigation, every new hire trying to read the codebase.

The honest trade-off

This is not "interfaces are bad." That would be a dumb position. Interfaces are one of the most useful tools in the language, and there are clear places where a service interface earns every line:

• Genuinely multiple implementations. A PaymentProvider with Stripe and PayPal behind it. A NotificationChannel for email, SMS, and push. The interface is the abstraction over real variants, and a strategy pattern needs it.
• A module or published-API boundary. When other modules or services consume your type, the interface is the contract. You expose the interface and hide the implementation so you can change internals without breaking callers.
• Ports and adapters / hexagonal. The port is an interface on purpose. It keeps your domain code from depending on infrastructure. The UserRepository interface in your domain, implemented by a JPA adapter in your infrastructure layer, is exactly right.

The distinction is the number of implementations and the existence of a real seam, not the layer the class happens to live in. A service interface at an architectural boundary is doing work. A service interface wrapped around a single CRUD bean in the same package is ceremony.

There is also an asymmetry that settles the default. Extracting an interface later, when a second implementation actually arrives, is a 10-second IDE refactor: right-click, "Extract Interface," done. Carrying a dead interface on every service from day one is a cost you pay forever, on every file and every navigation. Cheap to add when you need it, expensive to maintain when you do not. That asymmetry says: default to the concrete class.

The rule

Start with the concrete class. Put @Transactional right on it. Let CGLIB do its job. The moment you have a second implementation or a real cross-module boundary, extract the interface then, and give it a name that means something. Do not predict the second implementation. In most services it never comes.

What looked like clean architecture was mostly inertia from a constraint that expired eight years ago.

---

Do you still write an interface for every service, or did you drop the habit? If you kept it, what is the rule that makes it worth the second file for you? Real-world approaches beat theory here.