Tag: domain-driven-design

Andrew Harmel-Law

The Heart of Domain-Driven Design

Complexity in Software Tackling complexity is the heart of software. Complexity is in the problem domain, not in our software. We add our own complexity in solving the problem that may or may not be needed. This additional complexity is on us.

Concepts of that are Core to Successful Domain Driven Design

Ubiquitous Language

Domain Experts are developers who can’t code and we are developers who don’t know the domain.

Translation fractures the language between the developer and the business. It’s a mental overhead and things are always lost in translation. If we (the engineering team) and the business have the same understanding and use the same terminology there is no overhead to communication concepts. There is no opportunity to lose meaning in translation. What the point of using two different terms to mean the same thing? Isn’t this idea much like copy and pasting code? They might be the same to start with, but they always diverge over time?

Why are accounts in the banking domain opened and not created?

Respect the domain experts, the domain might seem simple, but once you start talking to the domain experts, it’s not. Domain experts have the solution to one of the hardest problems in Software Development and that’s they names for all the concepts.

Domain experts have a term that succinctly communicates a complex idea?

Are they correcting your word usage?

If so, these are the hints of a complex ideas and the naming to got along with it.

Hands-On Modelers

Developer assumptions get shipped to production and sometimes these assumptions are wrong.

In a typical organization the business domain is documented by a Business Analysis, which records what they think the developers will need. This document is then handed to the Developers. The Developers are reading the Cliff Notes version of the domain problem. This may or may not be the details the developers need to complete their work. Getting the Developers as close to the source of information gives the highest chance of getting the software right.

Engineers working on the model must understand the change they are making and how they are improving the model. If they don’t understand this then they are weakening the model.

Tests verify the facts of your Ubiquitous Language are still true.

Procedural and Data-Centric don’t work for DDD.

Breakthroughs (fine tuning the Ubiquitous Language)

Focus on breakpoints on the Ubiquitous Language. ARea’s of the domain/model that break down and don’t meet the needs of the problem domain.

Tests don’t do this because most of the time you are testing the positive of the assumptions.

Multiple Models

"Bounded Contexts"

A bounded context is an area of the problem domain that had natural or logic borders from other idea’s in a system.

DRY (Don’t Repeat Yourself) doesn’t apply across Bounded Context boundaries. If you do, you are coupling these two Bounded Contexts. The fact that they are two bounded context means they are two different spaces and shouldn’t have overlap. Sharing algothrims is coupling.

If there are truly algorithms that span Bounded Contexts, they should be cross-cutting concerns. For example, working in the financial industry and using financial calculations in multiple Bounded Context is an example of Cross-Cutting concerns.

DRY isn’t about code, it’s not about removing code duplication, but removing duplication of knowledge.

Nested Bounded Contexts aren’t a thing.

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.