For a small internal tool with a single web UI and simple CRUD use cases, a senior engineer proposes skipping a Service Layer and having controllers call the domain/persistence layer directly. When is that a defensible architectural choice, and what do you give up by doing it?

## When none of the benefits apply yet The case for skipping a Service Layer rests on taking its stated benefits seriously enough to notice when none of them apply yet. Fowler introduces Service Layer as solving specific problems: - giving multiple, heterogeneous clients (a web UI, a remote API, a batch job, an admin tool) one consistent entry point per use case; - centralizing transaction and authorization handling above a persistence-ignorant domain model; - and decoupling client code from the domain model's internal structure so the domain model can be refactored without breaking every caller. Each of these benefits only pays for itself once the situation it addresses actually exists. A tool with exactly one client, no remote API, no batch jobs, and simple CRUD use cases with no real business-rule complexity has no duplication to prevent (there's only one caller, so there's nothing to keep in sync), no meaningfully separate 'client vs domain' concern to decouple (the controller already is the only client), and generally no orchestration complex enough to warrant a dedicated coordination point beyond what a repository call already gives you. ## What skipping actually saves Skipping the layer in that situation saves real, measurable cost: - fewer classes and files to navigate, - fewer places to route a debugging session through when tracing 'what does clicking this button actually do,' - less onboarding overhead for new engineers who'd otherwise have to learn an extra architectural convention that isn't earning its keep, - and no risk of the Service Layer itself becoming a thin, pointless **pass-through** — a set of one-line methods that just forward the call to the persistence layer, which is worse than no layer at all because it adds indirection while providing none of the pattern's actual benefits. That last failure mode — a Service Layer that's purely ceremonial, added because 'that's how we structure applications here' rather than because it's solving an actual problem in this application — is common enough in over-templated codebases that it's worth naming as the thing skipping the layer is specifically avoiding. ## The trade-off: future flexibility The trade-off is future flexibility, and the size of that cost depends heavily on how cleanly the domain model and controllers were kept even without a formal Service Layer. If a second client shows up later — say, the internal tool needs a REST API for a partner integration, or a nightly batch job needs to perform the same 'archive record' operation the UI does — introducing a Service Layer at that point is usually a **mechanical extraction**: 1. pull the shared logic out of the controller into a new service method, 2. have the controller call it, 3. wire up the new client to call the same method. This is low-risk specifically because it's a refactor with existing, working behavior as a reference, not new logic being written from scratch under uncertainty. It only becomes expensive if, in the meantime, business logic and transaction handling got scattered and tangled directly into controller code in ad hoc, inconsistent ways across many endpoints, which is a controller-hygiene problem more than a direct consequence of skipping Service Layer per se — a disciplined team can keep controllers thin and business logic in well-organized domain/service classes even without formally naming one layer 'the Service Layer.' ## Two years without one, then a retrofit A concrete real-world example: a company's internal HR admin tool starts as a single Next.js/Spring app used only by three HR staff, with controllers calling repositories directly for simple CRUD on employee records — no Service Layer, because there's exactly one client and no complex business rules. Two years later, the company wants managers to be able to self-serve simple requests (like updating their own team's PTO records) through a separate, more restricted API, and also wants a nightly compliance job to flag records missing required fields. At that point the team introduces a Service Layer, extracting `updateEmployeeRecord` and `flagIncompleteRecords` as proper service methods with their own transaction and authorization handling, refactoring the existing admin UI's controller to call through them instead of the repository directly. Because the underlying domain objects were reasonably well-organized even without a formal Service Layer, this took a few days rather than a rewrite, and the two-year window where the tool ran without one cost effectively nothing beyond that later refactor. ## Where the judgment goes wrong Where this judgment call goes wrong is either direction: - reflexively adding a Service Layer to every project regardless of size, out of habit or 'best practice' cargo-culting, adds ongoing ceremony cost to genuinely simple tools for benefits that never materialize; - but equally, assuming a tool will stay simple forever and letting business logic and ad hoc transaction handling sprawl directly through dozens of controller methods with no plan for what happens when a second client inevitably shows up can turn what should be a cheap later extraction into an expensive untangling project instead. The principal-level judgment isn't 'always add it' or 'never add it upfront,' it's recognizing which of the pattern's specific benefits the project's actual trajectory is likely to need, and how expensive it would be to retrofit later given how disciplined the team is likely to stay without the layer formally forcing that discipline.