The Service Layer

Reviewed & published by Brayan K

The @Service layer is where business logic lives — separated from the web layer so it is reusable, testable, and the natural home for orchestration and @Transactional boundaries.

Part of the free Java course at LearnCodingFast — hands-on lessons with worked examples and the output they print, plus practice exercises and a quick quiz.

Before You Start

You've built REST controllers and learned request mapping. This lesson shows where the logic those controllers call should actually live.

What You'll Learn

• What the @Service annotation means
• Why @Service is a semantic @Component
• What belongs in the service layer
• Keeping controllers thin via delegation
• Orchestration across multiple services
• Where @Transactional boundaries belong

The Big Idea — The Kitchen Behind the Counter

💡 Analogy: If the controller is the waiter, the @Service is the kitchen. All the real work — combining ingredients, following the recipe, timing the dishes (your business rules and orchestration) — happens in the kitchen, out of sight of the dining room. The same kitchen can serve dine-in, takeaway, or catering (a controller, a CLI, a job) because it doesn't care how the order arrived.

Keeping the cooking out of the dining room is exactly what separation of concerns buys you.

1️⃣ Marking a Service with @Service

@Service is a stereotype of @Component that registers a bean and signals it holds business logic. The logic inside is completely free of HTTP concerns.

// (Conceptual — needs Spring on the classpath to run.)
package com.example.demo;

import org.springframework.stereotype.Service;

@Service                       // a specialised @Component: the business layer
public class PricingService {

    // BUSINESS LOGIC lives here, free of any HTTP concerns.
    public int totalWithTax(int subtotalCents, int taxPercent) {
        if (subtotalCents < 0) throw new IllegalArgumentException("subtotal < 0");
        int tax = subtotalCents * taxPercent / 100;
        return subtotalCents + tax;
    }
}

2️⃣ The Controller Delegates to the Service

The controller injects the service and simply delegates: parse input, call the service, return the result. All the rules stay in one reusable, testable place.

package com.example.demo;

import org.springframework.web.bind.annotation.*;

@RestController
@RequestMapping("/pricing")
public class PricingController {

    private final PricingService pricing;   // inject the SERVICE

    public PricingController(PricingService pricing) {
        this.pricing = pricing;
    }

    // The controller is THIN: parse input, delegate, return a result.
    @GetMapping("/total")
    public int total(@RequestParam int subtotal, @RequestParam int taxPercent) {
        return pricing.totalWithTax(subtotal, taxPercent);   // delegate
    }
}

3️⃣ Orchestration & Transactions

A service can coordinate several collaborators to perform one use case. Wrapping that method in @Transactional makes the multi-step operation atomic — commit on success, roll back on failure.

package com.example.demo;

import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

@Service
public class OrderService {

    private final InventoryService inventory;   // services can use other beans
    private final PricingService pricing;

    public OrderService(InventoryService inventory, PricingService pricing) {
        this.inventory = inventory;
        this.pricing = pricing;
    }

    // ORCHESTRATION: the service coordinates several steps as one operation.
    // @Transactional wraps it so the whole unit of work commits or rolls back.
    @Transactional
    public int placeOrder(String sku, int qty, int unitCents, int taxPercent) {
        inventory.reserve(sku, qty);                       // step 1
        int subtotal = unitCents * qty;                    // step 2
        return pricing.totalWithTax(subtotal, taxPercent); // step 3
    }
}

4️⃣ Reuse Beyond the Web

Because the logic is in a service, the same code is callable from anywhere — here we use it via a controller and directly, with no HTTP involved.

public class Main {
    // Demonstrate separation of concerns with plain Java.
    static class PricingService {                 // would be a @Service bean
        int totalWithTax(int subtotalCents, int taxPercent) {
            if (subtotalCents < 0) throw new IllegalArgumentException("subtotal < 0");
            return subtotalCents + subtotalCents * taxPercent / 100;
        }
    }
    static class PricingController {              // would be a @RestController
        private final PricingService service;
        PricingController(PricingService service) { this.service = service; }
        int handleTotal(int subtotal, int taxPercent) {   // GET /pricing/total
            return service.totalWithTax(subtotal, taxPercent);   // delegate
        }
    }

    public static void main(String[] args) {
        PricingController controller = new PricingController(new PricingService());
        // Same logic is reusable directly (e.g. from a batch job) — no HTTP needed.
        System.out.println("total (web):   " + controller.handleTotal(1000, 20));
        System.out.println("total (reuse): " + new PricingService().totalWithTax(5000, 8));
    }
}

// 🎯 YOUR TURN — replace each ___ using the hint beside it.
import java.util.*;

public class Main {
    record Order(String id, int quantity, boolean paid) {}

    static class OrderRepository {
        private final Map<String, Order> rows = new LinkedHashMap<>();
        void save(Order o) { rows.put(o.id(), o); }
        Optional<Order> find(String id) { return Optional.ofNullable(rows.get(id)); }
    }

    static class InsufficientStock extends RuntimeException {
        InsufficientStock(String m) { super(m); }
    }

    static class OrderService {
        private final OrderRepository repo;
        private int stock;

        OrderService(OrderRepository repo, int stock) {
            this.repo = repo;
            this.stock = stock;
        }

        Order place(String id, int quantity) {
            // 1) The RULE lives here, not in the controller and not in SQL.
            if (quantity > stock) ___ new InsufficientStock("only " + stock + " left");  // 👉 replace ___ with throw
            // 2) Only reached when the rule passed, so nothing half-happens.
            stock ___ quantity;                       // 👉 replace ___ with -=
            Order o = new Order(id, quantity, false);
            // 3) The service asks the repository to store it. It never
            //    writes SQL itself.
            repo.___(o);                              // 👉 replace ___ with save
            return o;
        }

        int stockLeft() { return stock; }
    }

    static class OrderController {
        private final OrderService service;
        OrderController(OrderService service) { this.service = service; }

        String post(String id, int quantity) {
            try {
                Order o = service.place(id, quantity);
                return "201 created " + o.id() + " x" + o.quantity();
            // 4) The controller's whole job: turn an exception into a status.
            } ___ (InsufficientStock e) {             // 👉 replace ___ with catch
                return "___ conflict: " + e.getMessage();  // 👉 replace ___ with 409
            }
        }
    }

    public static void main(String[] args) {
        OrderRepository repo = new OrderRepository();
        OrderService service = new OrderService(repo, 5);
        OrderController controller = new OrderController(service);

        System.out.println(controller.post("A-1", 3));
        System.out.println(controller.post("A-2", 4));
        System.out.println("Stock left: " + service.stockLeft());
        System.out.println("A-1 stored? " + repo.find("A-1").isPresent());
        System.out.println("A-2 stored? " + repo.find("A-2").isPresent());
    }
}

🧠 Quick Recall

Predict before you peek.

Answer: No — it's a specialised @Component. The difference is semantic: it documents the business layer.

Answer: in the service layer — not in controllers (web concerns only).

Answer: on service methods that coordinate a unit of work across repositories.

Common Errors

• ❌ Logic in the controller. Not reusable or easily tested. Fix: move it into a @Service.
• ❌ @Transactional on controllers. Couples transactions to HTTP. Fix: put it on service methods.
• ❌ Anaemic services that just forward calls. Add no value. Fix: let services own real rules/orchestration.
• ❌ Circular service dependencies. A↔B. Fix: extract a third component or rethink boundaries.
• ❌ Web types in the service. e.g. HttpServletRequest. Fix: keep services HTTP-agnostic.

Pro Tips

• 💡 Keep services HTTP-agnostic so they're reusable from jobs and CLIs.
• 💡 Use the right stereotype — @Service for logic, @Repository for data — to express intent.
• 💡 Put @Transactional on the orchestrating method, the true unit of work.
• 💡 Program to interfaces so services are easy to fake in tests.

📋 Quick Reference

📚 Resources / Keep Learning

• 📘 Classpath Scanning & Stereotypes — Spring docs
• 📗 Declarative Transaction Management — Spring docs
• 📗 Managing Transactions — spring.io guide

🎉 Lesson Complete!

You now know what the @Service layer is for, why it's a semantic @Component, why controllers should delegate to it, how services orchestrate other beans, and where @Transactional boundaries belong.

Practice quiz

Continue this course

• Previous: Request Mapping & Parameters
• Next: Repositories & @Repository — The repository pattern and the persistence boundary
• Quick reference: Java cheat sheet

Frequently asked questions

What is the service layer and why does it exist?

The service layer is the part of an application that holds business logic — the rules, calculations, validation and orchestration that define what the application actually does, independent of how it is invoked. It exists to separate concerns. Controllers deal with the web (URLs, HTTP methods, status codes, JSON), repositories deal with persistence, and the service layer sits in the middle expressing the domain's behaviour. By isolating business rules here, you can reuse them from multiple entry points (a REST controller, a scheduled job, a message listener), test them without spinning up the web layer or a database, and reason about them in one place rather than scattered across controllers.

Is @Service any different from @Component?

To the Spring container, @Service is technically just a specialised form of @Component — it is meta-annotated with @Component, so it is detected by component scanning and registered as a bean exactly the same way. The difference is semantic: @Service documents that a class belongs to the business/service layer, making your architecture self-describing. Using the specific stereotypes (@Service for logic, @Repository for data access, @Controller/@RestController for web) communicates intent to other developers and to tooling. There is also a minor behavioural nuance for @Repository (persistence-exception translation), but for @Service the value is primarily clarity of role.

Why should controllers delegate to services instead of containing logic?

A controller's responsibility is purely web translation: bind the request, call something, and shape the response. If you put business logic directly in controller methods, that logic becomes tied to HTTP and impossible to reuse elsewhere or test without the web layer. Delegating to an injected @Service keeps controllers thin and the logic centralised. The same service method can then be called by another controller, a CLI command, or a background job, and unit tests can exercise it by constructing the service with fake dependencies — no MockMvc or running server required. This is the practical payoff of separation of concerns.

Where do transactions belong in this layering?

Transaction boundaries belong on the service layer, typically via @Transactional on a service method. A single business operation often spans several repository calls — reserve inventory, create an order, record a payment — and you want them to succeed or fail as one atomic unit. Placing @Transactional on the service method that orchestrates those steps makes the whole method a transaction: if any step throws, Spring rolls everything back. Putting transactions on controllers is discouraged because the transaction would then be coupled to the web request rather than to the business operation, and read/serialisation concerns can leak into the transactional scope.

Can a service depend on other services?

Yes, and it is common. A higher-level service often orchestrates several lower-level ones — for example an OrderService that uses an InventoryService and a PricingService to fulfil a single use case. You inject those collaborators through the constructor just like any other bean. The key discipline is to avoid circular dependencies (A needs B and B needs A), which signal that responsibilities are tangled and usually call for extracting a third component or rethinking the boundaries. Programming to interfaces here also helps: a service depending on an interface can be tested with a fake collaborator and lets you swap implementations freely.

Related lessons

• REST controllers