📅 Join me for Acceptance Testing (Live Training) on Wed 25th Feb (17:00 - 19:00 CET) (100% discount for Optivem Journal members)
🔒 Hello, this is Valentina with a premium issue of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code.
Most “Clean Architecture” codebases still revolve around SomethingService.
UserServiceOrderServicePaymentService
And inside those services?
business rules
orchestration
validation
database calls
sometimes HTTP logic too
Everything… everywhere… with multiple use cases all in one file.
Why “Services” Are a Dead End
Services usually start like this:
“We’ll put business logic in services so controllers stay thin.”
And for a while, it works.
But over time:
Services grow without a clear responsibility
Methods multiply
Everything depends on everything
Tests become slow, fragile, and heavily mocked
You don’t know what the system actually does.
Only what data it has.
What a Use Case Actually Is
A use case represents one business functionality.
Not a resource.
Not an entity.
Not a technical operation.
Examples:
RegisterUserPlaceOrderApproveLoanCancelSubscriptionGenerateInvoice
Each use case answers one question:
What does the business want to achieve in this scenario?
Services vs Use Cases
Services (group data):
Organized around entities
Grow horizontally
Use Cases (express behavior)
Organized around behavior
Stay focused
If you have a UserService, ask yourself:
What is the use case here?
Because “user” is not a behavior.