---
url: /guide/learning-path.md
description: >-
  New to Domain-Driven Design? A reading order through the Alveolus docs, from
  bounded contexts to aggregates, handlers and architecture checks, in
  TypeScript.
---

# Learning path

New to Domain-Driven Design? Read the pages in this order: each step builds on the one before, and
each page explains one idea with the same `Order` example.

::: info An introduction, not a course
These pages explain each idea as far as you need it to use Alveolus. They are not a complete course
on Domain-Driven Design. For the whole picture, read the books:

* *Domain-Driven Design: Tackling Complexity in the Heart of Software*, Eric Evans, 2003
* *Implementing Domain-Driven Design*, Vaughn Vernon, 2013
* *Domain-Driven Design Distilled*, Vaughn Vernon, 2016
* *Learning Domain-Driven Design*, Vlad Khononov, 2021
  :::

::: tip Already know DDD?
Go straight to [Getting started](./getting-started.md) and come back to a page when you need it.
:::

## Why DDD

Software gets hard to change when its code no longer says what the business means. DDD puts the
business at the center of the code, in its own words.

## Split the system

Before writing a class, decide where its words apply. A "product" in the catalog and a "product" in
ordering are not the same thing: each part of the system gets its own model.

## Model the rules

Inside a context, the domain holds the business rules. Start from the smallest pieces and build up
to the aggregate, the object that keeps the rules of an order.

## Record what happened

When the rules accept a change, the aggregate records it as a fact other code can react to.

## Reach the outside world

The domain still needs things it does not own: a rule spread over several objects, a price from
elsewhere, a place to store orders. It asks for them in its own words.

## Run a use case

The application layer turns a request, such as "place this order", into a call to the domain, and
saves the result.

## Talk to other contexts

Contexts never import each other. They tell each other what happened in plain JSON, and each one
translates what it reads into its own model.

## Keep it on track

Each idea above becomes a rule the checks verify, so the code keeps it whoever writes it.

## See also

* [Getting started](./getting-started.md), to install Alveolus and run the checks
* [Project layout](./project-layout.md), the folders and layers of a project
* [Building blocks](../core/index.md), every class `@alveolus/core` gives