Why organizing code by “what it does” makes more sense than by “what it is”
“Wait... why is the controller in one folder, the service in another, and the real logic buried somewhere else?”
That question hit me again during a code review this week.
The feature was simple: process a checkout.
But understanding it required jumping between:
/Controllers/CheckoutController.cs
/Services/ProcessPaymentService.cs
/Repositories/OrderRepository.cs
/Utils/Mapper.cs
The structure was clean — technically.
But the story was lost.
The problem with layer-based organization
Most projects are organized by type, not intent.
It sounds good on paper. "Let's group all controllers, services, and repos."
But in practice?
You chase logic across folders
You lose business context
You forget what the feature was supposed to do
You make simple changes feel complex
This disconnect hurts onboarding, debugging, testing, and momentum.
The idea behind POCP
The Purpose-Oriented Code Principle (POCP) is simple:
Group code by what it’s for, not what it is.
Instead of this:
/Controllers
CheckoutController.cs
ProductController.cs
/Services
PaymentService.cs
InventoryService.cs
/Repositories
OrderRepository.cs
StockRepository.cs
You get this:
/Checkout
CheckoutController.cs
PaymentService.cs
OrderRepository.cs
/Inventory
StockRepository.cs
InventoryService.cs
Everything related to a feature — in one place.
Why this matters
We don’t write code for layers.
We write it to solve problems.
So why are we forcing devs to mentally reconstruct the business logic from pieces scattered across folders?
POCP brings back cohesion.
It gives your project:
- Narrative
- Focus
- Speed
- Confidence
You change features where they live — not across 5 files in 5 folders.
POCP + SOLID = ❤️
POCP doesn’t replace SOLID.
It amplifies it.
- SRP gives you focused classes
- DIP lets you inject dependencies
- OCP allows safe extensions
- And POCP makes all of that easier to understand and evolve
Bonus: It helps with scaling teams
In fast-growing teams, context is everything.
When your code is organized by purpose:
- A new dev can onboard into the Payments module without learning the whole app
- A bug in Notifications won’t touch Checkout
- Features can be split into modules or microservices more naturally
It’s not just about structure — it’s about mental model.
Final thought
“We spend more time reading code than writing it.
Let’s make it easier to read — by making it make sense.”
The POCP is a small shift in mindset that can lead to huge gains in clarity, autonomy, and delivery speed.
I believe this is a principle we should talk more about.
Top comments (1)
I really like your idea of using POCP (Purpose-Oriented Code Principle).
I think many of us don’t realize its importance because we often just follow the default setup, file structure, and generators that frameworks provide.
I’d love to see examples of how it’s used in real projects.