3 Core concepts of Domain-Driven Design

 

This chapter covers

    • The 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 was to just add an if clause. Although seldom a local programming mistake, the problem was poorly understood, and the solution was built on a model that 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 (Dog Ear Publishing, 2014)

    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