chapter three

3 Core concepts of Domain-Driven Design

 

This chapter covers:

  • Parts of Domain-Driven Design (DDD) most important for security
  • Models as strict simplifications of the domain
  • Value objects, entities, and aggregates
  • Domain models as ubiquitous language
  • Bounded contexts and semantic boundaries

During the years that we’ve been developing software, we’ve found inspiration from many sources—some different, some shared. One of the biggest sources of inspiration we have in common is Domain-Driven Design, often abbreviated as DDD.

DDD sets the bar a little higher in regards to most system development. We’ve seen a lot of system development where the attitude "just make it work" has been the guiding principle. When a bug was found, the solution has been to just add an if-clause. Although seldom a local programming mistake, the problem was poorly understood, and the solution was build on a model which was incomplete or inconsistent.

 

Domain-Driven Design is an approach to the development of complex software in which we: 1. Focus on the core domain. 2. Explore models in a creative collaboration of domain practitioners and software practitioners. 3. Speak a ubiquitous language within an explicitly bounded context.

  
  -- Eric Evans _Domain-Driven Design Reference_ (Domain Language

3.1  Models as tools for deeper insight

3.1.1  Models are simplifications

3.1.2  Models are strict

3.1.3  Models capture deep understanding

3.1.4  Making a model means choosing one

3.1.5  The model forms the ubiquitous language

3.2  Building blocks for your model

3.2.1  Entities

3.2.2  Value objects

3.2.3  Aggregates

3.3  Bounded contexts

3.3.1  Semantics of the ubiquitous language

3.3.2  The relationship between language, model, and bounded context

3.3.3  Identifying the bounded context

3.4  Interactions between contexts

3.4.1  Sharing a model in two contexts

3.4.2  Drawing a context map