The techniques used to distribute software, scale it through concurrency or make it tolerant of latency are hobbled when, deep inside, the business logic is based on inappropriate assumptions of consistency. Yet it is common to do domain modeling and design business features heedless of these issues, and then patch things up after the fact with technical tricks. In DDD, we consider the the CAP tradeoffs to be central concerns of the design, and we incorporate into our domain models explicit assertions about the boundaries of consistency. When deployment reveals that additional or different CAP tradeoffs must be made, we go back to the root of the problem and modify the  domain model to reflect those tradeoffs explicitly. In this talk, I’ll discuss three DDD patterns that help us address CAP tradeoffs: Aggregates, Domain Events and Bounded Contexts. 

I will not be able to explain these patterns in depth, but I hope to give a sense of the nature of these conceptual tools and where they come into play in designing practical systems constrained by CAP.