When people talk about offline-first systems, the conversation usually drifts toward sync engines, merge algorithms, and replication protocols. Those things matter, but they hide the real design question: when two valid changes collide, who decides what the system should do?
In many domains, a conflict is not a technical error. It is a business event. Two people reserve the same inventory. A field worker edits stale data. A user completes a task based on information that changed while they were offline. These are domain situations, and treating them as infrastructure problems usually produces bad software.

In this talk I’ll show how we started modeling offline behavior and conflict handling inside the domain instead of around it. We’ll look at how that changes aggregates, commands, invariants, and even the language teams use when discussing “sync issues.” The result is a system that is easier to reason about because it acknowledges that disconnected work and eventual reconciliation are part of the business reality, not edge cases.