How to Build Reusable Software Abstractions Without Overloading Them

Software abstractions typically emerge to eliminate repetitive code, such as when multiple services share identical CRUD operations like GetAll, Save, and Search. A generic shared interface centralises these common behaviours, making it easy to propagate API changes across all services in one update. Problems arise when developers expand a shared interface to accommodate specialised, service-specific methods, turning a focused contract into a bloated catch-all. A cleaner approach involves composing the base abstraction with service-specific extensions, keeping each service focused while still benefiting from shared logic. The core principle is that a shared abstraction should only contain behaviour genuinely common to all its consumers, not every feature any single consumer might require.