Freeze the domain.
Everything else stays liquid.

Most LLM agents working on production code have no central ground truth. They infer the domain from filenames, recent commits, and Stack Overflow patterns. Result: hallucinated context, semantic drift, broken contracts.

Each AI-assisted commit silently shifts what Order or Position means in the codebase. Six months later, the agent is generating code that compiles, passes tests, and slowly corrupts the model. Onboarding new humans takes longer than before AI.

Business logic doesn't live in domain entities — it lives in transactional service classes that grow forever. Every new requirement adds another method to OrderService, another null check, another orchestration step.

The cost: nobody can read the business model from the code anymore. New developers can't reason about what the system actually does. Every change ripples through unpredictable surfaces. Test coverage looks healthy and yet production keeps surprising you.

AI agents accelerate implementation but degrade the model. They generate code that compiles, passes tests, and slowly turns the domain into a bag of utilities — because the agent has no opinion about what belongs where.

The cost: velocity now, opaque codebase six months later. The domain stops being legible. Onboarding takes longer than before AI. The team starts to distrust merged code.

The team wants to modernize. The estimate keeps coming back the same: "we'd have to rewrite the whole thing." Reasonable — because business logic is fused with framework code, transport, and persistence. You can't move one without moving all.

The cost: cloud migrations that change deployment but not architecture. Year-long projects that ship the same monolith on Kubernetes. Sunk costs that grow with every quarter.

The team split a monolith into microservices, but kept shared databases, synchronous calls, and entity-level coupling. Result: more services, same coupling, more failure modes. Deploys still need orchestration. A bug in service A still rolls back service B. Latency got worse.

The cost: all the operational tax of microservices, none of the autonomy. Teams end up afraid of their own architecture.

Most "DDD codebases" I've inherited had folders named domain, application, infrastructure — and inside domain, anemic POJOs with getters, setters and Spring annotations.

I do it differently. Interfaces in the tree, classes at the edges. The domain is a tree of pure Java interfaces — no annotations, no frameworks, no transport concerns. Each leaf has exactly one implementation in exactly one infrastructure module.

The domain at the center. Ports are interfaces it declares — "I need to load an Asset by ID", "I need to emit an EligibilityDecided event". Adapters are implementations: Cosmos DB, Event Hubs, REST, gRPC, file system.

The practical payoff: decommissioning-safe leaf swaps. Retire a 10-year-old service without rewriting consumers.

An event is something that happened in the business. OrderPlaced. AssetMarkedIneligible. PaymentSettled. Immutable, named in the language the business uses.

The transport — Azure Event Hubs, Kafka, RabbitMQ — is an adapter. Manual checkpointing, optimistic concurrency, idempotent handlers, retry with backoff via Resilience4j. These are operational concerns; the event itself doesn't know any of this.

I work with AI agents daily. I treat them like a fast junior who needs structure: clear domain boundaries, explicit interfaces, recipes for common moves. Give them those, and they accelerate everything. Skip them, and they generate plausible code that quietly corrupts the model.

Domain‑First is what makes AI work safely. When every plane of the system — Terraform structures, interface compositions, microservice orchestration, even the way a single network connection is opened — explicitly expresses the domain it sits in, the agent can't drift. There's nowhere to drift to. The model is the map.

Even the "technical" code is a domain. If the work is conversion, the domain is conversion — and around it sits a small cluster of value objects, validators, mappers that encapsulate logic and responsibility. That's the antidote to service-first: business logic doesn't pile up in one fat orchestrator, because every concern has its own little domain.

The same encapsulation discipline scales. Each layer hides its internals and exposes only what the layer above actually consumes. Refactor inside any layer without breaking its consumers.

Design direction: Domain → Relationships → Needs → API. Understand the domain at the given layer. Map its relationships. From relationships, derive what is needed. Only then define the minimal API surface. Never the reverse.

The European PSD2 directive forced banks to expose public APIs. Our platform provided security, monitoring, load balancing and scalability for banks and payment providers like PayU and PayPal.

I was the architect — technology decisions, technical support during sales meetings, product presentations to the business. A short engagement, but a foundational one for understanding what "domain" actually means when the regulator is in the room.

Looking back: if I had then the awareness I have now, I would have designed the infrastructure and the service split very differently. With a properly maintained domain, the value compounds at every boundary — defining microservice responsibilities, locating business-critical atomic operations, choosing the right unit of scaling. Each layer is itself a domain: a Java method, a microservice call, a K8s pod inside a cluster, inside a VM, inside a cloud subscription at a financial provider, funded from a project in a department in a company operating in a regulated domain area.

A platform for asset ratings management at one of the world's largest asset managers. I joined as a senior engineer with one explicit mandate: promote DDD inside a working monolith.

The challenge was political as much as technical. Anemic JPA entities. Stored-procedure logic. Service classes that grew unbounded. Every refactor proposal had to make sense to a team that had shipped the system to production for years. This is where the method earned its political muscles — knowing when to refactor in place, when to extract, when to leave well enough alone.

Personally, RTM was also where exposure to reactive programming became a breakthrough moment in my understanding of DDD and encapsulation. Streams, backpressure, and the discipline of treating data flow as a first-class concern revealed how shallow my prior model was. Aggregates aren't just state — they're behavior, time and flow. That shift later became the foundation for the reactive pipeline in Ethereum Analyzer.

A blockchain analyzer where the pure domain module defines only behavioral interfaces — every infrastructure module implements them independently, with its own technology concerns. Strict downward-only dependencies. The domain doesn't know about Neo4j, Web3j or REST.

This is where the technique was honed in isolation, without legacy constraints or political negotiation. A laboratory for the interface-first idea that later got applied at production scale in ACES.

A platform coordinating asset eligibility decisions across multiple business domains using event-driven microservices on Azure. Distributed state, strict auditability, multiple counterparties.

ACES is where I first adapted Domain‑First thinking to the modeling of service domains — not just inside a class hierarchy, but across event flows, store abstractions and workflow orchestration that cross several bounded contexts. The laboratory ideas from Ethereum Analyzer, applied at production scale inside an investment bank. Domain‑First stopped being a personal preference and started being a load-bearing element of someone else's revenue.

A single-node Proxmox homelab managed end-to-end with Terragrunt and Terraform, structured in three IaC layers — but the headline is not the tech stack. The headline is that the-world is a complete instantiation of Domain‑First thinking at every layer of the stack: code, model, MCP, infrastructure, observability, deployment.

The methodology and its scaffolding evolve together. As Domain‑First Rules matures, the-world refactors to match. As the-world reveals new edge cases, Domain‑First Rules grows new chapters. Each is the proof of the other.

Domain-First Solution Architect, based in Cracow. 15+ years of commercial work shipping production systems, most of it in financial services: investment banking on UBS ACES, wealth management on the Capital Group RTM platform, digital identity on HSBC DIVA, credit verification at Crif, and payment APIs on the PolishAPI / PSD2 platform at Intive. Domains where being wrong has consequences.

The constant across every project: the systems where the domain stayed visible kept paying off. The ones where business logic scattered into a service layer rotted. That's the thesis behind Codefreeze.

Each engagement taught me a different angle of the same problem: how to keep the business model legible in code, even when the team turns over and the technology underneath shifts.

Domain‑First is not specific to a tech stack or a vertical. The discriminator is whether your context has enough coupling — between systems, regulations, market structure, organisational boundaries — that getting the model right is the leverage point.

The patterns below are recurring signals that it is.

The same discipline that pays off in complex domains adds friction to simple ones. If the surrounding context is shallow, ephemeral, or already understood by everyone involved, the upfront mapping work costs more than it returns.

Better to recognise that early than to discover it after three months.

I take one or two engagements at a time, so before anything paid we both check that Domain‑First is actually your leverage point. Fifteen to twenty minutes, no pitch.

You answer a few short questions first; they tell me whether your domain has the kind of coupling where getting the model right pays off. If it does, we talk; if it does not, you still leave with an honest read.

The shortest entry. Before committing to an Architecture Review, some teams need to validate whether Domain‑First is the leverage point at all. The Sprint is built for exactly that decision.

The output is a written brief — short enough to read in one sitting, concrete enough to act on. Even a "domain modeling is not where your leverage is" verdict leaves you with mapped assumptions and a clearer picture of where it is.

I read the codebase, the domain, and the team's working reality. The deliverable is a written report — so the analysis survives the meeting and gets re-read months later.

Low commitment for both sides. If we go no further, you still walk away with a ranked, costed, reversible path you can hand to anyone.

Scope and duration are agreed after the Architecture Review — never blind. The work proceeds leaf-by-leaf, so every change is reversible and reviewable, and you steer it at every gate.

Domain interfaces become the agent's read-only contract; aggregates own their invariants; service classes shrink to thin orchestration over rich domain models.