Being Successful with Domain-Driven Design: Minimal Complexity, Part 2
In part one, I talked about the complexity in the language used to communicate the domain. Domain-Driven Design (DDD) deals with that complexity by isolating the concepts in a clear language that domain experts understand. Ubiquitous Language helps form the basis of all the other patterns and practices in Domain-Driven Design through the clear isolation of domain concepts. The DDD pattern language context map provides a good example of isolating concepts (in this case, Domain-Driven Design concepts):
Being Successful With Domain-Driven Design: Minimal Complexity, Part 1
The Domain-Driven Design book (the "Blue Book") includes "Tackling complexity at the heart of software" in the title. While "complexity" can be subjective, the takeaway is that Domain-Driven Design intends to address complex software systems. The principles and practices in Domain-Driven Design have their complexities, so for Domain-Driven Design to add value, it needs to address existing/expected complexity and attempt to be net-positive for simplicity.
-pencil-and-watercolor.png)