Kapitola 21 · Praxe · Anti-vzory a typické chyby v DDD

Anti-vzory a typické chyby v DDD

Q: Proč je Primitive Obsession problém?

Primitive Obsession znamená používání primitivních typů ( string , int , float ) tam, kde patří doménový pojem. Místo typu Email se předává string , místo Money dvojice float . Důsledkem je, že validace a pravidla se opakují v každém místě volání, nebo se zapomínají. Hodnotový objekt s jedním místem validace tyto duplicity odstraňuje a typ dává kontext, co daná hodnota reprezentuje. Rozbor a příklady v sekci Primitive Obsession .

Q: Musí být doménová událost neměnná?

Ano. Doménová událost popisuje něco, co se již stalo – OrderPlaced , PaymentReceived – a minulost nelze měnit. Událost bez setterů, s neměnnými atributy a časovým razítkem vytvořeným při konstrukci je bezpečné sdílet mezi handlery, persistovat v event store a použít pro zpětnou rekonstrukci stavu. Mutovatelná událost vede k race condition, nedeterministickému zpracování a nekonzistentnímu auditu. Viz sekci Mutovatelné doménové události .

Přehled nejčastějších anti-vzorů a typických chyb při implementaci Domain-Driven Design: anémický doménový model, Primitive Obsession, příliš velký agregát, sdílená databáze napříč Bounded Contexts, mutovatelné události a over-engineering.

Autor M. Katuščák

Doba čtení ≈ 38 min

Náročnost mírně pokročilá

Publikováno · Aktualizováno 24. 4. 2025 · 8. 7. 2026

Obsah kapitoly

21.01 Úvodem: Proč znát anti-vzory#

Tato kapitola je katalog kódových a modelovacích anti-vzorů v DDD. Pro provozní/infrastrukturní třenice (Doctrine, Messenger, ACL k externím API, Symfony Form vs. Command) viz DDD v praxi – kde to bolí. Pro rozhodovací rámec, jestli DDD vůbec použít, viz Kdy DDD nepoužívat.

DDD nabízí strukturu pro modelování domény, ale s tou strukturou přicházejí specifická úskalí. Týmy začínající s DDD opakovaně narážejí na stejné chyby, i když teorii rozumějí. Anti-vzory je proto potřeba znát stejně dobře jako vzory samotné. Definice termínů použitých v této kapitole (entita, hodnotový objekt, agregát, bounded context) najdete v kapitole Základní koncepty DDD.

Anti-vzor je přístup, ke kterému vývojáři přirozeně sklouznou. Vypadá správně, ale narušuje principy DDD a dlouhodobě podkopává udržovatelnost, testovatelnost i výkon. Každá sekce níže proto nese rozpoznávací znak – větu, podle které zjistíte, jestli se problém týká vašeho kódu – a hranici, za kterou už kritizovaný postup chybou není.

Nejznámější anti-vzor DDD zde nenajdete. Big Ball of Mud, tedy oblast bez rozeznatelných hranic, patří ke Context Mappingu, protože se dá vědomě ohraničit a nechat být; rozebírá jej sekce 03.12.

§ Poznámka

Klasifikace typických chyb v DDD

Chyby při implementaci DDD spadají do tří kategorií podle toho, kde vznikají a kolik stojí jejich náprava. Sekce této kapitoly jsou k nim přiřazeny níže.

Strategické chyby – špatně definované Bounded Contexts, ignorování Ubiquitous Language, sdílená databáze napříč kontexty (21.05, 21.09). Dopad je nejzávažnější, protože strategické chyby ovlivňují celkovou architekturu systému.
Taktické chyby – anémický doménový model (21.02), Primitive Obsession (21.03), příliš velké agregáty (21.04). Projevují se na úrovni doménového modelu a narušují objektově orientované principy.
Implementační chyby – mutovatelné události (21.06), doménová logika v infrastrukturní vrstvě (21.07), over-engineering (21.08). Vznikají při konkrétní implementaci a obvykle se opravují nejsnáz.

21.02 Anti-vzor: Anémický doménový model (Anemic Domain Model)#

Anémický model patří k nejčastějším anti-vzorům objektově orientovaného vývoje a v DDD zvlášť bolí. Termín popularizoval Martin Fowler v článku z roku 2003 [1]. Doménové třídy (entity, agregáty) v něm slouží pouze jako datové kontejnery. Obsahují výhradně gettery a settery a veškerá doménová logika je přesunuta do servisní vrstvy.

Fowler považoval argument „porušuje se zapouzdření“ za příliš slabý a připojil druhý, nákladový: anémický model nese veškeré náklady doménového modelu, aniž by přinášel jeho užitek. Zaplatíte mapování na databázi, obalování hodnot a rozpad kódu do vrstev, a dostanete datovou strukturu, kterou by obsloužil obyčejný SELECT. Účet bez protihodnoty je jádro problému, ne nedodržená poučka o OOP.

Rozpoznávací znak. Vaughn Vernon k tomu v Implementing Domain-Driven Design (2013) nabízí diagnostický test dvou otázek. Volně přeloženo: má vaše entita jen gettery a settery, a žije pravidlo, které s jejími daty pracuje, v cizí třídě? Dvě „ano“ znamenají anémii. Test je použitelnější než definice, protože ho pustíte na konkrétní soubor.

Anémický vs. bohatý doménový model – kde sedí logika

§ Poznámka

Proč je anémický model problém?

Porušení zapouzdření (encapsulation) – základní princip OOP říká, že data a chování, které na nich operuje, by měly být společně. Anémický model toto porušuje tím, že data jsou v entitě, ale logika je jinde.
Ztráta modelu jako abstrakce domény – pokud entity obsahují pouze data, model přestává vyjadřovat chování domény a stává se pouhým datovým schématem přeloženým do tříd. Doménový expert by v takovém modelu nerozeznal žádné doménové procesy ani pravidla, pouze strukturu dat – model tak ztrácí svůj komunikační a dokumentační přínos.
Duplicita logiky – doménová pravidla rozptýlená do service tříd vedou k jejich kopírování na více místech, protože není jasné kanonické místo pro logiku.
Testy potřebují víc lešení – pravidlo přesunuté do služby se testuje přes celou tuto službu a přes všechno, co má v konstruktoru. Entita bez závislostí se otestuje jedním new a jedním voláním. Výhoda ale není bezpodmínečná: dobře navržená aplikační služba se testuje bez potíží a agregát, který ke svému rozhodnutí potřebuje kolaboranty, ji ztrácí také.

Anti-vzorem není servisní vrstva jako taková. Fowler v témže článku Service Layer výslovně obhajuje a odmítá jen to, aby v ní žila veškerá doménová logika. Rozlišit je proto potřeba tři věci, které se v projektech jmenují stejně:

Aplikační služba orkestruje: načte agregát, zavolá na něm jednu metodu, uloží výsledek, odešle události. Vlastní doménové pravidlo neobsahuje a je legitimní.
Doménová služba nese pravidlo, které nepatří jedinému agregátu – výpočet přes několik agregátů nebo politiku s externím vstupem. Je to řádný stavební blok, viz doménové služby.
„God service“ drží pravidla patřící entitám, které samy nemají žádné chování. Teprve to je anémický model.

✕ Anti-vzor

Příklad: Anémická entita User (špatně)

php src/UserManagement/Domain/Model/User.php

1<?php2 3declare(strict_types=1);4 5// ŠPATNĚ: Entita je pouze datový kontejner6 7namespace App\UserManagement\Domain\Model;8 9class User10{11    private string $id;12    private string $email;13    private string $status;14    private ?string $verificationToken;15    private \DateTimeImmutable $createdAt;16 17    public function getId(): string { return $this->id; }18    public function setId(string $id): void { $this->id = $id; }19 20    public function getEmail(): string { return $this->email; }21    public function setEmail(string $email): void { $this->email = $email; }22 23    public function getStatus(): string { return $this->status; }24    public function setStatus(string $status): void { $this->status = $status; }25 26    public function getVerificationToken(): ?string { return $this->verificationToken; }27    public function setVerificationToken(?string $token): void { $this->verificationToken = $token; }28 29    public function getCreatedAt(): \DateTimeImmutable { return $this->createdAt; }30    public function setCreatedAt(\DateTimeImmutable $dt): void { $this->createdAt = $dt; }31}32 33// ŠPATNĚ: Veškerá doménová logika v servisní třídě34class UserService35{36    public function activateUser(User $user, string $token): void37    {38        if ($user->getStatus() !== 'pending') {39            throw new \DomainException('User is not pending activation.');40        }41        if ($user->getVerificationToken() !== $token) {42            throw new \DomainException('Invalid verification token.');43        }44        $user->setStatus('active');45        $user->setVerificationToken(null);46    }47 48    public function deactivateUser(User $user): void49    {50        if ($user->getStatus() !== 'active') {51            throw new \DomainException('User is not active.');52        }53        $user->setStatus('inactive');54    }55}

◢ Vzor

Příklad: Bohatá entita User (správně)

php src/UserManagement/Domain/ValueObject/UserStatus.php

1<?php2 3declare(strict_types=1);4 5namespace App\UserManagement\Domain\ValueObject;6 7enum UserStatus: string8{9    case Pending = 'pending';10    case Active = 'active';11    case Inactive = 'inactive';12 13    public function isPending(): bool14    {15        return $this === self::Pending;16    }17 18    public function isActive(): bool19    {20        return $this === self::Active;21    }22}23 24final class VerificationToken25{26    private function __construct(27        public readonly string $value,28    ) {}29 30    public static function generate(): self31    {32        return new self(bin2hex(random_bytes(32)));33    }34 35    public static function fromString(string $value): self36    {37        return new self($value);38    }39 40    public function equals(self $other): bool41    {42        return hash_equals($this->value, $other->value);43    }44}

php src/UserManagement/Domain/Model/User.php

1<?php2 3declare(strict_types=1);4 5// SPRÁVNĚ: Entita obsahuje doménovou logiku6 7namespace App\UserManagement\Domain\Model;8 9use App\UserManagement\Domain\ValueObject\Email;10use App\UserManagement\Domain\ValueObject\UserId;11use App\UserManagement\Domain\ValueObject\UserStatus;12use App\UserManagement\Domain\ValueObject\VerificationToken;13use App\UserManagement\Domain\Event\UserRegistered;14use App\UserManagement\Domain\Event\UserActivated;15use App\UserManagement\Domain\Event\UserDeactivated;16use App\UserManagement\Domain\Exception\InvalidVerificationTokenException;17use App\UserManagement\Domain\Exception\UserAlreadyActivatedException;18use App\UserManagement\Domain\Exception\UserNotActiveException;19use App\SharedKernel\Domain\AggregateRoot;20 21final class User extends AggregateRoot22{23    private readonly UserId $id;24    private readonly Email $email;25    private UserStatus $status;26    private ?VerificationToken $verificationToken;27    private readonly \DateTimeImmutable $createdAt;28 29    private function __construct(30        UserId $id,31        Email $email,32        VerificationToken $verificationToken33    ) {34        $this->id = $id;35        $this->email = $email;36        $this->status = UserStatus::Pending;37        $this->verificationToken = $verificationToken;38        $this->createdAt = new \DateTimeImmutable();39    }40 41    public static function register(UserId $id, Email $email): self42    {43        $token = VerificationToken::generate();44        $user = new self($id, $email, $token);45        $user->record(new UserRegistered($id, $email));46        return $user;47    }48 49    public function activate(VerificationToken $token): void50    {51        if (!$this->status->isPending()) {52            throw UserAlreadyActivatedException::forUser($this->id);53        }54        if (!$this->verificationToken->equals($token)) {55            throw InvalidVerificationTokenException::forUser($this->id);56        }57        $this->status = UserStatus::Active;58        $this->verificationToken = null;59        $this->record(new UserActivated($this->id));60    }61 62    public function deactivate(): void63    {64        if (!$this->status->isActive()) {65            throw UserNotActiveException::forUser($this->id);66        }67        $this->status = UserStatus::Inactive;68        $this->record(new UserDeactivated($this->id));69    }70 71    public function id(): UserId { return $this->id; }72    public function email(): Email { return $this->email; }73    public function status(): UserStatus { return $this->status; }74}

Rozdíl je v tom, že správná entita vystavuje doménově orientované metody (activate(), deactivate(), register()) místo generických setterů. Entita sama garantuje své invarianty – nikdo zvenčí ji nedostane do nekonzistentního stavu.

§ Poznámka

Getter a setter už nejsou spolehlivý příznak

Fowlerova diagnóza z roku 2003 se opírala o tvar kódu: dvojice getX() / setX() znamenala datový kontejner. PHP 8.4 tento signál oslabuje. Asymetrická viditelnost public private(set) UserStatus $status [4] vystaví vlastnost ke čtení a zápis nechá jen uvnitř třídy; property hooks [5] odstraní většinu ručně psaných přístupových metod. Entita bez jediného getteru proto může být stejně anémická jako ta s dvaceti.

Příznakem zůstává veřejný zápis stavu bez doménového jména. Řádek $user->status = UserStatus::Active; v aplikační vrstvě je totéž co setStatus('active'), jen kratší. Hodnotové objekty této knihy hooky nepoužijí: s readonly vlastnostmi je zkombinovat nelze [5].

Kdy anémický model chyba není

Fowler sám připouští, že doménový model není vždy nejlepší nástroj, a odkazuje na Transaction Script [2] – řádný vzor z Patterns of Enterprise Application Architecture, který organizuje logiku po procedurách, jednu na požadavek. V doméně s pěti pravidly bývá procedura čitelnější než šest tříd okolo ní. Volba mezi vzory patří k rozhodnutí o typu subdomény, viz Kdy DDD nepoužívat.

Druhou výhradu přináší funkcionální škola. Mark Seemann ukazuje, že zapouzdření není totéž co metoda na objektu: stejnou garanci dá typ, který nelze zkonstruovat do neplatného stavu, plus modul funkcí nad ním [3]. Data od chování oddělit lze. Co oddělit nelze, je validace od dat – záznam s veřejnými poli, který kdokoli naplní čímkoli, je anémický v tom škodlivém smyslu, i kdyby funkce nad ním byly sebelépe napsané.

Hranice pravidla. Anémický model je chyba tehdy, když platíte cenu doménového modelu bez jeho přínosu. Rozhodli jste se pro doménový model? Pak v něm mají být pravidla. Rozhodli jste se pro Transaction Script? Pak žádnou anémii neřešíte, jen to rozhodnutí musíte umět pojmenovat a nevydávat adresář Domain/ za doménový model.

21.03 Anti-vzor: Primitive Obsession (posedlost primitivy)#

Primitive Obsession nastává, když vývojáři používají primitivní datové typy (string, int, float) tam, kam patří hodnotové objekty (Value Objects). Primitiva působí na první pohled přímočaře, ale vedou k závažným problémům.

Rozpoznávací znak. Najděte si validaci e-mailu ve svém projektu a spočítejte, na kolika místech stojí. Tři výskyty téhož filter_var() nad toutéž hodnotou znamenají, že hodnota chce vlastní typ.

✕ Anti-vzor

Příklad: Primitive Obsession (špatně)

php src/Order.php

1<?php2 3declare(strict_types=1);4 5// ŠPATNĚ: Primitiva místo hodnotových objektů6 7class Order8{9    private int $id;10    private int $userId;      // int, stejný typ jako $id - záměna je možná!11    private string $email;    // libovolný string, bez validace12    private float $amount;    // float pro peníze - nebezpečné kvůli zaokrouhlování13    private string $currency; // string "CZK", "EUR"... bez omezení14 15    public function __construct(16        int $id,17        int $userId,18        string $email,19        float $amount,20        string $currency21    ) {22        // Validace (pokud vůbec existuje) je rozptýlena do konstruktoru23        if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {24            throw new \InvalidArgumentException('Invalid email');25        }26        if ($amount < 0) {27            throw new \InvalidArgumentException('Amount cannot be negative');28        }29        // ... a opakuje se na každém dalším místě, kde se s hodnotami pracuje30        $this->id = $id;31        $this->userId = $userId;32        $this->email = $email;33        $this->amount = $amount;34        $this->currency = $currency;35    }36}37 38// Typový systém PHP neodhalí tuto chybu:39$orderId = 42;40$userId = 17;41processOrder($userId, $orderId); // Záměna parametrů - a PHP si nestěžuje!

◢ Vzor

Příklad: Value Objects (správně)

php src/OrderManagement/Domain/ValueObject/Email.php

1<?php2 3declare(strict_types=1);4 5// SPRÁVNĚ: Hodnotové objekty s validací a sémantikou6 7namespace App\OrderManagement\Domain\ValueObject;8 9use Symfony\Component\Uid\Uuid;10 11final class Email12{13    public function __construct(public readonly string $value)14    {15        if (!filter_var($value, FILTER_VALIDATE_EMAIL)) {16            throw new \InvalidArgumentException(17                sprintf('"%s" není platná e-mailová adresa.', $value)18            );19        }20    }21 22    public static function fromUserInput(string $raw): self23    {24        // Normalizace (lowercase, trim) patří sem, ne do konstruktoru.25        return new self(mb_strtolower(trim($raw)));26    }27 28    public function equals(self $other): bool { return $this->value === $other->value; }29    public function __toString(): string { return $this->value; }30}31 32enum Currency: string33{34    case CZK = 'CZK';35    case EUR = 'EUR';36    case USD = 'USD';37}38 39// Kanonická podoba Money i s metodou zero() je v kapitole Základní koncepty.40// Zde slouží jen jako protipól k float + string výše.41final readonly class Money42{43    public function __construct(44        public int $amountInCents, // Celé číslo - žádná plovoucí desetinná čárka45        public Currency $currency,46    ) {47        if ($amountInCents < 0) {48            throw new \InvalidArgumentException(49                'Money cannot be negative; use SignedMoney for credits/debits.'50            );51        }52    }53 54    public function add(self $other): self55    {56        if ($this->currency !== $other->currency) {57            throw new \DomainException(58                "Cannot add {$this->currency->value} and {$other->currency->value}"59            );60        }61 62        return new self($this->amountInCents + $other->amountInCents, $this->currency);63    }64}65 66// Silně typované identifikátory - záměna je odhalena typovým systémem67final class OrderId68{69    public function __construct(public readonly string $value)70    {71        // Uuid::isValid ze symfony/uid přijímá všechny verze UUID -72        // identifikátory v této knize vznikají přes Uuid::v7(), kterou73        // by regex omezený na verzi 4 odmítl.74        if (!Uuid::isValid($value)) {75            throw new \InvalidArgumentException('Neplatný formát UUID pro OrderId.');76        }77    }78    public function equals(self $other): bool { return $this->value === $other->value; }79}80 81final class UserId82{83    public function __construct(public readonly string $value) { /* stejná validace */ }84}85 86// Nyní typový systém PHP odhalí záměnu:87function processOrder(OrderId $orderId, UserId $userId): void { /* ... */ }88 89$orderId = new OrderId('018f4d2e-...');90$userId  = new UserId('02b5e8c1-...');91processOrder($userId, $orderId); // PHP TypeError: Argument #1 must be of type OrderId

Money odmítá zápornou částku záměrně: pro dobropisy a odpisy má kniha samostatný typ SignedMoney, aby se nemohla ztratit informace o směru pohybu. Plnou definici obou hodnotových objektů uvádí sekce 06.04; ukázka výše je zkrácená na to, co odlišuje hodnotový objekt od float a string.

Hodnotový objekt má i svou cenu. Vyplatí se tam, kde hodnota splní alespoň jednu ze tří podmínek: nese vlastní pravidla platnosti (Email, BirthNumber), má vlastní operace (Money::add()), nebo hrozí její záměna s jinou hodnotou téhož primitivního typu (OrderId proti UserId). Evans totéž říká obráceně – jako hodnotový objekt klasifikujte prvek modelu, u kterého vás zajímají pouze jeho atributy a logika [6].

Hranice pravidla. Pole note, description nebo internalComment žádnou z podmínek nesplňuje. Třída Note obalující string bez jediného pravidla je přesně ta ceremonie, před kterou varuje sekce 21.08. Kritériem tedy není počet primitiv v kódu, ale duplikovaná validace a riziko záměny.

21.04 Anti-vzor: Příliš velký agregát (God Aggregate)#

Agregát navrhujeme kolem transakční konzistence – tedy kolem nejmenší skupiny objektů, kterou je třeba měnit společně v jedné transakci. Příliš velký agregát (tzv. „God Aggregate“) sdružuje pod jeden kořen entity a logiku, které k sobě transakčně nepatří. Tím porušuje princip jedné odpovědnosti a způsobuje problémy popsané níže. Vernon pro tentýž jev používá střízlivější název large-cluster aggregate; komunita se drží dramatičtějšího „God“.

Rozpoznávací znak. Podívejte se na poslední přidání položky do kolekce uvnitř agregátu. Pokud kvůli jednomu novému řádku načítáte tisíc existujících, je hranice agregátu vedená podle asociací, ne podle invariantů.

God Aggregate vs. správně rozdělené agregáty propojené přes ID

§ Poznámka

Problémy způsobené příliš velkým agregátem

Výkonnostní problémy – načtení celého agregátu z databáze je pomalé, pokud obsahuje stovky nebo tisíce podřízených entit (např. všechny položky objednávky zákazníka za celý rok).
Problémy s konkurencí (concurrency) – agregát je zamčen jako celek při každé změně. Velký agregát znamená větší pravděpodobnost konfliktů při souběžném přístupu.
Těsné provázání (tight coupling) – příliš mnoho entit uvnitř jednoho agregátu ztěžuje nezávislý vývoj a testování.

A nakonec hranice. God agregát bývá příznakem špatně definovaných hranic kontextů – tam, kde do jednoho celku spadne víc, než kam sahá jeden Bounded Context.

✕ Anti-vzor

Příklad: Příliš velký agregát (špatně)

php src/Customer.php

1<?php2 3declare(strict_types=1);4 5// ŠPATNĚ: God Aggregate - příliš mnoho odpovědností6 7class Customer8{9    private CustomerId $id;10    private string $name;11    private Email $email;12 13    /** @var Order[] */14    private array $orders = [];        // Celá historie objednávek15 16    /** @var Address[] */17    private array $addresses = [];     // Všechny adresy zákazníka18 19    /** @var CreditCard[] */20    private array $creditCards = [];   // Platební karty21 22    /** @var ProductReview[] */23    private array $reviews = [];       // Recenze produktů zákazníkem24 25    /** @var WishlistItem[] */26    private array $wishlistItems = []; // Přání zákazníka27 28    // Při načtení zákazníka z DB musíme načíst vše - tisíce záznamů!29    // Při update zákazníka zamkneme celou tuto strukturu.30    // Přidání nové objednávky vyžaduje celý agregát v paměti.31}

◢ Vzor

Příklad: Správně rozdělené agregáty

php src/OrderManagement/Domain/Model/Customer.php

1<?php2 3declare(strict_types=1);4 5// SPRÁVNĚ: Malé agregáty s jednoznačnou odpovědností6 7namespace App\OrderManagement\Domain\Model;8 9use App\OrderManagement\Domain\ValueObject\OrderId;10use App\OrderManagement\Domain\ValueObject\CustomerId;11use App\OrderManagement\Domain\ValueObject\ProductId;12use App\OrderManagement\Domain\ValueObject\Address;13use App\OrderManagement\Domain\ValueObject\OrderStatus;14use App\OrderManagement\Domain\ValueObject\Money;15use App\OrderManagement\Domain\ValueObject\Email;16use App\OrderManagement\Domain\ValueObject\WishlistId;17use App\OrderManagement\Domain\Event\OrderConfirmed;18use App\SharedKernel\Domain\AggregateRoot;19 20// Agregát 1: Customer - pouze identita a kontaktní údaje21final class Customer22{23    private readonly CustomerId $id;24    private string $name;25    private Email $email;26 27    // Zákazník obsahuje jen to, co je součástí jeho identity.28    // Adresa pro doručení je součástí objednávky, ne zákazníka.29 30    public function changeEmail(Email $newEmail): void31    {32        if ($this->email->equals($newEmail)) {33            return; // Idempotentní změna, žádný přechod stavu34        }35        $this->email = $newEmail;36    }37}38 39// Agregát 2: Order - transakční hranice pro jednu objednávku40final class Order extends AggregateRoot41{42    private readonly OrderId $id;43    private readonly CustomerId $customerId; // Pouze reference - ne celý Customer objekt!44    private Address $shippingAddress;45    private OrderStatus $status;46 47    /** @var OrderItem[] */48    private array $items = [];49    private readonly \DateTimeImmutable $placedAt;50 51    private function __construct(52        OrderId $id,53        CustomerId $customerId,54        Address $shippingAddress55    ) {56        $this->id = $id;57        $this->customerId = $customerId;58        $this->shippingAddress = $shippingAddress;59        $this->status = OrderStatus::Draft;60        $this->placedAt = new \DateTimeImmutable();61    }62 63    public function addItem(ProductId $productId, int $quantity, Money $unitPrice): void64    {65        if ($this->status !== OrderStatus::Draft) {66            throw new InvalidOrderStateTransitionException(67                'Položky lze přidat pouze k objednávce ve stavu Draft.'68            );69        }70        $this->items[] = new OrderItem($productId, $quantity, $unitPrice);71    }72 73    public function confirm(): void74    {75        if ($this->items === []) {76            throw new EmptyOrderException();77        }78        $this->status = OrderStatus::Confirmed;79        $this->record(new OrderConfirmed(80            $this->id,81            $this->customerId,82            $this->totalAmount(),83            count($this->items),84        ));85    }86 87    public function totalAmount(): Money88    {89        // Měna plyne z položek objednávky, ne z konstanty zapsané v agregátu.90        // Pokud se položky v měně rozejdou, ohlásí to Money::add().91        $rest = $this->items;92        $first = array_shift($rest);93        if ($first === null) {94            throw new EmptyOrderException();95        }96 97        return array_reduce(98            $rest,99            fn(Money $carry, OrderItem $item) => $carry->add($item->subtotal()),100            $first->subtotal(),101        );102    }103}104 105// Agregát 3: Wishlist - zcela oddělená doménová odpovědnost106final class Wishlist107{108    private readonly WishlistId $id;109    private readonly CustomerId $customerId;110    /** @var WishlistItem[] */111    private array $items = [];112 113    public function add(ProductId $productId): void114    {115        foreach ($this->items as $item) {116            if ($item->productId()->equals($productId)) {117                return; // Invariant: každý produkt je v seznamu nejvýš jednou118            }119        }120        $this->items[] = new WishlistItem($productId);121    }122}

Pravidlo pochází z Vernonovy série Effective Aggregate Design [7]: agregát drží kořen a nezbytné minimum atributů a hodnotových vlastností, nic víc. Vernon k němu dodává větu, kterou katalogy anti-vzorů obvykle vynechávají – agregáty jsou hranice konzistence, ne výsledek snahy navrhnout graf objektů. Pokud změna jednoho objektu nevyžaduje konzistentní změnu druhého ve stejné transakci, patří do různých agregátů.

Hranice pravidla. Zmenšovat lze i příliš. Vernon pojmenovává obě selhání: agregát složený pro pohodlí kompozice je moc velký, agregát rozebraný na jednotlivé entity zase přestane chránit skutečné invarianty. Druhá chyba se hledá hůř, protože se neprojeví na výkonu, ale až nekonzistentními daty.

V Doctrine bývá nejčastější příčinou velkého agregátu samotné mapování. Asociace OneToMany popisuje vztah v databázi, ne transakční hranici: z toho, že objednávka má položky, neplyne, že zákazník má vlastnit svou historii objednávek. Vodítkem je invariant, který musí platit po každém commitu, nikoli tvar schématu.

21.05 Anti-vzor: Sdílená databáze napříč Bounded Contexts#

Sdílená databáze napříč Bounded Contexts patří mezi nejzávažnější strategické anti-vzory. Nastává, když různé kontexty sdílejí stejné databázové tabulky nebo přistupují přímo k datům jiného kontextu. Na počátku to vypadá pragmaticky, ale vede k těsnému provázání, které blokuje nezávislý vývoj a nasazení jednotlivých kontextů.

Rozpoznávací znak. Projděte migrace jednoho kontextu a hledejte tabulku, kterou vlastní jiný tým. Druhý příznak je provozní: nasazení kontextu A vyžaduje koordinaci s týmem kontextu B, přestože se jejich kód nikde nepotkává.

Hranice pravidla. Chybou není jedna databázová instance, ale sdílené schéma a dotaz vedený přes hranici. Modulární monolit běžně běží nad jednou databází s oddělenými schématy a vlastnictvím tabulek na úrovni modulu, a to je v pořádku. Legitimní zůstávají i další případy: Shared Kernel s explicitně dohodnutým vlastníkem, read-only replika pro reporting a analytický kontext, který čte data mimo doménový model. Anti-vzor začíná ve chvíli, kdy jeden kontext čte zápisový model druhého a spoléhá se na jeho tvar.

✕ Anti-vzor

Příklad: Sdílená databáze (špatně)

php src/OrderManagement/Infrastructure/Repository/DoctrineOrderRepository.php

1<?php2 3declare(strict_types=1);4 5// ŠPATNĚ: OrderManagement context přímo dotazuje tabulku users z UserManagement kontextu6 7namespace App\OrderManagement\Infrastructure\Repository;8 9use App\OrderManagement\Domain\ValueObject\CustomerId;10use App\OrderManagement\Domain\ValueObject\OrderId;11use Doctrine\DBAL\Connection;12 13class DoctrineOrderRepository14{15    public function __construct(private Connection $connection) {}16 17    public function findOrdersWithUserDetails(CustomerId $customerId): array18    {19        // Přímý JOIN na tabulku z jiného Bounded Context!20        return $this->connection->executeQuery(21            'SELECT o.*, u.email, u.billing_address, u.vat_number22             FROM orders o23             JOIN users u ON o.user_id = u.id   -- tabulka patří do UserManagement kontextu!24             WHERE o.customer_id = :id',25            ['id' => $customerId->value]26        )->fetchAllAssociative();27    }28}29 30// Billing context dělá totéž:31namespace App\Billing\Infrastructure;32 33class InvoiceGenerator34{35    public function __construct(private Connection $db) {}36 37    public function generate(OrderId $orderId): Invoice38    {39        // Opět přímý přístup k tabulce orders z OrderManagement kontextu!40        $data = $this->db->executeQuery(41            'SELECT o.total, u.billing_address, u.vat_number42             FROM orders o JOIN users u ON o.user_id = u.id43             WHERE o.id = :id',44            ['id' => $orderId->value]45        )->fetchAssociative();46        // ...47    }48}

◢ Vzor

Příklad: Izolované kontexty s ACL (správně)

php src/Billing/Domain/Port/CustomerDataProvider.php

1<?php2 3declare(strict_types=1);4 5// SPRÁVNĚ: Každý kontext vlastní svá data a komunikuje přes definované rozhraní6 7// OrderManagement kontext si ukládá pouze to, co potřebuje pro svou logiku.8// Billing údaje zákazníka získává přes Anti-Corruption Layer.9 10namespace App\Billing\Domain\Port;11 12use App\Billing\Domain\ValueObject\Address;13use App\Billing\Domain\ValueObject\CustomerId;14use App\Billing\Domain\ValueObject\VatNumber;15 16// Port (rozhraní) - Billing kontext definuje, co potřebuje vědět o zákazníkovi17interface CustomerDataProvider18{19    public function getBillingDataForCustomer(CustomerId $customerId): CustomerBillingData;20}21 22// CustomerBillingData je DTO specifické pro Billing kontext - ne User entita!23final class CustomerBillingData24{25    public function __construct(26        public readonly string $fullName,27        public readonly Address $billingAddress,28        public readonly ?VatNumber $vatNumber,29    ) {}30}31 32// Infrastrukturní adapter - implementace v Billing kontextu, volá UserManagement přes API33namespace App\Billing\Infrastructure\Adapter;34 35use App\Billing\Domain\Port\CustomerBillingData;36use App\Billing\Domain\Port\CustomerDataProvider;37use App\Billing\Domain\ValueObject\Address;38use App\Billing\Domain\ValueObject\CustomerId;39use App\Billing\Domain\ValueObject\VatNumber;40use Symfony\Contracts\HttpClient\HttpClientInterface;41 42class HttpUserManagementAdapter implements CustomerDataProvider43{44    public function __construct(private readonly HttpClientInterface $httpClient) {}45 46    public function getBillingDataForCustomer(CustomerId $customerId): CustomerBillingData47    {48        $response = $this->httpClient->request(49            'GET',50            "/internal/users/{$customerId->value}/billing"51        );52        $data = $response->toArray();53 54        return new CustomerBillingData(55            fullName: $data['full_name'],56            billingAddress: Address::fromArray($data['billing_address']),57            vatNumber: isset($data['vat_number']) ? new VatNumber($data['vat_number']) : null,58        );59    }60}

Synchronní HTTP adaptér z ukázky výše není jediná možnost a pro modulární monolit bývá tou nejdražší. V úvahu připadají tři cesty a každá má svou cenu.

Volání přes rozhraní v procesu. Kontext B vystaví port, kontext A ho volá přímo, bez sítě. Hranice zůstane zachovaná, latence žádná nepřibude. Cenou je společné nasazení a disciplína, aby se z portu nestal průchod do cizího modelu.
Synchronní HTTP nebo gRPC. Nutnost, jakmile kontexty běží odděleně. Zaplatíte latencí, nedostupností upstreamu ve chvíli vlastního provozu a nutností řešit timeouty i náhradní chování.
Asynchronní replikace přes události. Billing naslouchá události CustomerBillingDataUpdated a drží si lokální kopii potřebných dat (read model projection). Synchronní závislost mizí a čtení má ze všech tří variant nejnižší latenci. Cenou je eventuální konzistence a kód pro doplnění dat konzumentovi, který se připojí později. Spolehlivé publikování řeší Outbox Pattern.

21.06 Anti-vzor: Mutovatelné doménové události#

Doménová událost popisuje fakt, který se v minulosti stal. Evans ji proto označuje za zpravidla neměnnou (immutable), protože jde o záznam něčeho minulého [6]. Ono „zpravidla“ je na místě: doplnit metadata při publikování zprávy je běžné, změnit částku v OrderPlaced je konceptuální rozpor. Událost, kterou lze po vytvoření přepsat, ztrácí hodnotu historického záznamu.

Mutovatelné události navíc způsobují praktické problémy při event sourcingu, auditních logách a při komunikaci mezi Bounded Contexts. Přijímající kontext totiž předpokládá, že obdrží konzistentní a neměnná data.

Rozpoznávací znak. Otevřete třídu události a hledejte setter nebo \DateTime bez Immutable. Obojí znamená, že minulost lze v tomto systému přepsat.

Praxe pracuje se dvěma časovými razítky. occurredAt říká, kdy se věc stala v doméně; recordedAt, kdy ji systém zapsal. U události vzniklé z uživatelské akce obě hodnoty splývají, u importu historických dat nebo u zpětného storna se rozejdou třeba o týdny. Jedno razítko generované v konstruktoru na takový případ nestačí.

✕ Anti-vzor

Příklad: Mutovatelná událost (špatně)

php src/OrderPlaced.php

1<?php2 3declare(strict_types=1);4 5// ŠPATNĚ: Mutovatelná doménová událost6 7class OrderPlaced8{9    private string $orderId;10    private string $customerId;11    private float $totalAmount;12    private \DateTime $occurredAt; // Mutovatelný DateTime!13 14    // Veřejné settery - událost lze po vytvoření libovolně měnit15    public function setOrderId(string $orderId): void16    {17        $this->orderId = $orderId;18    }19 20    public function setTotalAmount(float $amount): void21    {22        $this->totalAmount = $amount; // Měnit celkovou částku události? Nonsens!23    }24 25    public function setOccurredAt(\DateTime $dt): void26    {27        $this->occurredAt = $dt; // Čas vzniku události by měl být fixní28    }29 30    public function getOrderId(): string { return $this->orderId; }31    public function getTotalAmount(): float { return $this->totalAmount; }32    public function getOccurredAt(): \DateTime { return $this->occurredAt; }33}

◢ Vzor

Příklad: Immutable doménová událost (správně)

php src/OrderManagement/Domain/Event/OrderPlaced.php

1<?php2 3declare(strict_types=1);4 5// SPRÁVNĚ: Immutable doménová událost s readonly properties6 7namespace App\OrderManagement\Domain\Event;8 9use App\OrderManagement\Domain\ValueObject\CustomerId;10use App\OrderManagement\Domain\ValueObject\Money;11use App\OrderManagement\Domain\ValueObject\OrderId;12 13final readonly class OrderPlaced14{15    public \DateTimeImmutable $recordedAt;16 17    public function __construct(18        public OrderId $orderId,19        public CustomerId $customerId,20        public Money $totalAmount,21        public int $itemCount,22        // Kdy se to stalo v doméně. U běžné akce je to teď, u importu historie ne.23        public \DateTimeImmutable $occurredAt = new \DateTimeImmutable(),24    ) {25        // Kdy to zapsal systém - údaj patří infrastruktuře, ne doméně.26        $this->recordedAt = new \DateTimeImmutable();27        // Všechny hodnoty jsou nastaveny jednou v konstruktoru.28        // Neexistují žádné settery - událost je neměnná.29        // Čte se přímo přes readonly properties ($event->orderId), accessory nejsou potřeba.30    }31}

Neměnnost instance přitom neřeší verzování schématu. Jakmile událost přežije nasazení, které jí přidá pole, potřebujete upcasting nebo verzovaný název typu; obojí rozebírá kapitola Event Sourcing.

Příbuzný anti-vzor: událost jako aplikační hook. Názvy CacheShouldBeInvalidated nebo EmailNeedsToBeSent nepopisují fakt, ale příkaz převlečený do minulého času. Verraes třídí zprávy na příkazy, dotazy a informace [8] a záměna kategorií je jádrem problému. Doménová událost říká, co se v doméně stalo, a nezajímá se, kdo na ni zareaguje. Jakmile její jméno obsahuje instrukci pro infrastrukturu, jde o příkaz, ne o událost.

21.07 Anti-vzor: Doménová logika v infrastrukturní vrstvě#

DDD odděluje doménovou vrstvu od infrastrukturní. Infrastrukturní vrstva (Doctrine repozitáře, Symfony Forms, kontrolery, event listenery) má být tenká a delegovat veškerou doménovou logiku do doménové vrstvy. Doménová pravidla v infrastrukturních třídách narušují hranice vrstev a vytvářejí skrytou, těžko testovatelnou logiku.

Rozpoznávací znak. Otevřete libovolnou třídu v adresáři Infrastructure/ a hledejte podmínku, která se ptá na doménový stav. Řádek if ($user->getStatus() !== 'pending') v repozitáři je pravidlo, ne persistence.

✕ Anti-vzor

Příklad: Doménová logika v repozitáři a kontroleru (špatně)

php src/UserManagement/Infrastructure/Repository/DoctrineUserRepository.php

1<?php2 3declare(strict_types=1);4 5// ŠPATNĚ: Doménová logika v Doctrine repozitáři6 7namespace App\UserManagement\Infrastructure\Repository;8 9use App\UserManagement\Domain\Model\User;10use Doctrine\Bundle\DoctrineBundle\Repository\ServiceEntityRepository;11use Doctrine\Persistence\ManagerRegistry;12 13class DoctrineUserRepository extends ServiceEntityRepository14{15    public function __construct(ManagerRegistry $registry)16    {17        parent::__construct($registry, User::class);18    }19 20    public function activateUser(string $userId, string $token): void21    {22        $user = $this->find($userId);23 24        // Doménová logika přímo v repozitáři - ŠPATNĚ!25        if ($user->getStatus() !== 'pending') {26            throw new \RuntimeException('User is not pending.');27        }28        if ($user->getToken() !== $token) {29            throw new \RuntimeException('Invalid token.');30        }31        $user->setStatus('active');32        $user->setToken(null);33        $user->setActivatedAt(new \DateTime());34 35        // Repozitář volá flush - to by měla řídit aplikační vrstva36        $this->getEntityManager()->flush();37    }38}39 40// ŠPATNĚ: Doménová logika v Symfony kontroleru41class UserController extends AbstractController42{43    public function activate(Request $request, string $userId): Response44    {45        $user = $this->userRepository->find($userId);46        $token = $request->query->get('token');47 48        // Doménová logika v kontroleru!49        if (empty($token) || strlen($token) !== 32) {50            return $this->json(['error' => 'Invalid token format'], 400);51        }52        if ($user->getCreatedAt() < new \DateTime('-24 hours')) {53            // Expirace tokenu - doménové pravidlo patří do domény, ne do kontroleru!54            $user->setStatus('expired');55            $this->entityManager->flush();56            return $this->json(['error' => 'Token expired'], 400);57        }58        // ...59    }60}

◢ Vzor

Příklad: Správné vrstvení – logika v doméně (správně)

php src/UserManagement/Infrastructure/Repository/DoctrineUserRepository.php

1<?php2 3declare(strict_types=1);4 5// SPRÁVNĚ: Doménová logika v doménové entitě (viz sekci o anémickém modelu)6// Repozitář je pouze tenký adaptér pro persistenci7 8namespace App\UserManagement\Infrastructure\Repository;9 10use App\UserManagement\Domain\Model\User;11use App\UserManagement\Domain\ValueObject\UserId;12use App\UserManagement\Domain\Repository\UserRepository;13use Doctrine\ORM\EntityManagerInterface;14 15class DoctrineUserRepository implements UserRepository16{17    public function __construct(private readonly EntityManagerInterface $em) {}18 19    public function save(User $user): void20    {21        $this->em->persist($user);22        // Flush je řízen aplikační vrstvou (Unit of Work), ne repozitářem23    }24 25    public function findById(UserId $id): ?User26    {27        return $this->em->find(User::class, $id->value);28    }29}30 31// SPRÁVNĚ: Aplikační vrstva (Command Handler) orkestruje, doména rozhoduje32namespace App\UserManagement\Application\Command;33 34use App\UserManagement\Domain\Repository\UserRepository;35use App\UserManagement\Domain\ValueObject\UserId;36use App\UserManagement\Domain\Exception\UserNotFoundException;37use App\UserManagement\Domain\ValueObject\VerificationToken;38use Doctrine\ORM\EntityManagerInterface;39use Symfony\Component\Messenger\MessageBusInterface;40 41class ActivateUserHandler42{43    public function __construct(44        private readonly UserRepository $users,45        private readonly EntityManagerInterface $em,46        private readonly MessageBusInterface $eventBus47    ) {}48 49    public function __invoke(ActivateUserCommand $command): void50    {51        $user = $this->users->findById(new UserId($command->userId));52        if ($user === null) {53            throw new UserNotFoundException($command->userId);54        }55 56        // Doménová logika je v entitě - handler pouze orkestruje57        $user->activate(VerificationToken::fromString($command->token));58 59        $this->em->flush(); // Flush patří do aplikační vrstvy60 61        foreach ($user->releaseEvents() as $event) {62            $this->eventBus->dispatch($event);63        }64    }65}66 67// SPRÁVNĚ: Tenký Symfony kontroler68class UserController extends AbstractController69{70    public function __construct(private readonly MessageBusInterface $commandBus) {}71 72    public function activate(Request $request, string $userId): Response73    {74        $this->commandBus->dispatch(new ActivateUserCommand(75            userId: $userId,76            token: $request->query->getString('token'),77        ));78 79        return $this->json(['status' => 'activated']);80    }81}

Handler odesílá doménové události rovnou na MessageBusInterface, a právě zde vede hranice, kterou lze přehlédnout. Doménová událost je vnitřní věc kontextu, integrační událost je veřejný kontrakt vůči okolí. Jakmile obojí sdílí jednu sběrnici, kdokoli si na doménovou událost pověsí handler a její tvar se tím stane veřejným API, které už nelze měnit. Oddělení obou vrstev i spolehlivé publikování ven rozebírá kapitola Outbox Pattern.

Hranice vrstev se navíc dají vynutit nástrojem, ne jen dohodou v code review. Nástroje deptrac [9] a PHPArkitect [10] čtou statickou strukturu kódu a v CI zastaví build, který ji poruší. Užitečné minimum je jediné pravidlo: App\*\Domain nesmí odkazovat na Doctrine\* ani Symfony\*. Jeden řádek konfigurace nahradí opakovanou diskusi u každého pull requestu. Pozor jen na název balíčku, původní qossmic/deptrac je opuštěný ve prospěch deptrac/deptrac.

21.08 Anti-vzor: Over-engineering u jednoduchých aplikací#

Anti-vzorem zde není samotné DDD, ale jeho ceremonie bez komplexní domény. Agregáty, Value Objects a doménové události obalují prosté řádky v databázi, pro které stačí formulář a tabulka. Typické příznaky: tým tráví více času architekturou než obchodní hodnotou a triviální změna prochází desítkami souborů napříč vrstvami.

Méně nákladná cesta začíná minimálním přístupem a přidává DDD prvky, až když se doménová složitost skutečně projeví. Celý rozhodovací rámec – sedm situací, kdy DDD vynechat, alternativy a rozhodovací strom – rozebírá kapitola Kdy DDD nepoužívat.

Hranice pravidla. Ceremonie sama o sobě chyba není. V jádrové subdoméně je to investice, která se vrátí při každé změně pravidel. Chybou je stejná ceremonie v podpůrné subdoméně, kde se za rok nezmění nic než sazba DPH.

21.09 Anti-vzor: Ignorování Ubiquitous Language#

Když selže Ubiquitous Language, tatáž doménová entita nese různé názvy na různých místech. Společný jazyk vývojářů a doménových expertů přestane platit a vývojář víc překládá mezi vrstvami, než modeluje doménu. Výsledkem jsou nedorozumění, chyby a ztráta doménového vhledu v kódu.

Rozpoznávací znak. Nechte doménového experta popsat jeden běžný případ a poznamenejte si každé slovo, které v kódu nenajdete nebo které tam znamená něco jiného. Délka seznamu je mírou driftu.

✕ Anti-vzor

Příklad: Nekonzistentní pojmenování (špatně)

php src/User.php

1<?php2 3declare(strict_types=1);4 5// ŠPATNĚ: Tatáž doménová entita má různé názvy na různých místech6// Pozn.: koláž ukázek z různých míst projektu, ne jeden skutečný soubor7 8// Databázová tabulka: "clients"9// Doménový expert: "Pojistník" (PolicyHolder)10// Backendový kód:11class User { /* ... */ }         // Proč User? Systém je pro pojišťovnu!12class Customer { /* ... */ }     // Jiný název ve stejném projektu13class Account { /* ... */ }      // Třetí název v jiném modulu14 15// API endpoint: GET /api/clients/{id}16 17// Doctrine entita:18#[ORM\Entity]19#[ORM\Table(name: 'clients')]20class User { /* ... */ }  // Třída "User", tabulka "clients" - zmatek21 22// Metody v kódu:23function getCustomerById(int $id): User { /* ... */ }   // Vrací User, bere customer24function findUser(int $clientId): Customer { /* ... */ } // Bere client, vrací Customer25 26// Výsledek: vývojář musí neustále překládat mezi vrstvami místo práce na doménové logice

◢ Vzor

Příklad: Konzistentní Ubiquitous Language (správně)

php src/Insurance/Domain/Model/PolicyHolder.php

1<?php2 3declare(strict_types=1);4 5// SPRÁVNĚ: Jednotný jazyk pojišťovací domény napříč všemi vrstvami6 7// Doménový expert: "Pojistník" → kód: PolicyHolder8// Doménový expert: "Pojistná smlouva" → kód: InsurancePolicy9// Doménový expert: "Pojistné plnění" → kód: Claim10// Doménový expert: "Pojistná událost" → kód: InsuredEvent11 12namespace App\Insurance\Domain\Model;13 14use App\Insurance\Domain\ValueObject\BirthNumber;15use App\Insurance\Domain\ValueObject\ContactDetails;16use App\Insurance\Domain\ValueObject\Money;17use App\Insurance\Domain\ValueObject\PersonName;18use App\Insurance\Domain\ValueObject\PolicyHolderId;19use App\Insurance\Domain\ValueObject\RiskProfile;20 21// Třídy pojmenovány přesně podle doménového slovníku:22class PolicyHolder23{24    private readonly PolicyHolderId $id;25    private PersonName $fullName;26    private BirthNumber $birthNumber; // Specifický pojišťovací identifikátor27    private ContactDetails $contactDetails;28 29    public function fileClaimFor(InsuredEvent $event): Claim30    {31        // Metoda pojmenována jazykem domény - doménový expert rozumí!32        return Claim::open($this->id, $event);33    }34}35 36class InsurancePolicy37{38    public function calculatePremium(RiskProfile $riskProfile): Money39    {40        // Název metody je přímo z doménového slovníku pojišťovny41        return $this->basePremium->adjustFor($riskProfile);42    }43 44    public function isValidForEvent(InsuredEvent $event): bool45    {46        // Doménový expert okamžitě rozumí, co tato metoda dělá47        return $this->validFrom <= $event->occurredAt()48            && $this->validTo >= $event->occurredAt();49    }50}51 52// Databázová tabulka: policy_holders (ne "users" ani "clients")53// API endpoint: POST /api/policy-holders/{id}/claims54// Testy: "When a policy holder files a claim for an insured event..."

21.10 Shrnutí: anti-vzor, znak, alternativa#

Anti-vzor	Podle čeho ho poznáte	Realistická alternativa	Víc v knize
Anémický model	Entita má jen gettery a settery, pravidlo nad nimi žije v cizí třídě	Pravidla do entity, nebo přiznaný Transaction Script v jednoduché subdoméně	22.09
Primitive Obsession	Tatáž validace téže hodnoty na třech místech	Hodnotový objekt tam, kde má hodnota pravidla, operace nebo hrozí záměna	06.04
Příliš velký agregát	Kolekci načítáte jen kvůli přidání jedné položky	Rozdělit podle invariantů, reference přes ID	07.04
Sdílená databáze	Migrace jednoho kontextu sahá na tabulku jiného týmu	Port a adaptér, replikace přes události, oddělená schémata v monolitu	03
Mutovatelná událost	Událost má setter nebo mutovatelný `DateTime`	`readonly` vlastnosti, `occurredAt` i `recordedAt`	15
Logika v infrastruktuře	Podmínka nad doménovým stavem v adresáři `Infrastructure/`	Pravidlo do entity, orchestrace do handleru, hranice do CI	20.01
Over-engineering	Triviální změna prochází desítkami souborů	Míru DDD volit podle typu subdomény	22
Drift jazyka	Expert použije slovo, které v kódu není	Glosář v repozitáři, revize jmen u každé nové funkce	20.03

Tabulka má jedno společné čtení. Žádný z uvedených anti-vzorů nevzniká z neznalosti vzorů, ale z pohodlí: každý je krok, který v daném týdnu ušetří práci a účet za něj přijde o rok později. Proto je užitečnější znát rozpoznávací znak než definici.

Anémickému doménovému modelu se obšírně věnuje Vaughn Vernon v Implementing Domain-Driven Design (2013), odkud pochází i test dvou otázek z úvodu sekce 21.02. Další tituly uvádějí doporučené zdroje.

Časté otázky

Co je anémický doménový model a jak ho poznat?

Anémický model vypadá na první pohled jako DDD – obsahuje třídy s názvy agregátů, entit a hodnotových objektů. Veškerá logika je ale přesunutá do služeb. Typickým znakem jsou gettery a settery jako jediné metody a třídy bez jakéhokoli pravidla uvnitř. Doménová logika končí ve „Service“ třídách, které manipulují s daty zvenku. Výsledkem je procedurální kód balený do objektových fasád. Detailní rozbor v sekci Anémický doménový model.

Je anémický model vždy chyba?

Ne. Fowler sám v článku o anémickém modelu píše, že doménový model není vždy nejlepší nástroj, a odkazuje na Transaction Script. V doméně s několika málo pravidly je procedura na jeden případ užití čitelnější než vrstva tříd okolo ní. Anémický model je chyba tehdy, když platíte cenu doménového modelu – mapování, obalování hodnot, rozpad do vrstev – a nedostáváte za ni žádný přínos. Rozbor obou stran sporu v sekci Kdy anémický model chyba není.

Proč je Primitive Obsession problém?

Primitive Obsession znamená používání primitivních typů (string, int, float) tam, kde patří doménový pojem. Místo typu Email se předává string, místo Money dvojice float. Důsledkem je, že validace a pravidla se opakují v každém místě volání, nebo se zapomínají. Hodnotový objekt s jedním místem validace tyto duplicity odstraňuje a typ dává kontext, co daná hodnota reprezentuje. Rozbor a příklady v sekci Primitive Obsession.

Jak poznat, že je agregát příliš velký?

Typické příznaky God Aggregate jsou tři. Agregát obsahuje desítky vnitřních entit. Jeho načtení zabere stovky SQL dotazů. Nebo souběžné operace nad různými částmi narážejí na optimistické zamykání. Pokud dvě metody agregátu řeší vzájemně nezávislá pravidla a nesdílejí invariant, pravděpodobně jde o dva samostatné agregáty. Hranice agregátu má kopírovat hranice transakční konzistence – nic víc. Praktický příklad refaktoringu v sekci Příliš velký agregát.

Proč je sdílená databáze mezi Bounded Contexts problém?

Sdílená databáze formálně drží data pohromadě, ale fakticky ruší hranice mezi Bounded Contexts. Změna schématu v jednom kontextu může rozbít druhý, pojmy se mísí a model jednoho týmu začíná záviset na modelu druhého. Správné řešení je, aby každý Bounded Context vlastnil svá data a komunikace probíhala přes definované rozhraní (API, události), nikoli přes sdílenou tabulku. Podrobný rozbor v sekci Sdílená databáze napříč Bounded Contexts.

Musí být doménová událost neměnná?

Ano. Doménová událost popisuje něco, co se již stalo – OrderPlaced, PaymentReceived – a minulost nelze měnit. Událost bez setterů, s neměnnými atributy a časovým razítkem vytvořeným při konstrukci je bezpečné sdílet mezi handlery, persistovat v event store a použít pro zpětnou rekonstrukci stavu. Mutovatelná událost vede k race condition, nedeterministickému zpracování a nekonzistentnímu auditu. Viz sekci Mutovatelné doménové události.