Praktický návod

Jak navrhnout architekturu větší PHP aplikace

Nezačínej diagramem pro celý svět. Vyber jeden důležitý proces, pojmenuj jeho pravidla a teprve pak kolem něj stav vrstvy.

25 minut · PHP architektura

Nejdřív stručně

Architektura je hlavně dohoda

Architektura říká, kam patří pravidla, data a technické detaily. Dobrá architektura nedělá aplikaci „enterprise“. Umožní lidem změnit jednu věc bez strachu z deseti vedlejších efektů.

DDD pomáhá začít jazykem byznysu. Doména je část aplikace, kde jsou pravidla firmy: třeba kdy lze odeslat objednávku nebo schválit fakturu.

Připrav si

Co potřebuješ před kreslením složek

Nejdřív si ujasni problém. Složky a názvy tříd přijdou až potom.

Jeden konkrétní tok, například vytvoření objednávky, schválení nabídky nebo změna stavu reklamace.
Člověka, který zná byznysová pravidla a umí potvrdit, co se má stát v běžném i chybovém případě.
PHP projekt, ve kterém můžeš dělat malé postupné změny. Nemusíš první den předělávat celý adresář src/.
Místo pro krátké poznámky. Pro začátek stačí jedna stránka s pojmy, pravidly a příklady.

Kroky 1 až 3

Postav hranice kolem skutečné práce

Vrstva není složka pro složku. Má mít jasnou roli a jasně říct, co přes ni nesmí projít.

1. Pojmenuj doménu lidskou řečí

Napiš tři až pět vět, které vysvětlují jeden proces bez technických slov. Například „objednávku lze odeslat až po úspěšné platbě“.
Vypiš důležitá podstatná jména a slovesa. Z nich vzniknou názvy tříd, metod a případů použití.
Když dva lidé stejnému slovu rozumí jinak, rozliš je hned. Nejasný název v kódu bývá dražší než další třída.

Oficiální Symfony doporučení pro strukturu aplikace

2. Rozděl odpovědnosti do vrstev

Doména drží pravidla a pojmy. Nemá vědět o HTTP, SQL ani o konkrétní databázi.
Aplikační vrstva skládá use-case: načte data, zavolá pravidla domény a uloží výsledek. Je to dobré místo pro třídu CreateOrder.
Infrastruktura řeší techniku: databázi, e-mail, soubor nebo externí API. Implementuje rozhraní, které potřebuje aplikace.
Vstupní vrstva, třeba Symfony kontroler nebo CLI příkaz, jen přeloží vstup do use-case a vrátí odpověď.

mkdir -p src/Domain src/Application src/Infrastructure

Oficiální Symfony dokumentace ke službám a jejich propojení

3. Chraň směr závislostí

Vnitřní vrstvy nesmí importovat konkrétní Symfony, Doctrine nebo SDK třídy. Jinak se z pravidel rychle stanou technické detaily.
Když aplikace potřebuje uložit objednávku, závisí na rozhraní OrderRepository. Implementace s databází patří ven, do infrastruktury.
Každý nový závislostní směr krátce zapiš do README. V týmu pak nebude architektura jen obrázek z minulého roku.

php bin/console debug:container --types

Oficiální Symfony dokumentace k typovým závislostem

Krok 4

Ověř hranice na jednom use-case

Nejlepší test architektury je malá změna. Zkus ji udělat bez sahání do všeho kolem.

Najdi pravidlo domény

Otevři use-case a ukaž na třídu nebo metodu, kde skutečně žije hlavní pravidlo. Pokud je schované v kontroleru nebo SQL dotazu, vrať ho blíž k doméně.
Vyměň technický detail v testu

Use-case by měl jít otestovat s jednoduchou paměťovou náhradou repozitáře. Neměl by k tomu potřebovat připojenou databázi ani webový server.
```
php bin/phpunit
```
Zkontroluj závislosti vrstev

Vyhledej importy frameworku v doméně. Jednotlivý výskyt může mít důvod, ale má být vědomou výjimkou, ne výchozím stavem.
```
rg "Symfony\\|Doctrine\\" src/Domain
```

Když to zlobí

Nejčastější chyby

Předěláváš celý projekt najednou

Vyber jeden use-case, obestav ho testy a přesuň ho jako první. Velký „architektonický sprint“ často jen zastaví dodávku funkcí a nic neověří.

Vznikají prázdné vrstvy plné přeposílacích metod

Vrstva má existovat kvůli pravidlu nebo hranici, ne kvůli názvu z článku. Když nemá vlastní odpovědnost, klidně ji zatím nevytvářej.

Doména volá databázi nebo externí API přímo

Přidej malé rozhraní do aplikační nebo doménové části a konkrétní klient dej do infrastruktury. Pravidla pak půjdou testovat bez sítě.

Tým používá pro stejnou věc různé názvy

Zaveď krátký slovníček přímo u modulu a promítněte ho do názvů tříd. Konzistence je pro velkou aplikaci cennější než dokonale chytrý název.

Hotovo

Víš, kde mají žít pravidla i technika.

DDD ti teď může sloužit jako kompas, ne jako povinná šablona. Přidávej hranice postupně tam, kde aplikace opravdu roste.

Přečíst DDD ve slovníku Všechny návody