Domain Driven Design Notes

Why DDD?

YAGNI – You are not going to need it.

  • Shortening development time

KISS – Keep it short and simple

  • Maintainable

DDD

  • Focus on essentials parts
  • Simplifying the problems.

We can only handle so much complexity in our brains.

Ubiquitous language

  • Use the same language between the coders, QA, BA, Clients

Bounded Context

  • Separate area’s of the system that don’t make sense to be together.

Core Domain – Focus on the most important part of the system. Think of Core Competency in business

When to unit test Where Test Coverage meets value. At some point, adding tests doesn’t add value. I.e. principle of diminishing returns

Types of Equality Identifier equality – do the Id’s between the entities match? Reference equality – do the two objects point to the same reference in memory Structural equality – do the two objects have the same values.

Entities vs. Value Objects

  • Entities
    • Have inherent Identity
    • Reference equality
    • Identifier equality
    • Single place for equality members
  • Value Object
    • Value objects don’t have an identifier field.
    • Can be treated interchangeably
    • Immutable
    • Can’t live on their own, must belong to one or several entities

How to Recognize a Value Object

  • Value objects are light-weight
  • Put most of business logic to value objects
  • Entities act as wrappers

When to create a Repository Repositories are generally created for each aggregate root.

Null Object Design Pattern

Command Query Separation Principle

Anti-Corruption Layer

Bounded Context is a logic separation of the domain in the code. Some examples of this in use is putting all the code related to a Bounded Context under the same folder or using different schemas in the database. Yet, another possibility is different deployments.

Leave a Comment