God objects and anemic models

Software design often swings between two dangerous anti-pattern extremes:

1. The God Object (The Blob): One gigantic class that knows too much and does too much.
2. The Anemic Domain Model: The opposite extreme—entities that are empty data structures with getters and setters, while procedural "Manager" or "Service" classes manipulate their raw internals.

Both destroy the primary advantages of object-oriented design: cohesion, encapsulation, and maintainability.

The problem

Anti-Pattern 1: The God Object

1 // God Object: 3,000 lines touching everything
2 class AppManager {
3   renderUI() {}
4   calculateTax() {}
5   sendEmail() {}
6   connectToPostgres() {}
7   processRefund() {}
8 }

Anti-Pattern 2: The Anemic Model

1 // Anemic entity: zero logic, zero validation, public mutation
2 class BankAccount {
3   balance = 0; // Anybody can set this to -999999!
4 }
5 
6 // Procedural service does all the work, breaking encapsulation:
7 class BankService {
8   withdraw(account, amount) {
9     if (account.balance >= amount) {
10       account.balance -= amount; 

The pattern: Rich Domain Model

A Rich Domain Model puts business logic right next to the data it operates on. Entities protect their own invariants. External services coordinate operations, but never bypass the entity's encapsulated rules.

In code

When to use it, and when not to

Use Rich Domain Models when:

• Your application has non-trivial business rules, invariants, and multi-step domain workflows.
• You want to eliminate duplicate validation rules scattered across UI, controllers, and services.

Don't use Rich Domain Models when:

• The system is purely data transformation or passthrough ETL with zero business rules.
• Performing bulk batch insertions into analytical data warehouses.

Where you have already seen it

In Domain-Driven Design (DDD), Martin Fowler coined "Anemic Domain Model" to warn against stripping entities of behavior. Frameworks like EventStore and modern DDD aggregates model entities with rich methods (order.cancel(), order.applyDiscount()).

Related patterns

• Rich Domain Model vs Repository: Repositories persist rich domain aggregates; they do not contain business rules.
• God Object vs Facade: A Facade delegates to focused subsystem classes without holding logic itself. A God Object hoards all state and execution logic.