If Your Business Logic Knows AWS Exists, It Isn’t Business Log

Open up your payment service codebase right now and check the imports. What do you see?

Odds are, your core domain knows intimately that it lives in AWS. It knows that the request arrived over HTTP, that sessions reside in Redis, and that transaction records settle into Postgres. It knows the exact merchant gateway SDK it talks to, and it knows Kafka is waiting to broadcast the result.

PaymentService → AWS + HTTP + Postgres + Kafka + Redis

At first glance, this feels harmless. We tell ourselves, "Of course it knows these things—the code has to actually run somewhere." We build fast, wire frameworks directly into domain classes, and celebrate shipping the feature on time.

If the sole responsibility of your service is to decide whether money can legally and safely transfer from Account A to Account B—why does that decision care about the names of AWS, Kafka, or Postgres?

None of those tools change the fundamental mathematics of moving money. Yet when our business rules become entangled with infrastructure, our systems succumb to what I call Architectural Dementia: the domain forgets what it actually exists to do, mistaking its tools for its identity.

In our previous discussion, we established that separating code into microservices doesn't make services independent if their minds remain coupled to the outside world. To fix that, we must create a genuine border between thought and execution.

The Rule of Anonymity

To achieve what we call Absolute Domain Isolation, we don't start with complex enterprise patterns. We start with a radically simple contract: The core business logic should never know who it is speaking to, how the message arrived, or where the data will sleep tonight.

Think of your core business logic like an air-gapped sovereign country. It speaks only its own pure language, enforces its own laws, and issues commands through strict diplomatic borders.

Inbound: Driving Ports

The domain doesn't know about REST, GraphQL, or gRPC. It only exposes an intent: ExecuteTransfer(command). The transport layer adapts to the domain—never the reverse.

Outbound: Driven Ports

The domain doesn't talk to Postgres or Kafka. It defines pure interfaces: LedgerRepository and EventPublisher. Concrete infrastructure is injected at runtime.

The Litmus Test: Running Offline

Want to test if your domain actually achieved isolation? Disconnect your Wi-Fi, tear down your Docker containers, and kill your database daemon.

Can you spin up an in-memory test suite that executes your most intricate business rules in milliseconds? If the answer is no, your business rules do not own their behavior—your database or your framework does.

The Golden Inversion: Infrastructure should depend on business logic. Business logic should depend on nothing.

What This Buys You

Teams often assume Hexagonal Architecture or Domain Isolation is academic over-engineering. In reality, it protects your velocity when reality shifts:

• Zero-Fear Migrations: Swapping from DynamoDB to Postgres or migrating event brokers becomes an edge-adapter replacement, not a domain rewrite.
• Sub-Second Test Feedback: Pure unit tests run in memory without spinning up heavy mocks or database containers.
• Longevity: Frameworks and cloud vendors go obsolete every five to seven years; clear financial and operational rules outlive them all.

In the next dispatch, we’ll take a raw, coupled payment service and refactor it step-by-step: extracting ports, crafting isolated domain primitives, and wiring up swappable adapters without leaking a single dependency.