# DDD - Domain Driven Design

## What is DDD?

It is a way to develop software **focusing** at the heart of the application - called `Domain`- with the objective of understanding its rules, processes and complexities, and **separating** them from other complex topics that usually are added during development.

It is about modeling a `Ubiquitous Language` in an explicitly [#bounded-contexts](https://kdongs.gitbook.io/kdocs/ddd/strategic-modeling#bounded-contexts "mention").

## Usability

DDD is/should be used for **complex softwares**.

* Big projects have many areas, many business rules, many people with different visions in different contexts.
* A lot of the complexity from this softwares are not technological, but communicational, from separating contexts, understanding of the business from many angles.

The challenge is to **balance** the amount of needed information to preserve the invariance and the resource consumption (*like memory)*, since the seggregation of Domains and Subdomains can increase the amount of code and memory usage.

{% hint style="warning" %}
DDD **always** breaks down into **two sections**:

* [tactical-modeling](https://kdongs.gitbook.io/kdocs/ddd/tactical-modeling "mention"), helps on building the Domain Model, separating your Core/Domain entities into Domain Objects, complementing `Clean Architecture` `Entity Layer`.
* [strategic-modeling](https://kdongs.gitbook.io/kdocs/ddd/strategic-modeling "mention"), to help divide your application code into separate code bases, depending on Domains and Subdomains.

**That are used for different reasons, together or separated.**
{% endhint %}

<figure><img src="https://4117899876-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FzHW4Qy3sVvzzQVSgW17m%2Fuploads%2FyxzplIFfghLQnX2T3XlH%2Fimage.png?alt=media&#x26;token=68b3279c-331b-4af3-9e9c-fa5b173efc00" alt=""><figcaption></figcaption></figure>

## How DDD helps?

Helps understanding the deepness of the Domain and Subdomains of the application.

:star: Helps in having a universal language (Ubiquitous Language) between everyone involved. *(From the software specification until the variables names used in the code)*

* Think of the meaning of the word `Client` for different areas of the business. They could have different meanings and refer to different things.
* So having everyone speak the same language is indispensable.

Helps creating a strategic design using `Bounded Context`.

Helps showing what is business complexities and what is technical complexities.

### Context Map

* The interaction between bounded contexts is by a **Context Map**.

<figure><img src="https://4117899876-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FzHW4Qy3sVvzzQVSgW17m%2Fuploads%2FXP67ePPmW76zDmzYlHkc%2Fcontext-map.png?alt=media&#x26;token=6f6fe6da-b687-4c28-8900-0cad862286f2" alt=""><figcaption></figcaption></figure>

### Integration Patterns

* The integration patterns naturally define the relationship type between each bounded context.

#### Partnership

**Shared Kernel**

* Collection of code that can be shared like a npm package. It will be used by multiple bounded contexts.
* Using code versioning like Semantic Versioning `1.0.0`.

**Customer/Supplier**

* You have the Upstream (The consumed) and Downstream (Who consumes).
* There is a supply relationship where the customer and the supplier may determine how the contract between them should be.

**Conformist**

* The downstream must accept what the upstream gives him.
* Brings the risk of accepting the nomenclature of the upstream into your code.
* Usually requires an Anti-Corruption layer.

**Anti-Corruption Layer**

* Is a layer to translate nomenclatures that come from upstreams.
  * Like when conforming.

**Open-host Service**

* When you offer services to the outside.
* You try to simplify the internal complex logic, by providing the simpler interface for the outside world.
