标签：#refactorit

Most Laravel applications do not become difficult to maintain because somebody made one obviously terrible architectural decision. They get there through dozens of small decisions that looked completely reasonable at the time. A controller grows beyond a comfortable size, so part of its logic moves into an Eloquent model. Later, the application needs to send a notification after an order ships. Then inventory must be checked through an external API. Accounting requests an ERP integration, and marketing wants loyalty points awarded after dispatch. Each change adds only a few lines. Since the Order model is already available wherever the feature is being implemented, adding one more method feels natural: $order -> ship (); It is concise, expressive, and pleasantly object-oriented. Six months later, however, that innocent method may be updating several tables, calling two APIs, dispatching events, sending notifications, and deciding whether the entire operation is allowed. The model has quietly become the place where the application runs its business workflows. That is the real problem. It is not that the model is “fat.” It is that persistence, domain decisions, and application orchestration have been mixed together until nobody can change one without understanding all three. Business Logic in Eloquent Models Is Not Automatically Wrong The common advice to remove all business logic from Laravel models goes too far. Eloquent follows the Active Record pattern. Martin Fowler describes Active Record as an object that represents a database row, encapsulates database access, and adds domain logic related to that data. In other words, an object containing both state and behavior is not an architectural mistake by itself. A model should be allowed to answer questions about itself: class Order extends Model { protected function casts (): array { return [ 'paid_at' => 'datetime' , 'expires_at' => 'datetime' , ]; } public function isPaid (): bool { return $this -> paid_at !== nul