💃 Enterprise Apex Rebalanced 🕺

Good morning, Salesforce Nerds!

Apex Enterprise Patterns have achieved something rare in the Salesforce world: they outlived their novelty phase. 🥇 

Years later, they’re still referenced as “the right way” to write Apex. That alone tells us they solved real problems.

But it also creates a trap. Patterns that were once corrective medicine can quietly turn into daily vitamins. 💊 

Taken automatically. Taken forever. Taken even when you’re already healthy.

This article is not a teardown. It’s a calibration. 🎯 

Apex Enterprise Patterns still matter. They still work. But modern Salesforce has changed the terrain. Flow is no longer a sidekick.

Async boundaries are everywhere. Events are common. And scale today often means coordination, not just encapsulation. 🤝 

Let’s talk about what these patterns were meant to fix, what still holds up beautifully, and where restraint has become the more advanced move.

TABLE OF CONTENTS

💃 Enterprise Apex, Rebalanced 🕺

• Why They Existed

• The Core Layers

• Modern Pressure Points

• Flow Changed The Shape

• Patterns With Restraint

PROBLEMS WORTH SOLVING

WHY THEY EXISTED

Apex Enterprise Patterns emerged to solve three very real issues in early enterprise Salesforce orgs.

1️⃣ First, trigger chaos. Business logic scattered across triggers, helpers, and static methods created systems that worked until they didn’t.

2️⃣ Second, tight coupling. Data access, logic, and orchestration were glued together, making change risky and testing painful.

3️⃣ Third, scale anxiety. Teams needed guardrails that made large codebases predictable and survivable.

The patterns introduced structure. Not cleverness. Structure. 👈️ 

They borrowed heavily from classic enterprise design thinking: separation of concerns, explicit layers, dependency inversion, and transaction management.

For Salesforce teams coming from Java or .NET, this felt familiar and grounding.

For Salesforce teams drowning in trigger spaghetti, it felt like oxygen.

That original intent still matters. The mistake is assuming the solution never needs reinterpretation. 🤔 

WHAT STILL HOLDS

THE CORE LAYERS

At their best, Apex Enterprise Patterns create clarity.

Selectors remain one of the strongest ideas in the whole approach. 💪 

Centralizing SOQL is still a win. It prevents query duplication, makes performance tuning easier, and creates a clear contract for how data enters the system. In large orgs, this alone pays for itself.

The Service layer also holds up well. 📈 

Treating business use cases as explicit operations rather than scattered logic keeps intent readable. When written well, services become the story of the system. “Enroll customer.” “Calculate eligibility.” “Provision access.” That narrative value still matters.

The Domain layer is more situational. 🙃 

Encapsulating record-level behavior is powerful when objects truly own rules. Validation logic, lifecycle constraints, and invariants belong close to the data. Where that’s true, Domain logic shines. Where it isn’t, the layer can feel forced.

Unit of Work still makes sense inside a single transaction. 🧠 

Grouping DML, managing order, and avoiding partial commits remains sound thinking. The problem isn’t the idea. It’s assuming that modern Salesforce stays inside one transaction for very long.

WHERE COMPLEXITY CREEPS IN

MODERN PRESSURE POINTS

Patterns don’t usually fail outright. They fail by accumulation. The most common issue at scale is ceremonial layering.

Selectors that wrap a single query. 🚫 

Domains that forward calls without owning rules. 🚫

Services that exist only to call other services. 🚫

The architecture looks disciplined, but cognitive load increases while value plateaus.

👉️ Asynchronous processing adds more strain. Queueables, platform events, scheduled jobs, and retries fracture the assumption of a single transactional boundary.

👉️ Unit of Work still applies locally, but pretending it governs an end-to-end process can be misleading rather than helpful.

👉️ Dependency inversion is another quiet tax.

Salesforce’s testing model already provides strong isolation through test context and data control.

Heavy abstraction purely for mocking often introduces indirection without proportional gains, especially for teams with mixed experience levels.

None of this makes the patterns wrong. It just makes them non-trivial. 💯 

ORCHESTRATION MOVED

FLOW CHANGED THE SHAPE

The biggest architectural shift isn’t Apex itself. It’s Flow.

Flow is no longer “admin automation.” It is orchestration. 🫡 

It spans screens, async paths, branching logic, retries, and user context in ways Apex never naturally did.

Treating Flow as a second-class citizen in a pattern-heavy architecture creates friction instead of leverage. 😰 

In modern orgs, Flow often owns orchestration, while Apex owns execution.

That reshapes responsibilities. Service layers get thinner. Domain logic focuses on invariants rather than process flow. 🔥 

Some logic that once lived in Apex now lives declaratively, where it’s visible, inspectable, and adjustable without deployments (sometimes).

This doesn’t weaken Apex Enterprise Patterns. 🙅 

It reframes them. 🖼️ 

Apex becomes the engine room, not the control tower. The patterns that survive are the ones that respect that boundary.

ARCHITECTURE THAT LASTS

PATTERNS WITH RESTRAINT

Apex Enterprise Patterns are not outdated. They’re seasoned. 🤌 

They shine in orgs with real complexity: multiple teams, long-lived codebases, integration-heavy workflows, and business rules where mistakes are expensive.

They struggle when applied universally, early, or defensively. 😓 

The most mature move is selective application.

Use the layers that earn their keep. Skip the ones that don’t.

Let Flow orchestrate when it’s better suited. Let Apex stay sharp and purposeful. 🏹 

The goal was never perfect architecture. The goal was sustainable systems.

When applied with judgment instead of dogma, Apex Enterprise Patterns still do exactly what they were designed to do. 🎉 

SOUL FOOD

Today’s Principle

and now....Salesforce Memes