OOP Is About Treating Business Concepts Like Pets

I once joked that Object-Oriented Programming is really about treating business concepts like pets. It got a laugh, which was the point. But the more I thought about it, the more it stopped being funny and started being uncomfortably true.

Not in a «Gang of Four» design pattern way. In the way you understand ownership when you’ve watched systems break for decades.

Own It Like You Mean It

If you’ve had a pet, you know the drill. You name it. You know its boundaries. You know what it never does. You don’t let random strangers grab it by the scruff. And when something’s wrong, you know before anyone else does.

That’s what OOP tried to give us. Not inheritance hierarchies, not UML diagrams, not abstract factories with heroic names. Ownership.

Data Bags Are Not Objects

Somewhere we lost the plot. We call things «objects» that are just structs with attitude. DTOs. ORM output wrapped in a class. You see it everywhere:

PHP

$customer->status = 'suspended';
$customer->credit_limit = 0;
$customer->vip = false;

Nothing stops you. Nothing explains why. Nothing enforces rules. Anyone walks in and flips switches. That’s not an object. That’s a spreadsheet cell with delusions.

A real object looks boring but behaves like it means it:

PHP

$customer->suspend($reason);

Better because the Customer owns its behavior. You don’t mutate it. You ask it to do something. That’s the pet relationship. You’re responsible for its well-being, which means protecting its insides from the chaos outside.

DDD Is Damage Control

Domain-Driven Design didn’t appear because architects love layers. It appeared because we kept breaking systems by letting anyone touch anything.

DDD says one thing: Business rules live with the business concept.

Not in controllers. Not in random services. Not scattered across «helper» classes. Not duct-taped into a WordPress hook or filter as an afterthought. If a rule exists because the business exists, it belongs with the object that represents it. This isn’t dogma. It’s damage control.

The Old Tools Got It

Back in the VB, VB.NET, FoxPro days, this wasn’t philosophy. A button clicked, a form reacted, a private sub handled logic. If something was Private, it was private. End of story.

We didn’t argue about architecture. We shipped software people used every day. Those systems often felt more «object-oriented» than modern code because ownership was obvious.

Today we have «domain models» with no behavior. Services that do everything. Objects passed around like party favors. We call it OOP because the files end in .php or .ts, but there’s no ownership. When no one owns an object, it gets fragile. When everyone can mutate it, it gets dangerous.

Care, Not Elegance

DDD feels heavy when you fight it. It feels natural when you realize it’s just enforcing what you already believe: Don’t let random code mess with business state. Make invalid states unrepresentable by default.

Here’s the thing: If nobody feels responsible for an object, it’s not an object—it’s a liability.

Good OOP and good DDD aren’t about elegance. They’re about care. You don’t throw your pets around. You don’t expose their insides. You don’t let strangers decide how they behave. That’s not ideology. That’s how systems survive.