Tech — Work — Ramblings

by Mike Kalvas

202606170951 Bounded Context

In 202511120846 Domain Driven Design, we model our business as a group of bounded contexts. Each context represents real-world concepts, teams, and a 202511151211 Ubiquitous language.1 In particular, bounded contexts help us recognize and address the fact that two teams in a company may have a very different idea of (for example) what a "Product" is.2

Bounded contexts should strive to be independent and complete unto themselves. This does not mean that they don't have boundaries and interactions though. Often there are seams that seem superfluous to a naïve engineer. "Why do I need to convert between an AccountingProduct and a SalesProduct and back again?" These contexts pay themselves back in spades if we maintain their independence and evolvability (202605281610 Building Evolutionary Architectures).


  1. Evans, E. (2003). Domain-driven design: Tackling complexity in the heart of software. Addison-Wesley. ↩

  2. Fowler, M. (2014, January 15). Bounded Context. Martinfowler.Com. https://martinfowler.com/bliki/BoundedContext.html ↩