The God Class and the Anemic Model

Two patterns dominate the logistics platform’s class design, and they are opposite mistakes.

The God class puts too much in one place. ShipmentService has 3,400 lines, 47 public methods, and 23 dependencies. It handles everything related to shipments. A developer working on rate calculation must navigate past label generation, tracking, billing integration, and notification code. The class resists understanding because it contains too many concepts.

The anemic model puts too little in one place. Shipment is a class with 14 fields, 14 getters, 14 setters, and zero behavior. Every operation on a shipment lives in a service class. To understand how a shipment’s status changes, a developer must search across six service classes for methods that call shipment.setStatus(). The domain object is a data bag. The behavior that gives it meaning is scattered across the codebase.

Both patterns destroy readability. The God class destroys it by concentration: too much to hold in working memory at once. The anemic model destroys it by dispersion: the reader must search across too many files to assemble a complete understanding. The solution is the same for both: objects with focused behavior and clear responsibility boundaries.

This diagram shows the spectrum of class design from anemic model (all data, no behavior) to God class (all behavior, too much data). The readable zone is in the middle: classes with cohesive behavior and the data that behavior needs. On the left, the anemic Shipment class has 14 getters and zero methods. On the right, ShipmentService has 47 methods covering five subdomains. The goal is to move toward the center, where each class has focused behavior operating on the data it owns.