|
| 1 | +# Lab: the code from the Domain-Driven Design article |
| 2 | + |
| 3 | +Runnable checks for [the article](../../posts/2026-11-02-domain-driven-design.md). |
| 4 | +Docker must be running. The script creates and removes its own PostgreSQL container; |
| 5 | +it does not use an existing database. Run from this directory in a repository checkout: |
| 6 | + |
| 7 | +```bash |
| 8 | +uv run --no-project --python 3.13 --with-requirements requirements.txt ddd_lab.py |
| 9 | +``` |
| 10 | + |
| 11 | +Dependencies are pinned in `requirements.txt`: sqlalchemy-foundation-kit 0.5.1, omni-box 0.3.1, |
| 12 | +SQLAlchemy 2.1.6, asyncpg 0.32.0 and testcontainers 4.15.0. The image is `postgres:17-alpine`; |
| 13 | +the script prints its server version (17.11 in the verified run). |
| 14 | +sqlalchemy-foundation-kit 0.5.1 is the first release that imports on SQLAlchemy 2.1 |
| 15 | +([#78](https://github.com/bedrock-python/sqlalchemy-foundation-kit/issues/78), found while writing this lab). |
| 16 | + |
| 17 | +The lab keeps no copy of the article's code. `ddd_lab.py` reads the code blocks from the English |
| 18 | +and Russian editions, checks that both show the same code, and runs each block in a fresh namespace |
| 19 | +with the names it takes for granted. `support.py` holds what the article leaves out: the tables, |
| 20 | +the repositories and the full `User` with CanExecute / Execute and domain events. |
| 21 | + |
| 22 | +In memory it checks that: |
| 23 | + |
| 24 | +- the anemic `PersonService` leaves `is_employee` stale, as the article says; |
| 25 | +- the eleventh order makes a `Customer` Advanced, and the orders are read-only; |
| 26 | +- `OverbookingPolicy` accepts 110% of capacity and refuses 111%; |
| 27 | +- the functional core returns a `FileUpdate` that the shell applies, and the article's test passes without a disk; |
| 28 | +- each of the three trilemma options rejects a taken address; |
| 29 | +- with CanExecute / Execute the controller asks first, and calling `change_email` around the check raises (the block has no `assert`); |
| 30 | +- `Money` is equal by value and checks currency and sign; `Order` is equal by id and stays hashable; |
| 31 | +- `transfer`, `DelinquentInvoice` and the `MessageBus` wrapper behave as described. |
| 32 | + |
| 33 | +On PostgreSQL it adds the article's unique constraint with its `ALTER TABLE` and runs the assembled `change_email`: |
| 34 | + |
| 35 | +- the user, the company and the outbox row commit together, and the event carries `aggregate_type="user"`; |
| 36 | +- a confirmed email and a taken address leave nothing written; |
| 37 | +- a failing outbox write rolls back the user and the company; |
| 38 | +- two transactions both read the address as free before either writes; the constraint lets one commit, and the other gets `Email is taken`; |
| 39 | +- with ORM-tracked saves, the violation surfaces at the flush that `transaction()` runs before commit, still as `IntegrityError`. |
| 40 | + |
| 41 | +Fragments the article prints as partial classes (the aggregate, the repository over `_db`, the `User` that records events) |
| 42 | +are not run as printed; `support.py` has the complete versions the PostgreSQL checks use. |
| 43 | +The script prints `PASS: article snippets` only when all assertions succeed. |
0 commit comments