Domain Driven Design (DDD)

Domain Driven Design

  1. Strategic Design (Overview of the domain/app on the higher level)
  2. Tactical Design (Overview at the lower level)

Strategic Design

We talk about the problems and not solutions yet.

  • Event storming
    • events
    • commands
    • policies, users
  • Ubiquitous language
  • Domain analysis -> Core subdomains -> Supporting subdomains -> Generic Subdomains

Core Subdomains The place where the business gets the most of the value. Code in this subdomain is written by developers.

Supporting Subdomains

  • use off the shelf providers (payments, etc)

Generic Subdomains

  • Outsourced, SAP, etc

Technical Design

Solution space, more technical

  • Bounded contexts
    • Very similar to subdomains but can span over multiple subdomains
  • Entities
    • Can span over multiple bounded contexts
  • Value objects
  • Aggregates
  • Domain events
  • Domain & Application services

Entities

  • Unique Items, with a unique identifier. Example: A company with a unique ID
  • May span multiple bounded contexts

Value Object

  • have no ID, defined by its values
  • immutable
  • basic building blocks of the domain model. Example: status, address, etc

Aggregates

  • Cluster one or more entities into a consistency boundary
  • Has one root entity
  • usually bound to a transaction scope
  • Application service -> Domain service -> Aggregate -> root entity -> Entities & Value objects

Services

  • Has no state
  • Domain services encapsulate domain logic
  • Application services: Auth, email, etc

What is a DDD Aggregate

Source: https://www.youtube.com/watch?v=zlFqjD2LKlE

Aggreate is an imaginary boundary for holding data consistency for a bunch of entities, driven through the Root Entity.

Example: If I have an user entity, and session entity, and if I want to invalidate the session, the wrong way to do this is to get the user.current_session() and then do session.invalidate(). This is basically exposing session to the outer world.

The right way is to do user.invalidate_session(), where the user is the root entity here, for accessing session and maintaining data consistency.

Aggregate is a unit of consistency and concurrency. Aggregates are distinct, so they need to carry some kind of identity.

2 Users are different, having different User IDs.

Context mapping

Surprising truth about what motivates us - Autonomy, mastery and purpose This also applied to teams and bounded contexts in software

Bounded Context

Is a boundary for a model expressed in a consistent (ubiquitous) language tailored around a specific purpose

  • Propagation of models ? Why bad ?
  • Dependency between teams
    • Mutually dependent
    • Free
      • Changes in one bounded context do not influence success or failure in other bounded contexts.
    • Upstream/Downstream
      • An upstream context will influence the downstream counterpart while the opposite might not be true

9 Patterns

  • Partnership
  • Shared kernel
    • Physically shared artifact between two teams
    • Examples: Shared JARs or database
  • Customer / supplier
  • Conformist
    • Take the model with upstream and just use it. Represented as CF
  • Anticorruption layer
  • separate ways
  • Open / Host service
    • one API for several consumers
    • Common, general purpose model and functionality
    • Upstream service
  • Published language
  • Big Ball of Mud