Class and type naming conventions that make architecture clear

Classes are nouns — they represent things. A class named UserManager or DataHelper tells you nothing about what it actually manages or helps with. These vague suffixes are a red flag that the class hasn't been properly designed.

// Bad — what does Manager manage?
class UserManager { }
class DataHelper { }
class Processor { }

// Good — name reflects the actual responsibility
class UserAccountRepository { }
class EmailNotificationService { }
class OrderSummaryBuilder { }

Naming patterns by responsibility:

Entity/Model — represents a real-world concept: User, Order, Invoice.

Service — encapsulates business logic: PaymentProcessingService, AuthenticationService.

Repository — handles data access: UserRepository, ProductRepository.

Builder/Factory — constructs complex objects: QueryBuilder, ReportFactory.

// Each name tells you exactly what layer this belongs to
class InvoiceRepository {   // data layer
  findById(id) { }
  save(invoice) { }
}

class InvoiceService {      // business layer
  generateMonthlyInvoice(userId) { }
}

Use your domain's own language. If your business calls them "Enrollments," don't name the class CourseRegistration because it sounds more technical. Align code names with the terms stakeholders use — it eliminates a constant translation layer between business conversations and code.

Interfaces should describe capability: Serializable, Comparable, Printable. Abstract classes describe what something is: AbstractNotifier, BaseController.